Josh DuBois wrote:
Why? The default alignment of this struct is 4 anyway (as all its members have a default alignment of 4 ...)
The only situation where a RTL_CRITICAL_SECTION could conceivably be not aligned to 4 would be if if were embedded into a packed struct. In this case, however, the aligned attribute wouldn't help either AFAIK.
(Additionally, the gcc'ism will annoy Patrik ;-/)
Bye, Ulrich
Hi -
Sorry for the delay - hard-drive died.
Well, on the ppc it seems that CRITICAL_SECTIONS which are initialized (they get set to CRITICAL_SECTION_INIT a lot) fairly reliably get put on 2-byte boundaries. I am not certain why this is the case. I could perhaps try to change all the instances of initialized critial sections to have their data copied into them during an init routine, but that seems like yet another big weirdness. Or maybe I can convince the compiler to stop aligning them strangely in the first place.
The problem is that the instructions to implement Interlocked* functions on the ppc require the destination of a store to be 4-byte aligned (so I want to align the LockCount member). I'm not sure, actually, how to be certain that regular int's passed to these functions will be aligned, but I havn't seen problems (yet) other than with the funny alignment of the CRITICAL_SECTION structs.
You're absolutely right about the gcc'ism, though. At the very least, it needs to be #ifdef'd.
Josh.
Ulrich Weigand wrote:
-
Josh DuBois -
Ulrich Weigand