[Top][All Lists]

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

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

From: Paul Eggert
Subject: Re: oops? read/write vs type of length parameter
Date: Wed, 13 Apr 2011 01:15:01 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110223 Thunderbird/3.1.8

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

reply via email to

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