The size of PAC_TYPE_LOGON_INFO and PAC_TYPE_UPN_DNS_INFO elements is supposed
to be padded to an 8 byte boundary...
(In reply to Stefan Metzmacher from comment #0)
My understanding about alignment:
- I think current processors are bit smart and they can handle the unaligned memory but in some bad situation, the processor takes some extra cycles to fetch the unaligned memory. So it would be good for coder to care about alignment when he writes the code.
- Padding increases the performance of the processor at the penalty of memory.
- For structure, union wastage of memory can be saved by rearranging members in the order of largest size to smallest.
- But wont custom struct member alignment cause compatibility issues, for linking external library using different packing alignments?
__attribute__ ((aligned (8)))
the alligned attribute might not be supported by all compilers. gcc supports it, xlc also supports it obviously. The studio compiler docs however say, that it will only issue a warning:
Roughly equivalent to #pragma align. Generates a warning and is ignored if used on variable length arrays
The documentation of the "pragma align" says that this will fix alignment:
We'd need to make configure tests for alignment fixing capablities of the compiler.
(In reply to Björn Jacke from comment #2)
This bug has absolutely nothing to do with compilers nor the memory representation