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

[Bruno Haible]

Jim Meyering writes:
> But isn't it valid to call read with a length of 2^31 or larger?

Good question. POSIX:2001 (at
http://www.opengroup.org/onlinepubs/007904975/functions/pread.html)
says:

  If the value of nbyte is greater than {SSIZE_MAX}, the result is
  implementation-defined.

What does this mean, in practice? Paul?

> IMHO, read's prototype is not well designed, since code using
> it often ends up comparing the buffer length (of type size_t)
> with the returned value (of type ssize_t).

I agree with you that read's prototype is not well designed. But it's
better to follow a standard way of doing things, if it's not too much
broken, especially if the standard is very well-known - than to do
things in a not so common way.

Similarly, you would have less problems using the <ctype.h> and putc()
functions if strings were 'unsigned char *', not 'char *'. But the
commonly accepted way is to use 'char *' for strings, even if it
requires some casts.

> But what if nbytes is 2^32 - 1?
> Then on some systems, the RHS will evaluate to -1.

"implementation-defined", see above.

> The important thing for me is to keep the code (that
> calls functions like safe_read) clean, and that means
> avoiding casts whenever possible.

I think gcc's "comparison between signed and unsigned" warning is
bogus. I've checked all places in gettext where gcc emits this
warning, and all of them were harmless, because counters and .mo file
sizes and such never reach 2^31.

So I recommend to just turn off this warning.

Bruno