Date: Sat, 22 Jan 2005 20:17:43 +0300 From: Andrey Chernov <ache@nagual.pp.ru> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: current@freebsd.org Subject: Re: Implementation errors in strtol() Message-ID: <20050122171743.GB39943@nagual.pp.ru> In-Reply-To: <20050122113015.GV30862@uriah.heep.sax.de> References: <20050121194103.GB19150@nagual.pp.ru> <20050121201400.GQ30862@uriah.heep.sax.de> <20050121221156.GA21459@nagual.pp.ru> <20050120192324.GA30862@uriah.heep.sax.de> <20050120205501.GA69123@nagual.pp.ru> <20050120211449.GC30862@uriah.heep.sax.de> <20050120214406.GA70088@nagual.pp.ru> <20050120222137.GE30862@uriah.heep.sax.de> <20050121230949.GA34313@VARK.MIT.EDU> <20050122113015.GV30862@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050122171743.GB39943>