Tuesday, September 30, 2014

Why not use C++ instead of C for ...

This question pops up again and again, either for operating systems or databases or something else.

Primarily this has to deal with: How Linus Torvalds feels about C++

This is what happened on one of the the questions concerning the use of C++ over C for some GIT thread..


From: Linus Torvalds <torvalds <at> linux-foundation.org>
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (2 years, 14 weeks, 16 hours and 36 minutes ago)

On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
> When I first looked at Git source code two things struck me as odd:
> 1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
> it's BS.

*YOU* are full of bullshit.

C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.

Monday, September 29, 2014

Solution: Unknown symbol “__aeabi_ldivmod”

You might notice that while compiling for your 32bit platforms your kernel module compiles. However, when you are inserting it we see a failure (either at boot or while explicitly doing an insmod or modprobe).

The reason this "Unknown symbol in module" is seen is because you are in some instruction trying to do a 64bit division in the Linux kernel for an ARM platform (32bit).

Why is the symbol missing though if everything compiles. The compiler wants to do the 64bit div with slow library functions which Linux does not implement. So when the code is run, the symbol (__aeabi_ldivmod) is not found.

The solution to this problem is to use do_div() while including <asm/div64.h>.

do_div has its own side effects and if you search enough you will find that there are multiple cases where "do_div is considered harmful". But for now, if you are not doing this division frequently, it might be a good idea to just use do_div() and get your work done.

From div64.h:

// the semantics of do_div() macros are:
uint32_t do_div(uint64_t *n, uint32_t base) {
  uint32_t remainder = *n % base;
  *n = *n / base;
  return remainder;

Simple example:

void  _do_64bit_div(int64_t *operand_ptr, int64_t base)
    // do_div for older platforms.
    uint64_t operand, remainder;
    operand = *operand_ptr;
    remainder = do_div(operand, base);
    *operand_ptr = operand;
    // Direct div for newer platforms.
    unit64_t result;
    *operand_ptr = *operand_ptr / base;

Just call this function with the parameters (&operand / operator) and get the result in operand.