Implementation errors in strtol()
Andrey Chernov
ache at nagual.pp.ru
Sat Jan 22 09:17:46 PST 2005
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/
More information about the freebsd-current
mailing list