Re: [PATCH] strerror_r: simplify AIX code.

[Bruno Haible]

Hi Eric,

> > 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.
> 
> I personally disagree - if I call strerror_r(-12, buf, 17) and get
> ERANGE, then I immediately know that "Unknown error -1" is suspect;  but
> if I get EINVAL, then I've just printed a misleading error number, and
> the only way to tell if I didn't suffer from truncation is to retry with
> a larger buffer until I get an answer with a strlen() smaller than my
> buffer.  That is, if I am going to _guarantee_ that all errors produce a
> non-empty message, I'd much rather prefer learning that my buffer was
> too small until I got my complete non-empty message.

That's a valid scenario.

The scenario I was thinking of is someone who wants to know whether
an errno value is valid. This is a special case of functions that return
multiple pieces of information, and one of them is a string. If ERANGE
takes precedence, the caller needs to provides a large enough buffer for
the string even if he's not interested in the string but only in the
other pieces of information. So,
  strerror_r (errnum, buf, 10) == EINVAL
will no longer be a way to test whether errnum is valid.

But I agree that if ERANGE takes precedence, it makes it easier to write
reliable programs, and it is not a blocker issue for the scenario I imagined.

Bruno
-- 
In memoriam Alfred Grünberg <http://en.wikipedia.org/wiki/Alfred_Grünberg>