Date: Sun, 23 Jan 2005 23:47:55 +0100 From: Joerg Wunsch <j@uriah.heep.sax.de> To: Giorgos Keramidas <keramida@freebsd.org> Cc: current@freebsd.org Subject: Re: Implementation errors in strtol() Message-ID: <20050123224755.GK30862@uriah.heep.sax.de> In-Reply-To: <20050123221630.GB22234@gothmog.gr> References: <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> <20050122171743.GB39943@nagual.pp.ru> <20050123143024.GA28604@gothmog.gr> <20050123211656.GB64754@nagual.pp.ru> <20050123221630.GB22234@gothmog.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
As Giorgos Keramidas wrote: > If errno is explicitly set (i.e. zeroed) by the calling program > immediately before strtol(), can we not be sure that it was, in > fact, strtol() that set it to any non-zero value? Andrey meant that an application shouldn't blindly assume that errno == ERANGE, as other extensions to the standard could allow setting errno to other values for other errors. However, this immediately reminded me of Steinbach's Guideline for System Programming. ;-) (-> fortune -m Steinbach) At least according to C99/Posix/SUSP, once you've caught conversion errors (by means of looking whether endptr had been advanced), and if you are sure that base had a legitimate value (as it is probably a hardcoded value in almost any practical application of strto*l), the only legitimate errno value remaining is ERANGE, as after a valid conversion and with a correct base value, there's no chance for EINVAL anymore. Sure, you can check whether errno != 0 && errno != ERANGE, but see Steinbach, what to do in that case? abort() ;-) I think Andreay always thought it the other way round, first test errno, and only if errno == 0, test endptr. But see above, testing errno for EINVAL can be completely skipped when done properly. That's why I think that the entire EINVAL thing is completely pointless. It would have only been meaningful in any way if SUSP had mandated it to be set in case of a conversion error (and even then, only applications that rely on SUSP extensions over C99 could have relied on it). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050123224755.GK30862>