Re: Preview: portable dumper

[Paul Eggert]

Thanks for working on this. Although it's not the approach I would have 
taken, there is a real advantage to having running code. A few points:

* The portable dumper doesn't work with modules. Although this should be 
OK for Emacs builds since they don't use modules either, what is your 
thought about this? Will the module API need to change to support dumping?

* I am working on getting Emacs to work with gcc -fcheck-pointer-bounds, 
and will boost the priority of that task and CC: you when I have 
something ready. The portable dumper should work in such an environment. 
I don't see any fundamental problems with this; just giving you a heads-up.

* Functions like do_dump_relocation should use intptr_t or uintptr_t, 
not ptrdiff_t, to access pointers as integers (whether relocated or 
not). In theory this would support architectures where intptr_t and 
ptrdiff_t have different widths. Although Emacs doesn't run on such 
architectures now, conceivably it could and in the meantime the code 
might as well be clear about the distinction between pointers and offsets.

* pdumper_load should check that S_ISREG (stat.st_mode) (I suppose this 
won't be needed if we load from the emacs executable....).

* I suggest using the type bits_word (defined in lisp.h) rather than 
unsigned. This should work better on 64-bit machines (plus, on weird 
platforms).

* For pdumper_read a more-portable limit is MAX_RW_COUNT (see sysdep.c) 
instead of SSIZE_MAX. Maybe that value needs to move into a .h file.

* A nit: pdumper_marked_p relies on implicit conversion to bool, a style 
I find confusing for bool values. In a bool function it's clearer to 
write 'return E != 0;' instead of 'return E;' when E might have values 
other than 0 or 1.

* I haven't thought through all the implications of this and may have 
more comments later.