emacs-devel
[Top][All Lists]
Advanced

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

Re: Preview: portable dumper


From: Andy Moreton
Subject: Re: Preview: portable dumper
Date: Fri, 16 Feb 2018 16:50:55 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (windows-nt)

On Fri 16 Feb 2018, Eli Zaretskii wrote:

>> From: Andy Moreton <address@hidden>
>> This appears to be because sys_read() and _read() take an unsigned int
>> for count rather than size_t.
>
> Yes.  Angelo already reported this a few days ago.
>
>> Changing the code to:
>> 
>> read (fd, (char*) buf + bytes_read, (int)(bytes_to_read - bytes_read));
>
> This cannot be the right solution, because you will lose bits in the
> cast, when bytes_to_read is greater than INT_MAX.

Agreed - it was a quick and dirty hack to get the build to complete.

> When Angelo reported this, I said I didn't understand how a similar
> code in sysdep.c:emacs_intr_read does compile without a problem,
> although it seems to feed a ptrdiff_t value (which should be 64-bit
> wide in the 64-bit Windows build, just like size_t, except for the
> signedness), similarly to the above.  Can you spot why that works?
> Maybe look at the preprocessed source?  Maybe then we will know how to
> fix that properly (or maybe we will discover one more subtle bug ;-).

No idea - I'll take a look over the weekend.

> In general, breaking the read into chunks of INT_MAX should work as
> well, but I'd like to know first what's going on in emacs_intr_read,
> because perhaps there's a more elegant solution we have available.

Given the mismatch between sys_read/_read and read, doesn't the smae
problem exist elsewhere in emacs also ?

    AndyM




reply via email to

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