standards/151316: lib/libc/string/strerror.c r1.9 breaks POSIX

[Jilles Tjoelker]

The following reply was made to PR standards/151316; it has been noted by GNATS.

From: Jilles Tjoelker <jilles at stack.nl>
To: Jeremy Huddleston <jeremyhu at apple.com>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: standards/151316: lib/libc/string/strerror.c r1.9 breaks POSIX
Date: Sat, 9 Oct 2010 14:37:31 +0200

 On Fri, Oct 08, 2010 at 04:28:55PM +0000, Jeremy Huddleston wrote:
 > >Number:         151316
 > >Category:       standards
 > >Synopsis:       lib/libc/string/strerror.c r1.9 breaks POSIX
 
 > >Description:
 > r1.9 of strerror.c did the following (from the changeslog)
 
 > strerror()'s semantics have changed slightly such that an argument of
 > 0 is now considered invalid and errno is set to EINVAL.
 
 > This introduces a regression in SUS conformance.
 
 Please explain why. As far as I understand, 0 is not a valid error
 number, and therefore it is appropriate to set errno = EINVAL while
 still returning a string.
 
 Hints to 0 being an invalid error number are the requirement that all E*
 constants from <errno.h> be positive and the requirement that no
 POSIX-defined function shall set errno to 0.
 
 If I'm wrong, please provide a reference such as to a specific section
 in the standard.
 
 In any case, this is of little practical effect since few programs check
 the value of errno set by strerror(). If the patch is accepted,
 sys_errlist[0] will probably be changed to "Unknown error: 0" so the
 only difference is errno set by strerror().
 
 > >How-To-Repeat:
 
 > >Fix:
 > In strerror.c's strerror_r
 > -	if (errnum < 1 || errnum >= sys_nerr) {
 > +	if (errnum < 0 || errnum >= sys_nerr) {
 
 > And here's a man page change:
 
 > @@ -110,7 +118,7 @@
 >  .Er EINVAL
 >  as a warning.
 >  Error numbers recognized by this implementation fall in
 > -the range 0 <
 > +the range 0 <=
 >  .Fa errnum
 >  <
 >  .Fa sys_nerr .
 
 -- 
 Jilles Tjoelker