Re: strtonum(3) from OpenBSD?

[Iain Hibbert <plunky%rya-online.net@localhost>]

On Fri, 26 Jun 2009, David Holland wrote:

> On Fri, Jun 26, 2009 at 12:02:12PM +0100, Iain Hibbert wrote:
>  > > If it *can* set errno on success, which is the usual convention for
>  > > library functions,
>  >
>  > Nonsense, that is no usual convention. Please read errno(2) and see what
>  > it says (try the second paragraph in the DIAGNOSTICS section)
>
> Yes, precisely. Did you read your citation before posting it? (Or did
> you misunderstand what I wrote because you assumed I didn't know what
> I was talking about? :-p )

Yes I read it, can you explain how you translate "Successful calls never
set errno" into setting errno on success being the "usual convention"?

> Unless strtol is specifically granted permission to clear errno to 0
> after calling other functions, which it isn't in C99 (don't have POSIX
> on hand) there's a problem.

The problem is worked around by the specification saying that if you want
to check that ERANGE is not set then you should reset errno first.

> There's also possibly an issue that C99 does not specifically say that
> endptr is set on the overflow failure case, so in principle one ought
> to test for that case before touching it. (Which is also unlike the
> example in strtol(3).)

The manpage (and the one at www.opengroup.org) specifically states that
all the characters that are valid digits will be processed, and that
endptr will be set to the remaining string. I don't have any C99 but I
can't see such a glaring difference being used.

> It's too bad they didn't define the overflow case to return with
> endptr pointing at a digit. That would make things a lot easier in the
> common cases.

The specification cunningly allows for overflow to be ignored in a "safe"
manner.

>  > > there's no fully safe way to distinguish an overflow from a valid return
>  > > of LONG_MAX or LONG_MIN. But if one's going to try, one should properly
>  > > test the return value before errno, unlike the example in strtol(3).
>  >
>  > I think so too, but it doesn't actually matter in practice as both
>  > conditions need to be met anyway.
>
> What if some failing (and defective) internal call leaves a trap
> representation in errno? I can never remember if signed integers are
> allowed to have trap representations, but -0 on a sign/magnitude
> machine is a legitimate candidate.

Well perhaps the people who wrote the the example code took that into
account when they had it checking the errno value first, eh?

iain