[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: strtonum(3) from OpenBSD?
On Fri, Jun 26, 2009 at 09:09:25PM +0200, Joerg Sonnenberger wrote:
> On Fri, Jun 26, 2009 at 06:20:15PM +0000, David Holland wrote:
> > 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 POSIX version is explicit that it will not touch errno on success.
> It also gives explicitly the errno = 0 + strtol idiom.
Ok, what I can find says
The strtol() function shall not change the setting of errno if
which is specific permission to assign to it on success, in order to
preserve the previous value.
This guarantee does not appear to be provided by C99.
However, back to my original point, given this guarantee there's no
need to check the return value to test for overflow.
> > 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.
> I don't think so. Overflow is detected by errno value, period. I think
> you want to make the interface worse than it is for no good reason.
I'm not convinced that would make it worse; then you could check
unambiguously for problems by inspecting endptr.
Although I suppose if you find that *endptr contains 'f', you passed 0
as the base, you expect to continue on from endptr rather than
consuming the whole string, *and* you legitimately expect to see two
input tokens in the form "0700foo", you end up in a bit of a hole.
I'm not sure I've ever seen real code that continues onward from
endptr. But anyway...
> > What if some failing (and defective) internal call leaves a trap
> > representation in errno?
> I can't find anything in the C standard that allows setting errno for
> integer arithmetic.
That's not what I said.
David A. Holland
Main Index |
Thread Index |