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
I guess it's fixed in 4.15.1, 4.14.9, 4.13.13 by this commit
Author: Joseph Sutton <firstname.lastname@example.org>
AuthorDate: Wed Aug 11 13:27:11 2021 +1200
Commit: Andrew Bartlett <email@example.com>
CommitDate: Thu Oct 14 18:59:31 2021 +0000
s4/heimdal/lib/krb5/pac.c: Align PAC buffers to match Windows
Signed-off-by: Joseph Sutton <firstname.lastname@example.org>
Reviewed-by: Andrew Bartlett <email@example.com>
We just need to remember that the rule may also apply to
PAC_TYPE_CLIENT_CLAIMS_INFO, PAC_TYPE_DEVICE_INFO and PAC_TYPE_DEVICE_CLAIMS_INFO...