Mail Archives: djgpp/2013/07/31/00:38:38
Georg Potthast writes:
> I still feel it would be a better "user experience" if atoi() would
> not crash. As far as I understand the specification does not
> require atoi() to crash if a NULL pointer is passed.
No, it doesn't. But "not crashing" is not necessarily a better end
user experience, although it may allow a programmer to save a few
lines. It is not possible to give a consistent specification of what
happens when NULL is passed to a function, because by definition (C
standard) there can be no valid data pointed to by that pointer.
Therefore any behavior is necessarily arbitrary.
If you chose to avoid the crash via OS trap by testing for the special
case and returning 0, you may be screwing the end user by covering up
a bug. The NULL pointer comes from somewhere; surely, the literal
expression "atoi(NULL)" is very rare in your programs. So most likely
some other function is failing to do its job.
The DJGPP implementation is therefore functionally equivalent to
assert(cp);
return atoi(cp);
which identifies the bug earlier (perhaps much earlier) than doing a
postmortem analysis on a corrupted database, for one example. It
encourages defensive programming:
if (cp)
return atoi(cp);
else
/* Reproduces True64 behavior.
More complex error recovery is easily substituted. */
return 0;
which is pretty much universally recommended by coding standards,
although programmers often don't bother. Sometimes, where all callers
have been verified, the overhead of the check can be avoided
completely. This is a performance improvement, in accordance with the
general philosophy of C that it's the programmer's responsibility to
assure correctness at any level above machine language, while the C
compiler provides the most efficient but correct implementations
possible for its constructs.
If you really like the "safe" behavior, it's trivial[1] to accomplish
efficiently by defining a tiny function (modern compilers will almost
certainly inline it, which will be a tiny bit faster than implementing
the branch in the function, since in the NULL case the function call
overhead is avoided).
Footnotes:
[1] In a one-file program. In a multi-file program getting this to
work without defining the function many times is wizard's work. Of
course, if you're confident that your compiler will inline it, that
doesn't matter. Or you can change the signature and use a macro.
- Raw text -