[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] strerror_r: simplify AIX code.

From: Bruno Haible
Subject: Re: [PATCH] strerror_r: simplify AIX code.
Date: Sat, 21 May 2011 00:50:49 +0200
User-agent: KMail/1.9.9

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


  This function always fails when the third argument is less than 80 on some
  HP-UX 11.31.


  This function overwrites memory even when a size argument of 1 is passed on 
  Linux libc5.

  This function overwrites memory even when a zero size argument is passed on 
  OSF/1 5.1.


  This function refuses to do anything when the output buffer is less than 128
  bytes large, on some platforms:
  Solaris 11 2010-11.


  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?

In memoriam Jan Bula <http://en.wikipedia.org/wiki/Jan_Bula>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]