Mundane C tricks ...

[taniwha]

[Baker]

[Baker]

[Baker]

[taniwha]

Structure order (both union and struct) is guaranteed to be the same in any compiler. For union, the offset is always 0 and the size of the union is the size of its largest field. For struct the offset is guaranteed to increase with member offsets being in the declared order and with no overlap. I believe even with alignment, there will be no gaps between fields of the same type. The issue comes when mixing types in the struct. Also, endianess makes a mess of bit fields. Otherwise, struct is very reliable, and union is a non-issue.

Your design for your vector structs is spot-on.

[Spike]

you only get padding if your data types are different sizes. structs are padded to the alignment of the largest member.

pointers and 64bit ints have undefined alignment and/or size requirements (depends upon the compiler).
floats/ints/shorts/bytes will have consistant alignment in any platform you're likely to develop for, with the exceptions of 16bit dos (use gcc and/or dos extenders) or old versions of windows ce (predating 'windows mobile' versions), both of which are obsolete.

longs are a wildcard, and should generally be avoided nowadays.

if you really care about your datatype alignments, use stdint.h though beware that its not part of c89, and that some (really obsolete) systems simply don't have allocation units that are a multiple of 8.

There are also some systems that are pure 32bit and don't support bytes/shorts. Not sure how well stdint.h works there, but there's no reason it can't work effectively enough, only that it won't be atomic, so beware of threading issues.

Other than that, if you stick to the rules of using all-same datatype sizes, and anticipate padding on some systems if you use pointers/64bit datatypes, then there's really no issues.
at least no issues other than endian... Good luck with that one.

[taniwha]

[Baker]

[Spike]

'int' is the standard datatype that is native for the machine, so 16bit if you're on a 16bit machine, 32bit if you're on a 32bit machine, and 32bit if you're on a 64bit machine... wait... that doesn't work... meh.

'long' is sometimes emulated, because 16bit ints are too much of a pain.

'size_t' is generally a uintptr_t, but can also be 16bit in a segmented system like dos, where far pointers are 32bit (although with only a 20bit address space, with random weirdness mapping to the same bits of memory). Its an efficient datatype, basically.

'long double' is a fun datatype... 80 bits of actual data on x87, 64bits of actual data with sse. its just a fun datatype.

if you're doing professional coding, get accoustomed to typing uint32_t sooner rather than later.

At the end of the day, you'll either have data structures that are internal to your code (in which case you shouldn't really care about alignment/padding etc anyway), data structures that are part of an API (where extensibility is likely more important), or data structures that are transfered between programs (where you should be checking variables are within expected parameters and extra padding can be fatal, or leak information that should not be leaked).

If its buggy on 64bit, run it through valgrind. That'll detect any reads of uninitialised padding for you nice and easy. In certain situations, memsetting everything to 0 can be bad.

[Baker]

[revelator]

There where a few Places in Doom3 that memset class members to 0 like the ase models,
but doing so caused some ase models to go black because it also nulled out some class members that should not have been. mh suggested a fix and it Works quite nicely

[taniwha]

For memsetting to 0: certain machines have non 0-bit representations of 0 (null pointers and floating point), but my understanding is that there'd be more trouble than that for quake on such machines.

The only guarantees for type sizes are char has enough bits to represent source code, and then long >= int >= short >= char, which means long == int == short == char is perfectly valid. On the other hand, apparently you can trust float: ieee spec. Maybe double, not sure, but long double is a wildcard again.

It seems even big-endian is going the way of the dodo, so I'm not sure it's worth being overly worried about memsetting to 0 (though good to keep in your mind's deep storage just in case you find yourself working with such a machine).

For reckless' example, that's not really memset 0 being bad, but just not complete: memset to 0, then do specific initializations. The memset is to ensure the whole struct is in a known state, the specific sets to non-zero is to correct that known state for fields that need to be non-zero.

[Spike]

well clearing out the vtable of a class is obviously bad... But that's more an issue with the 'new' operator than anything else.

A more serious example is when you're updating your code a little. Say you have 5 places where you spawn some type of object, and you want to add an extra field to these objects, that doesn't have a 'default' value of 0 (but 0 doesn't crash anything, at least not immediately).
You can easily forget to update at least one of those places to set it to 5 or whatever, and the behaviour of those other bits of code is now not what was originally intended.
If its not memcleared, you can run it in valgrind and have valgrind point out the bits of memory that are being poked without having been set first, thus drawing your attention to the ommision.
Though its not something you should rely upon - developing in the debugger is generally frowned upon.


While you can trust the ieee float spec, there's no guarentee that your compiler/cpu actually complies with it.
Yes, there are some machines with negative-zero integers too... And machines with 7bit or 9bit bytes, or 32bit 'bytes'. The paculiarities of the archetecture are important for speed, but any semi-mainstream system will at least attempt to support most common libraries without too much rewriting.
Little endian may be backwards, but at least its a bit more extensible in that the trailing part can be masked instead of having to be offset. There's enough awareness of bigendian that it'll live on in niche systems (like MIPS, powerpc, routers, and supercomputers), and any differences there really affect only file formats (network endian is big endian). Well written programs will still work properly, they might just use a different byte order. Yay.

While 0 can logically be a valid value for a pointer, systems that don't use 0 for NULL will have huuuge problems with C++. Its just not going to happen on any non-embedded system (I don't even count phones as 'embedded' any more).

[revelator]

Maybe not the best example there was one place though where the differences between C and C++ came to pass as an inherently bad way of using memset.

it was organized a bit like this

someclassmember dummy;

memset (&dummy, 0, sizeof(someclassmember));

whoops we just nulled out the entire row of class members

in C say like this

entity_t dummy;

memset(&dummy, 0, sizeof(entity_t));

which is valid though maybe not the best way to do Things.

it gave every static code analyzer i tried on it hickups and the memset was removed in a later patch

Visually it didnt seem to do much if anything but removing the memset worked just as well atleast in C++ while C would spew warnings about an uninitialized function if i did not memset the dummy.

[taniwha]

If you're spawning and initializing your objects in 5 different places, you're doing it wrong (*attempts to scrape more char from fingers*). I've found that even testing objects in 5 difference places is doing it wrong. That's why qfcc has a slowly growing population if things like "is_void()" (really should be "type_is_void"), "statement_is_goto", "def_operand", "new_value_expr"...: I both got tired of having to look up how to init/test and all the typing involved (even though is_void is just type->type == ev_void). For qfcc speed is not an issue, so I have such functions in the relevant .c files, but in an engine, static inline functions in header files would be more appropriate.

The currently supported MIPS port of QF is little-endian. In fact, only the ps3 ppc port is big-endian. (port = cross building scripts in tools/cross).

I believe the C spec guarantees that no matter what the machine encoding of NULL is, the source "encoding" shall be 0 (for assignment and testing). I believe memset is another matter. I guess the truly paranoid can memset the struct to 0, then explicitly set the pointers to 0.