Portability of idiom

[Nathan Myers]

On Tue, Jan 29, 2002 at 06:51:52PM -0600, Loren James Rittle wrote:
> Depending on exactly how one interprets this C99 standard passage:
> ``The value of errno may be set to nonzero by a library function call
> whether or not there is an error, provided the use of errno is not
> documented in the description of the function in this International
> Standard.'', I could see it go either way.  strtod() is documented by
> standard to use errno but it is only documented to ever set it to
> ERANGE under some overflow/underflow conditions.  Thus, if it
> magically sets errno, e.g. to EINVAL because of a nested library call,
> did this implementation of strtod() violate the standard?

To me the meaning is dead clear.  It's no business of the user's
what other functions a standard function uses to get its job done.  
The user deserves to have the spec met, without excuses.  The 
standard gives no license to violate the spec just by (e.g.)
invoking undefined behavior.

If strtod uses something else that might clobber errno, it's 
strtod's job to save the value, and either restore it or set 
it to ERANGE.
 
> Either way, at some point, this line was added to the FreeBSD
> implementation of strtod:
> 
>   char decimal_point = localeconv()->decimal_point[0];
> 
> In this environment, the call to localeconv() can set errno to EINVAL
> and thus the behavior of this user-level code changed (4.4 returns 0,
> CURRENT returns EINVAL):

If in fact the usage in this case may set errno (and it may be that the
author is certain that it can't!), then this is just a buggy libc.  
Sometimes we may have to work around a buggy libc, but let's not 
pretend it's OK.  Maybe we should abort if we get a disallowed errno 
value, unless it's one that configure has identified as a known bug 
on the target.

Nathan Myers
ncm at cantrip dot org