Re: strerror_r questions

[Corinna Vinschen <vinschen at redhat dot com>]

On Feb 10 09:54, Eric Blake wrote:
> On 02/09/2011 05:43 PM, Eric Blake wrote:
> >> Shoot - I missed another POSIX requirement:
> >>
> >> "The implementation shall behave as if no function defined in this
> >> volume of POSIX.1-2008 calls strerror( )."
> >>
> > Reading further, POSIX states the reason for that requirement:
> > 
> > "Historically in some implementations, calls to perror( ) would
> > overwrite the string that the pointer returned by strerror( ) points to."
> 
> Proposal: would anyone object if I changed the semantics of
> _user_strerror?  Right now, it is documented as:
> 
> char *_user_strerror(int errnum);
> 
> where errnum is unhandled by newlib proper, and the result is NULL if
> the hook also declines handling, or an alternate string used directly
> (therefore, one can write _user_strerror to provide "unknown error %d"
> formatting into thread-safe storage).  However, this means that use of
> _user_strerror either renders perror() non-compliant, since
> _user_strerror reuses the same storage on each call, or that it is a
> memory leak with _user_strerror returning new storage on each call.  I'm
> proposing that we change the signature of the hook to:
> 
> char *_user_strerror(int errnum, int from_strerror)
> 
> where the from_strerror argument is 0 for all callers except strerror().
>  I'm also proposing adding _strerror(int errnum, int strerror) which all
> other newlib clients (such as perror()) will call as _strerror(err,0),
> but strerror() will call as _strerror(err,1).
> 
> ABI wise, existing implementations of _user_strerror that take one
> argument will ignore the second argument, so it is a backward-compatible
> API change.  Meanwhile, this would allow others to implement
> _user_strerror in such a way that keeps the rest of newlib
> POSIX-compliant - returning two different banks of storage depending on
> the from_strerror argument, so that no other function overwrites the
> bank of storage returned by strerror(); it would also allow strerror()
> to set errno to EINVAL via _user_strerror while leaving errno untouched
> for strerror_r.

That sounds ok.  As long as _user_strerror just returns a pointer to a
constant string value it's no problem, but as soon as the function
copies over an error string into some static storage it doesn't comply
to POSIX anymore.

If nobody has a strong argument against this proposal within a week or
so, I guess you can just go ahead.  Please don't forget to enhance the
documentation.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat