sizeof(char)

It does not seem to be common knowledge what sizeof(char) returns and why. So I will try to cover that.

If you're new to C, you may be assuming that a char is always 8 bits, and that sizeof(char) is thus always 1. It is correct that sizeof(1) is always equal to 1, but it's for another reason, and a char may be bigger than 8 bits.

So, thus if you're an intermediate C programmer, you may know this, and for example use malloc((n+1) * sizeof(char)). The multiplication is redundant, however, because as I stated above, sizeof(char) is always equal to 1. Why?

The reason is that sizeof() returns sizes on units of the size of char; that is, sizeof(char) must be equal to 1 as, well, a char is as big as a char. This also means that the sizes of all datatypes (with potential padding) must be in multiples of CHAR_BIT (a macro which expands to the number of bits in a char).

And as you might have guessed, the sizes passed to malloc et al are not in multiples of 8 bits, they are in units of sizeof(char).

In the standard, a char is defined to be the same size as a byte. This means that a byte can be bigger than 8 bits. There are examples of C compilers which define a char, and thus a byte, as 9, 16, 32 or 36 bits.

Pocoproject

I stumbled upon this today, while looking for a platform-independent library to handle zip files:

http://pocoproject.org/

It appears to have quite a few more things that would be handy, like an XML DOM implementation, crypto routines (there must be hashing algos in there, right? I want those!), threading library and network programming.

I'll take a look on this, but it's possible that I will use it in a long-time project of mine: Nightfall, a free RTS game. See http://nightfall-rts.org/.

I'm currently using SDL and SDL_net for threading and networking, respectively, and I have my own tiny XML library (as I didn't want to drag in extra dependencies). SDL threading is not very advanced, and SDL_net doesn't support ipv6. The small XML library is quite limited.

PHP and fgets()

In an attempt to mimic behaviour of fgets in C, it appears that PHP defines the $length argument as the number of characters - 1 that should be read.
The length argument to fgets in C includes the '\0', but PHP really has no reason to care about that issue.

GDB 7 will bring major improvements

According to GDB and Debian Developer Daniel Jacobowitz, GDB 7 will bring major improvements:

http://weblog.false.org/weblog/2009/tech/inlined-function-support-for-gdb.html

Improvements mentioned are:

• Support for understanding inlined functions -- that is, you will actually be able to step in, through and out of them, and get backtraces that include inlined functions!
• Support for pretty-printing STL containers etc!
• Python scripting.

So it appears that this release will be a great one. It's slated for this fall.

Oh, and on another sidenote -- I must promote cgdb again, it simplifies debugging with gdb a lot. It will also benefit from these improvements. It could be that it could need a feature or two to make these new features easier to use (python scripting, perhaps?). Sadly, upstream of cgdb appears to be quite dead; no release since 2007.

Function returning function pointer: funny syntax

Take a look at this:

void (*f())(void*);

At a first glance, it may look like some kind of special function that returns void and takes a void*. That's totally wrong. It's actually a function that takes zero arguments, and returns function pointer, a void (*)(void*) -- that is, a pointer to a function pointer that returns void and takes a void*. The syntax actually makes a little sense if you consider the syntax for defining a variable containing such a function:

void (*f)(void*);

Typedefs of function pointers are weird too:

typedef void (*ptrFunc)(void*);

But I can't help to think that the following syntax would be much clearer:

void (*)(void*) f(); // invented syntax

void (*)(void*) f;

typedef void (*)(void*) ptrFunc;

These would make a lot more sense than the current function pointer syntax in C/C++, and would 'logically match' other declarations -- [return] type followed by an identifier (followed by argument list if it is a function), instead of mixing [return] type, identifier and argument list into one big mess.

It may be that the invented syntax is harder to parse -- I have thought a while on this, but haven't come to a reliable conclusion. The syntax may just be a historical artifact.

In any case, this odd syntax must be the reason why you usually define typedefs for function pointers, as done above. Then we can use the following syntax:

ptrFunc f();

ptrFunc f;

Much cleaner and understandable -- the obvious drawback is: what's a ptrFunc? You'll have to find the typedef to know. But I think that's worth it.

Surprise with std::map.operator [] and thread safety

A year ago or so, I got a surprise using std::map.operator [] in a multithreaded program -- the program kept crashing while in subscripting the map, even though I was just reading and nor writing -- I thought!

I looked it up today while peeking at my old code, and discovered that std::map.operator [] inserts a data_type() for the specific key if it does not exist -- which surely explains the crashes I got. The reason I was able to use it like this, was that I was storing a std::map to record valid pointers -- operator [] would thus return false for pointers that weren't keys in the map.

Lesson learnt? Use std::map.find() instead!