Greg Stark <gsstark@MIT.EDU> 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.
The typical case of this is calling printf which first calls isatty(). printf
then returns success but leaves errno set to ENOTTY. And programs that check
errno without checking the return valule -- even if they clear it before
calling printf -- mysteriously print "Not a Typewriter" after correctly
printing the data.
The SUS standard protects against this though by only allowing this to happen
for functions that don't themselves use errno to signal errors:
The value of errno may be set to nonzero by a library function call whether or not there is an error, provided the use
oferrno is not documented in the description of the function in this International Standard.
Older platforms may still have this behaviour, but strtol seems like a pretty
innocuous case. It's hard to imagine strtol needing to call much else. And
strtol was an ANSI addition so one imagines most platforms got it right from
the beginning.
--
greg