Malcolm said:
To ask for the integer value of '~' or 'x' or any non-digit is nonsense.
The question is, what do we want the function to do if that happens?
It depnds what you are doing. if you are writing a video game there is
argument for returning zero and hoping for the best -
No, there isn't. If you are writing a video game, there is no excuse
whatsoever for a non-digit character ever reaching such a function, because
the game-supplied data is tightly controlled and should have been validated
before shipping, and user-supplied data can be restricted at the input
stage so that only appropriate data can be entered. Video games have
considerable freedom in that regard, since they have access to more
sophisticated data capture techniques than are available in standard C.
the worst thing that
can happen is that the game craches anyway,
No, that's just the start of your problems. Here's one possible case that is
worse: the player, who happens to be highly influential in the marketplace
(perhaps he's a well-known and much admired reviewer) says "it crashed!
What a lame game - I'm never buying from /that/ company again, and I'm
going to tell everyone else /why/, too".
probably you'll just get a
tiny error on screen most players won't notice.
You'd be amazed at what players notice - especially since many modern video
games are so fast-paced that players /have/ to be able to notice tiny
things very quickly if they are to do well at the game. For example, in a
driving game my son plays, he can spot instantly whether a car in the
distance is a police car, without the benefit of sirens and lights!, by the
presence or absence of a *single pixel* representing the (unlit) roof lamp.
He would be very likely to spot an anomaly caused by a bug in the program
(and often does).
If you are doing accounts software, on the other hand, the last thing you
want is for a wrong value to get into your database. Better far to trigger
an error.
Normal practice in interactive programs is to alert the user and allow
re-entry. In batch mode, perhaps a bank's overnight run, the error is
logged. If processing can continue, it does. Otherwise, a message is
written on the operator's console, and operators ignore such messages at
their peril.
If you are writing software for a life support machine?
You get it right, or someone dies.
assert() is the C way of checking parameters.
No, it's the C way of allowing the programmer to test his assumptions, and
(perhaps) prove them to be false.
It always triggers an error under debug conditions, which is what you
want.
Well, nearly. It always triggers an error when NDEBUG is not defined and the
assertion condition fails, provided no undefined behaviour has got in the
way beforehand.
Here's how Edward Nilges uses his function
*intValue = *intValue * 10 + intCharValue;
if ( *intValue < 0 ) return 0; }
return -1;
}
Overflow is not terrible?
but the difficulties in reading it mount as error
returns are propagated upwards. One function returns a negative number on
error, another returns zero. Fortunately the program is short enough for
this not to really matter.
Yes. In a larger program, consistency would greatly help the maintainer.
Most importantly, every call has an error check anyway. So why not make
the check validate the parameters rather than test the return?
Yes, that would work - e.g.
if(isdigit((unsigned char)ch)
{
n = RidiculousFunctionToSubtractAZeroDigitFrom(ch);
DoSomethingWith(n);
}
else
{
Handle the error
}
But a far better approach can be found on K&R2 page 252.
