Date:        Tue, 21 Sep 1999 11:23:35 +1000
    From:        Luke Mewburn <lukem@goanna.cs.rmit.edu.au>
    Message-ID:  <199909210123.LAA16857@wombat.cs.rmit.edu.au>

  | There may be cases in your code that you can't test fully until the
  | program has been running for a long time. As long as your code checks
  | the return values of functions, then at least it has a chance to
  | recover.

If you're sure that the code is going to be that well written, then it
can just as easily be also doing "if (arg == NULL)" type tests before
calling the library routine.   In practice, most code that tests library
return values already "knows" what the cause of an error will be "if this
returns an error it means the file wasn't there to be opened, or there
was no permission to open it", I have yet to meet the programmer who
thinks "if this returns an error it might mean that I was an idiot and passed
it a null pointer instead of a file name".    That "knowing" of what the
error means tends to influence the behaviour that follows when an error is
detected - in a case like this, what may happen is that your embedded
application may go into an endless loop telling the user that some important
file doesn't exist, and asking for a replacement file name - failing in
exactly the same way whatever name is given (which can then lead the
end user into a long search for problems in the filesystem or with the
hardware, instead of just realising that the application is broken).

There are no shortcut answers to truly robust code.   Further, having the
library return "you gave me a NULL pointer you idiot" type error codes
doesn't help at all unless you're quite certain that the only thing that
the program is ever going to do with that arg value is pass it to a
library routine.   If it is going to be tested for null, then the extra
checking in the library routine is just wasted.   If it is going to be used
other than as an arg to a library routine, then the program is going to
dump core (or whatever that means in an embedded system) anyway, and having
the library routine carefully avoiding crashing isn't really much use as
far as robustness goes.

Even more, chances are that the tests added were for just one (perhave most
common) invalid arg case, to be truly robust you'd have to check that the
pointer passed was a sensible one (aligned properly, etc) and within the
address space of the application (a core dump from *0xdeadbeef isn't really
any better than a core dump from *0 if avoiding core dumps is the aim).

I know I am continuing flogging the dead horse, as the relevant code has
been removed again, but I thought this might be useful to say anyway.

kre