Re: [Bug-gnulib] safe-read.[ch] (safe_read): what do you think?

[Bruno Haible]

Paul Eggert writes:
>     read more than SSIZE_MAX bytes, which is a no-no as described
>     above.  Also, it runs into a bug in Tru64 5.1, which can't read
>     more than INT_MAX bytes at a time (and where INT_MAX < SSIZE_MAX).

OK, in that case safe_read must internally bound the number of bytes:

      nbytes = MIN (nbytes, MAX_BYTES_TO_READ);

and all my reasoning about the read() system call is bogus.

>  3. block_read is guaranteed to always return nbytes unless end-of-file
>     or error; it retries if it gets a short read.  In contrast,
>     safe_read returns whenever it successfully reads any bytes.

Indeed I think we need both of these functions, but I would rename
block_read to full_read, for consistency with full-write.c (and the
"block" is not a disk block, just some memory buffer).

We need both, because:

  - One cannot simply replace all calls to full_read with safe_read:
    the calling code may not be prepared to partial returns.

  - One cannot simply replace all calls to safe_read with full_read:
    it leads to the long-time 'patch' bug where the user has to type
    Ctrl-D twice in order to signal end-of-file.

> But perhaps we should establish a new .h file (readwrite.h?) to
> contain the union of block-read.h, safe-read.h, and full-write.h?

I'm in favour of a 1:1 relationship between .h and .c files. It makes
things simpler when copying files from gnulib and also when merging
changes back into gnulib. (Example: do you remember which .h file
belongs to addext.c?)

Bruno