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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 11 Apr 2011 18:16:40 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> emacs_read and emacs_write are a bit of a special case,
> because by design Emacs always invokes them with a
> small positive size (currently limited to 64 KiB, if memory
> serves).

That's not true.  When Emacs saves a buffer or some its portion,
write-region can call emacs_write (though a_write and e_write) with
the full extent of the region to be saved.  At least with a pure-ASCII
file, that's how write-region works.  Just step through the code with
a debugger, and you will see it.

That's why I changed the signature (and the local variables inside
emacs_write): without that, you simply cannot save regions that are
larger than 2GB.  The previous version would leave the saved file
empty, if invoked on large buffers.

So it is not a theoretically motivated change; it had very specific
real reason.  The old signature simply didn't work in that case.

> * When dealing with system objects, such as file descriptors
>   and C object sizes, use the relevant system types,
>   such as 'int' and 'size_t'.
> 
> * When dealing with Emacs fixnums, which are always signed,
>   use EMACS_INT.

The issue here is that emacs_write and emacs_read are on the boundary:
they accept Emacs Lisp integers, but then call a system API.  Thus the
dilemma what to use in this case, which I resolved in favor of the
system type.  sysdep.c in general uses system types.