[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 12:31:48 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9

On 04/13/2011 10:22 AM, Eli Zaretskii wrote:

>> it'd be nice to remove that silly 512 MiB limit.
>> Would you object to such a change?
> Of course not!  Why should I object to a great feature like that?

OK, thanks, I'll take a look at it.  This won't happen instantly.

> The original code continued looping and trying to write the rest of
> the stuff if emacs_write returned a positive value that is smaller
> than what is was asked to write.  The new code bails out of the loop
> in that case, assuming that it's due to an error.

Ah, thanks, now I see what you mean.  The old code ignores write error
in some cases, whereas the new code carefully reports the first write
error it sees.  Yes, that is a separate issue; I think it's a better
approach, but it should be analyzed separately as it might lead to
incompatibilities.  The following further patch removes that part of
the change, so that the new code (like the old) ignores the first
write error after a partial write.

* process.c (send_process): Count partial writes as successes.
See http://lists.gnu.org/archive/html/emacs-devel/2011-04/msg00483.html
=== modified file 'src/process.c'
--- src/process.c       2011-04-13 05:02:54 +0000
+++ src/process.c       2011-04-13 19:20:49 +0000
@@ -5396,7 +5396,7 @@
                    written = emacs_write (outfd, buf, this);
-                 rv = (written == this ? 0 : -1);
+                 rv = (written ? 0 : -1);
                  if (p->read_output_delay > 0
                      && p->adaptive_read_buffering == 1)

reply via email to

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