Re: Preview: portable dumper

[Eli Zaretskii]

> From: Andy Moreton <address@hidden>
> Date: Mon, 19 Feb 2018 22:23:17 +0000
> 
> Comments mentioning MAX_RW_COUNT show that somebody checked an invariant
> when writing the comment, but they do not guarantee that the invariant
> will continue to be maintained in future versions of emacs. A check that
> can be enforced by the compiler is preferable.

I added an assertion there (on master) that should make the code more
future-proof.

> > As for pdumper, we could do one of 2 things:
> >
> >  . make a reasonable assumption that no .pdmp file will ever be larger
> >    than 2GB, change the assertion there which checks against SSIZE_MAX
> >    to check against UINT_MAX instead, and work internally with
> >    unsigned int instead of size_t counts; or
> 
> This seems perfectly reasonable, and is the current implementation,
> albeit checking for INT_MAX.

No, the current code actually breaks the reads into chunks no larger
than INT_MAX.  So it doesn't assume a .pdmp file cannot be at most
2GB.

> >  . write a separate Windows-specific version of dump_read_all, which
> >    in the 64-bit build would limit to UINT_MAX the number of bytes we
> >    read on each iteration through the loop.
> 
> This offers more opportunity for divergent implementations, so the other
> option is preferable.

I presumed that we will not want to punish other platforms by making
them read piecemeal.  But if that's not an issue, I agree that the
second alternative is less elegant.

> Is there a gnulib replacement for read() that works for emacs, so that
> we could use the proper prototype even on Windows ?

No, because sys_read does much more than just fix the Windows _read.