Re: Implementation errors in strtol()

On Sat, Jan 22, 2005 at 12:30:15PM +0100, Joerg Wunsch wrote:
> Nope.  Just think about it: code which doesn't take this feature into
> account needs to check for conversion errors by means of verifying
> endptr.  It simply wouldn't care about errno at all, except for
> possibly checking for overflows -- which only needs to be verified
> after it is already clear from checking endptr that the conversion was
> OK.  Thus, errno could not possibly be EINVAL anymore in that case.

I know portable way of doing that. You describe one case from two. The 
another case you miss is more indirect: portable application which set 
"errno = 0" before calling strtol() to detect overflows (it is only method) 
even after checking that endptr moved can't check just

if (errno) { ... }

but must check

if (errno == ERANGE) { ... } 

instead.

That is, what I mean, saying that portable application should consider 
_both_ cases.

> implementation, the more in that the FreeBSD man page (unlike systems
> like Solaris or Linux that simply quote the SUSP man page) explicitly
> states that EINVAL is returned for conversion errors, without
> mentioning that this feature is not portable as it employs a ``may''
> clause from SUSP.

This situation could be improved. I'll look into that.

> > At those time I don't remember any "against" votes.
> 
> Well, Bruce wrote me that he was opposed to it even by that time.

Strangely, my memory says me other things - he will help me with polishing 
strtol() at those time with that and other aspects. Perhaps his opposition 
was too soft to be detected?

> I know that Posix/SUSP basically interprets it that way, but I think
> the second sentence in paragraph 3 of 7.5 is ambiguous, as that I
> would interpret it as an explicit statement that for any function
> where the use of errno is documented as part of the [C] standard,
> errno must not be set in another way than documented.  This would
> prohibit setting errno to EINVAL for strtol(), as the possible errno
> modifications are documented for strtol() (either undmodified, or set
> to ERANGE).

POSIX pretends to be part of C standard (sort of), saying that conflict 
you may see is not a conflict :-) Here is full quote:

"Extension to the ISO C standard
The functionality described is an extension to the ISO C standard.
Application writers may make use of an extension as it is supported on all
IEEE Std 1003.1-2001-conforming systems.

With each function or header from the ISO C standard, a statement to the
effect that ``any conflict is unintentional'' is included. That is
intended to refer to a direct conflict. IEEE Std 1003.1-2001 acts in part
as a profile of the ISO C standard, and it may choose to further constrain
behaviors allowed to vary by the ISO C standard. Such limitations are not
considered conflicts.

Where additional semantics apply to a function or header, the material is
identified by use of the CX margin legend."

-- 
http://ache.pp.ru/