pdump and alignment handling

I've been doing too much alignment hacking lately. But I still have trouble understanding how pdump alignment works. Olivier, it seems to me that: - objects should be aligned when they are written. dumper.c still occasionally (even after my recent proposed patch) adds alignment _after_ writing an object. This requires knowledge of the next object. Bad. If you know the alignment of an object, you can write it to a stdio stream aligned by using ftell() to get the current offset in the file. pdump_dump_data() aligns objects after they are written. - every struct and Lisp_Object type should have an alignment, not just a size, stored with its description. Currently pdump doesn't have enough information to correctly align every object. We can do this accurately now because we have a working ALIGNOF macro. This matters spacewise because on some platforms everything has alignment of 4, except for doubles, which have alignment 8. Almost all Lisp_Objects require storage alignment of 4 except for things like Lisp_Float. We shouldn't have to align to max_align_t. - pdump_add_entry() uses pdump_align_table to get possible alignment of an object. But it seems to use the _size_, not the _address_ of the object to do this. I would like to simply use ALIGNOF, but the actual type of the object seems not to be available here. See above. Please comment. I would like to further nuke some of the current alignment code, like this cruft at the end of pdump_dump_data(): write (pdump_fd, desc ? pdump_buf : elmt->obj, size*count); if (elmt->is_lrecord && ((size*count) & 3) write (pdump_fd, "\0\0\0", 4-((size*count) & 3)); (This is partially fixed by my other patch with PDUMP_ALIGN_STREAM, but...) Why check is_lrecord? Don't structs have similar alignment problems?