On Thu, Dec 01, 2005 at 03:31:41PM -0500, Greg Stark wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Generally speaking looking at errno when you haven't received an error
> > return
> > from a libc function is asking for trouble. It could be leftover from any
> > previous libc error.
> >
> > That's how you get programs saying things like "strtol: No such file or
> > directory" ...
>
> Ah, I take back my taking back of this. It's still dicey to be doing it this
> way -- even if you reset errno before calling the library function.
>
> The problem is that the function can call other libc functions, which may in
> turn return errors. But these errors might be incidental and handled by the
> function you're calling.
I had that concern, as I've seen such incidental errno changes
before. But Tom pointed out the following from SUS:
The strtol() function shall not change the setting of errno if
successful.
Immediately after that the standard says:
Since 0, {LONG_MIN} or {LLONG_MIN}, and {LONG_MAX} or {LLONG_MAX}
are returned on error and are also valid returns on success, an
application wishing to check for error situations should set errno
to 0, then call strtol() or strtoll(), then check errno.
I don't know if any systems are non-compliant in this respect, but
Tom said that "we've been doing it that way (errno test only) for
many years without complaints."
--
Michael Fuhr
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
