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

[Paul Eggert]

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).  So any signature will do; it really doesn't matter.
The old signature worked; the new one works; and making
the signature compatible with ordinary 'read' and 'write'
would also work.  Of these choices, I mildly prefer using
the 'read' and 'write' signature since that's what C
programmers would expect; and second would prefer
going back the way it used to be (using the argument that
if it wasn't broken, why fix it....).

To some extent this discussion is a proxy for what the
internal coding style of Emacs should be, for integers.
Here are some suggestions:

* 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.

* Use EMACS_UINT only when EMACS_INT would yield undefined
  behavior due to integer overflow.

* If overflow is possible when calculating values of a type,
  e.g., when converting from one type to another, then
  check this at runtime.

I realize these guidelines are often violated (particularly the
last one :-), but using them would help make Emacs internals
more reliable.