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

[Paul Eggert <eggert@cs.ucla.edu>]

On 04/13/2011 02:46 AM, Eli Zaretskii wrote:
> I was asking whether testing errno for EWOULDBLOCK
> and EAGAIN, and the code that deals with when that happens, are good
> enough for all the possible reasons that emacs_write and
> emacs_gnutls_write could return a partial count of bytes.

The revised send_process code tests for EWOULDBLOCK and EAGAIN under
the same conditions that it does now.  If the checks are good enough
now, they will continue to be good enough after the proposed change.
So I still see no problem here.

> sysdep.c is not about system things, it's about Emacs code that
> requires platform-dependent techniques.  Most of that indeed deals
> with system types, but you will find quite a few Emacs specific
> internals

Yes, and I had already mentioned that the abstraction boundaries were
sometimes being violated there.  But let's not make matters worse.
sysdep.c is supposed to be for interfaces to system-dependent kernel
and library code, not for access to Emacs Lisp internals.

>> 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.
> 
> Somehow, I doubt it is a small change.  But if it is, by all means
> let's do it now!  What are we waiting for?

I suspect you are joking, but if not, I'd be happy to implement it.
It shouldn't take that long, and it'd be nice to remove that silly 512
MiB limit.  Would you object to such a change?

But at any rate, that would be a different change, and this fix
shouldn't wait on it.

>> emacs_write should not stand in the way of plausible improvements
>> such as this one.
> 
> Such a configuration (if it indeed is possible "easily") will need to
> revamp several calls to emacs_write anyway, so what type we use there
> now is a moot point.

True, and it suggests that we can revisit the issue if this idea is
implemented.  But in the meantime, we have a proposed change that
fixes bugs and doesn't introduce bugs.  Since there are no downsides
to this fix now, and no improvements to it have been suggested, we can
install it now, and worry about future improvements later.

> Either you care about future changes or you don't.

Both.  I care about plausible future changes; and I also realize that
we don't have time to program for all possibilities and need to fix
what's before us, which the proposed patch does.