At Wed, 1 Jul 2009 15:28:41 -0400 (EDT), der Mouse
<mouse%Rodents-Montreal.ORG@localhost> wrote:
Subject: Re: strtonum(3) from OpenBSD?
>
> >> [...], but it does matter which test is done first if errno might
> >> contain a trap representation.
> > I meant in the strict ordering of terms in the test expression(s).
>
> > if (errno == ERANGE && rval == LONG_MAX)
>
> > if (rval == LONG_MAX && errno == ERANGE)
>
> These are not equivalent if errno might contain a trap representation
> for non-LONG_MAX returns. (Because of strtol()'s special case for
> errno, this can happen only if it was that way on entry.)
What exactly do you mean by "trap representation" in this context --
that's not normal terminology I'm aware of for the _C_ Programming
Language. It's certainly not something that applies to ISO C89 or ISO
C90 so far as I can find.
(and for this new invention called C99 the best I understand "trap
representations" to mean only apply to lvalues, not rvalues, but anyway
the code we're talking about here is normal plain old C, not some newly
invented language, especially not if it violates very long-standing
rules about evaluation of normal expressions)
> Not necessarily _arithmetic_ operation. There is no guarantee that
> strtol() and friends are leaf routines, and, indeed, it's not
> implausible that they may do something (like locale setup) which may
> leave relatively unpredictable trash in errno.
Hmmm.... equally pedantically, but what do the currently applied
standards have to say about undocumented errno values, especially in
this case of an interface which specifically requires errno to be
cleared of garbage values before it is called? I seem to recall that
such behaviour is allowed for the most part, but when as you say the
interface contract must make special mention of errno I would expect the
requirements for its value upon return to be equally well specified.
For example NetBSD's strtol() may violate the standard by returning with
errno set to the undocumented value of EINVAL.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgpdfFzeG4evR.pgp
Description: PGP signature