Hi Eric,
> @@ -95,6 +95,15 @@ int
> strerror_r (int errnum, char *buf, size_t buflen)
> #undef strerror_r
> {
> + /* Filter this out now, so that rest of this replacement knows that
> + there is room for a non-empty message and trailing NUL. */
> + if (buflen <= 1)
> + {
> + if (buflen)
> + *buf = 0;
> + return ERANGE;
> + }
> +
> #if GNULIB_defined_ETXTBSY \
> || GNULIB_defined_ESOCK \
> || GNULIB_defined_ENOMSG \
This is odd and inconsistent.
errnum = -3, buflen >= 2 -> return EINVAL
errnum = -3, buflen <= 1 -> return ERANGE
Also it seems strange to introduce new code for all platforms,
from FreeBSD to Cygwin, with the rationale that it's a simplification
for AIX.
I would not have done this. Rather, since the caller does not know
in advance how long the string will be (i.e. how long the buffer needs
to be for a complete message), that ERANGE should be the "lowest priority"
error. That is, I think EINVAL should take precedence over ERANGE.
Also remember that if we have to workaround bugs such as
strerror_r:
This function always fails when the third argument is less than 80 on some
platforms:
HP-UX 11.31.
snprintf:
This function overwrites memory even when a size argument of 1 is passed on
some
platforms:
Linux libc5.
This function overwrites memory even when a zero size argument is passed on
some
platforms:
OSF/1 5.1.
ttyname_r:
This function refuses to do anything when the output buffer is less than 128
bytes large, on some platforms:
Solaris 11 2010-11.
getlogin_r:
This function fails with error code EINVAL instead of ERANGE when
the second argument is zero on some platforms:
HP-UX 11.31.
then it is because these system functions were coded with the "let's check the
size upfront" philosophy. And now you introduce the same, broken idiom here?
Bruno
--
In memoriam Jan Bula <http://en.wikipedia.org/wiki/Jan_Bula>
