[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preview: portable dumper

From: Eli Zaretskii
Subject: Re: Preview: portable dumper
Date: Tue, 20 Feb 2018 06:03:53 +0200

> 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

> > 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

> >  . 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]