Re: Writing bulletproof code

From: Paul Hsieh (qed_at_pobox.com)
Date: 01/03/04 

Date: 3 Jan 2004 01:35:27 -0800

Les Cargill <lcargill@worldnet.att.net> wrote:
> Paul Hsieh wrote:
> > You have it reversed. If you do all the checking, then the user of
> > your module/library doesn't have to. If you instead adopt the
> > attitude that Ken, Dennis and Brian adopted and simply pushed all
> > error checking to the end user, then its as if you are encouraging
> > flawed coding to spring forth. But you assume its ok, because you can
> > always point your finger at the other programmer for not being
> > perfect.
>
> This is fundamentally flawed. strcpy() et al are services. [...]

No ... strcpy is at best a beginner's exercise. I mean before a
student learns about algorithm complexity or have any sense about
performance or design.

> [...] Each comes with constraints and caveats as to its proper use.
>
> As a simplifying assumption, these functions do not necessarily
> perform all possible error checks.

Again, we need to correct your statement. These functions perform no
error checks at all. I repeat, there is *NO* error checking of
anything inside of the C library (or at best its option, and generally
not seriously in existence in typical C compiler implementations.)

> [...] This is because they may be used differently by different people.
> They provide the absolute minimum functionality possible.

These two statement are not congruent. And these "different people"
don't include people who care about safety.
 
> One of the basic precepts of software design *is* to push error
> checking to the highest possible level.

That's horse-cocky. Good software design requires that you put error
checking where there is the highest likelihood of error -- plain and
simple. Arbitrary decisions like pushing checking at "high levels"
will have arbitrary impact on their effectiveness. No error checking
at all just means that any usage which includes a non-zero probability
of misuse (i.e., using humans as programmers) will definitively lead
to errors that could otherwise have been detected or naturally
avoided. Which part of this is not dead obvious?

> [...] For some services, this is not possible, so there are error returns
> from functions which express failure conditions.

You have to be kidding me. You could put error checks in all sorts of
places -- they just chose not to.
 
> > > If the function is never called by anyone but yourself then you just need
> > > to understand what inputs are valid and ensure you never use bad inputs.
> >
> > What you need is a sound model for what you are doing, and a
> > sanity/unit test of some kind to make sure its ok.
>
> Right. And that is more appropriate in the less general context
> of an application, not necessarily a library.

You don't need testing for a library?!?!
 
> > Correction -- it does not validate anything. Most C compilers I know
> > of happily square root negative numbers, divide by 0, derefence NULL
> > pointers, call free() on auto-arrays or function pointers etc, -- only
> > the OS/CPU exceptions keep these from going unnoticed. The C library
> > is not something that can be put forward as anything that was
> > seriously *designed* much less the standard for bullet-proof code.
>
> But it *was* seriously designed. Read of the philosophy and history of
> the 'C' language and the libraries.

And if I read these histories will I get an explanation for gets(),
why none of the varargs functions never have const on the varargs
parameter, why strtok is not re-entrant? Multitasking may not have
existed back then, but re-entrancy definately did.
 
> I'd just say you don't agree with the philosophy used to design it.
> That's fine, but it doesn't mean "everybody else is wrong".

Everybody else? And just who is everybody else? Do these people
include those who have abandoned C in favor of Java, Perl, Python and
Visual Basic?
 
> > Documentation only gives a well defined way of pointing your finger at
> > someone. It doesn't actually solve the problem that programmers are
> > going to write bugs in their code.
>
> No, documentation provides a means of explaining the proper use of a
> set of tools. Programmers themselves cnanot be releived of the
> responsibility to link the things they have together into a correct system.

And what blame can be applied to library designer? None? The C
library documentation says "here's your straight jacket, now put it on
and juggle".
  
> You can chip ice with a screwdriver, but an icepick works better.

And if you don't have an icepick, and you have been indoctrinated to
believe that the screwdriver is just as good?

> > > The toughest area for guarding is end-user input [...]
> >
> > http://www.pobox.com/~qed/userInput.html
>
> While that is a step in the right direction, in almost all cases of
> editting user input which I have seen in real-world applications,
> even more stringent constraints are required. A gets() replacement
> does not serve as a full on edit checker. I've developed curses
> type subsystems which had full on edit checking, and while it's
> not too difficult, it is not trivial.

You skipped the part where I discuss input tainting.
 
> > But for some reason, very few know when the cost will be negligible
> > versus the potential massive benefit.
>
> But the cost should be borne by those who know they need it, not
> by all people who use a service.

The cost must be measured first. If it costs nothing, why wouldn't
you put it in there? Now try applying this statement to the following
well known rule of thumb: 90% of the performance of any software is
isolated to 10% of the code. Does this not suggest that one can cover
90% of one's code with little or no impact on performance?
 
> I've actually seen at least one guy who could not understand this
> concept, [...]

As opposed to the hords of nameless programmers who will live on in
infamy in reams of CERT advisories, and Security Focus analyses. 

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/