On Wed, Jun 23, 2004 at 05:40:16PM +1000, Luke Mewburn wrote:
> On Wed, Jun 23, 2004 at 03:02:44AM -0400, Greg A. Woods wrote:
>   | [ On Tuesday, June 22, 2004 at 09:57:41 (+0200), Alan Barrett wrote: ]
>   | > Subject: Re: tales of woe from the recent tools/compat_defs.h pullups on netbsd-1-6
>   | >
>   | > strtoul() and friends are documented to set errno = ERANGE on overflow.
>   | > I had a quick look at the implementation, and don't see any obvious
>   | > bugs.  So you should be able to do something like this:
>   | > 
>   | > 	errno = 0;
>   | > 	result = strtoul(...);
>   | > 	if (result == ULONG_MAX && errno == ERANGE) {
>   | > 	   ...
>   | > 	}
>   | 
>   | Hmmm....  I suppose so.  I'm just _really_ leary about setting errno
>   | before making a library call and then expecting it to only be changed
>   | iff there's an error, even I use a "special" result in that way as a
>   | hint to check errno only when it might be necessary to do so.
> 
> Well, that's the C99 & POSIX standard for you.
> 
> Per IEEE Std 1003.1, 2004 Edition for strtoul():
> 	Since 0, {ULONG_MAX}, and {ULLONG_MAX} are returned on error
> 	and are also valid returns on success, an application wishing
> 	to check for error situations should set errno to 0, then call
> 	strtoul() or strtoull(), then check errno.
> 
> strtod() and strtol() have similar statements.
> 
> 
>   | (and thats without even considering the implications of errno in a
>   | threaded environment!  ;-)
> 
> Don't the pthreads standards actually deal with the "special" case
> that is errno, and provide it as a per-thread item that is a
> modifiable int?
> 

That's the common implementation as 

errno = 0;
<some function call>
<test errno value>

is common and perfectly valid, so threading models try hard not to completely
break that mindset.  IIRC it's also the only way to be guarenteed
of not possibly getting the wrong errno as I don't believe all functions are
required to set errno to 0 if they didn't produce an error.

James