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>