Re: oops? read/write vs type of length parameter

[Paul Eggert]

On 04/12/2011 11:37 PM, Eli Zaretskii wrote:

> The current code handles this situation (by looping for what's left
> to write), while your suggested code will treat that as a fatal error.

No, the suggested code also loops for what's left to write.
Perhaps you misread the code? (or am I misunderstanding your comment?)

> Emacs cannot have buffers (or any other streams of bytes) that are
> larger than SSIZE_MAX, because a small number of bits is reserved for
> the Lisp tags.

That kind of argument violates abstraction boundaries: sysdep.c
is supposed to be about system things, and it's not supposed to
rely on assumptions about Emacs Lisp internals.  There may be a
few violations of these abstraction boundaries now, but let's
not make this worse.

For example, it would be a fairly small change to make Emacs buildable on
a machine with 32-bit pointers and 64-bit EMACS_INT.  And this would
have real advantages: on 32-bit hosts it would remove the arbitrary
(and really annoying :-) 256 MiB limit on editable files.  But it
would mean that Emacs *could* have buffers larger than SSIZE_MAX.

emacs_write should not stand in the way of plausible improvements
such as this one.

> It was also about a mistaken
> call to emacs_write with a negative value in the last argument...
> 
> That danger still exists with your proposed version of emacs_write,

No it doesn't, because I've carefully audited all the Emacs code
(which is how I found all those *other* bugs :-).  With the
proposed change, emacs_write is never called with a negative
argument.