Re: [PATCH] strerror_r: simplify AIX code.

[Bruno Haible]

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>