Re: pdump and alignment handling

[Martin, I bounced you original message to xemacs-beta, I hope you don't mind] On Mon, Jan 22, 2001 at 06:53:36PM +0900, Martin Buchholz wrote: I'm using these facts of life: 1- Alignments are powers of two 2- sizeof() is required to return a properly-aligned size (that's in ANSI) By properly aligned size I mean if p is aligned for the type, p_size is aligned too. This means that you can get an upper-bound for the alignement of a given structure from its size by finding the higher power of two that is a divisor of the size. That's the point of the pdump_align_table array. The table goes all the way to 2^8 which is overkill though. We should stop at 2^3 or maybe 2^4 (and use a 8 or 16 elements table). The other trick I use is to dump the data ordered by decreasing alignment constraint. After all, if something is aligned for 8 bytes, it is aligned for 4, 2 and 1 too. And by (2) we know that if we're aligned for 8 bytes, and we write an 8-bytes aligned structure, we will still be 8-bytes aligned afterwards. So writing the data by decreasing alignment constraints ensures the alignment at zero cost in padding. This "scaning by decreasing alignment constraint" thingy is done by pdump_scan_by_alignment btw. That would be nice and cool, except that there is one exception. Some lrecords are lying a little. Well, to be more precise, they give sizes that are not the result of a sizeof, and don't necessarily respect (2). In particular, the opaques do that. If that case, the minimal alignment is sizeof(lrecord_header) (i.e. 4, but it should have been written as a sizeof). This is the management of the exception. The other half is in pdump_allocate_offset. Which aligns too hard though... OG.