Re: Writing bulletproof code
From: Les Cargill (lcargill_at_worldnet.att.net)
Date: 01/03/04
- Next message: Guillaume: "Re: What IS Intelligence"
- Previous message: Oelewapperke: "Re: Academic research aimed at improving programmer productivity?"
- In reply to: Paul Hsieh: "Re: Writing bulletproof code"
- Next in thread: Paul Hsieh: "Re: Writing bulletproof code"
- Reply: Paul Hsieh: "Re: Writing bulletproof code"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 03 Jan 2004 02:29:58 GMT
Paul Hsieh wrote:
>
> darrell@NOMORESPAMcs.utoronto.ca.com (Darrell Grainger) wrote:
> > On Thu, 1 Jan 2004, The Directive wrote:
> > > How do you make your code bulletproof? For example, I make my function
> > > bulletproof by validating every argument passed to the function. I
> > > ensure the arguments are within the expected ranges. This causes
> > > multiple validation at different levels and so there's a slight
> > > decrease in performance (since these checks ship with release code). I
> > > could turn off these checks (asserts) for release code but it would
> > > not protect the code from unexpected conditions since it's impossible
> > > to test every possible condition.
> >
> > Efficiency is part of good coding. If you do too much checking then you
> > are like a government that has too much unnecessary paperwork.
>
> 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. 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. This is because they may be used
differently by different people. They provide the absolute minimum
functionality possible.
One of the basic precepts of software design *is* to push error
checking to the highest possible level. For some services,
this is not possible, so there are error returns from functions
which express failure conditions.
> > > My professor says that this is bad design. He says I should design
> > > according to specs and not include so much validation. What do you
> > > think? How do you make your code solid? How do you test your code and
> > > ensure quality? Any advice or ideas are appreciated.
> >
> > If you have a library of functions you can protect them one of two ways.
> > The first is what you are planning. Validate everything. The second is to
> > document it well and trust that who every is using it will use it
> > properly.
>
> The second has very little meaning to me. Programmers are people --
> they are limited by their abilities and their requirements.
> Documenting the code does not remove their failings, it only gives you
> a way of articulating exactly how they have failed after they have
> done so.
>
> > 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.
> > If the function is to be used by someone else (or you are on a team and
> > someone else might inherit your code) then document it well. Case in
> > point, the standard C library does not valid everything.
>
> 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.
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".
> > [...] If you give it
> > bad inputs it does bad things. Failing to document your assumptions is
> > where most programmers seem to go wrong, in my experience.
>
> 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.
You can chip ice with a screwdriver, but an icepick works better.
> > The toughest area for guarding is end-user input. If you are receiving
> > input from some other programmer than we can hope they are good and read
> > your documentation. If you are receiving input from a keyboard, database,
> > network connection, etc. then you need to validate that data more, if
> > possible.
>
> 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.
> > Mind you, there are some situations (e.g. life critical) where double and
> > triple checking is more important than efficiency. Most programmers will
> > know when they need to be that meticulous.
>
> 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.
I've actually seen at least one guy who could not understand this
concept, and failed to deliver stuff because of it, because he
couldn't decide where to put the edit checks and/or error handling.
>
> --
> Paul Hsieh
> http://www.pobox.com/~qed/
> http://bstring.sf.net/
-- Les Cargill
- Next message: Guillaume: "Re: What IS Intelligence"
- Previous message: Oelewapperke: "Re: Academic research aimed at improving programmer productivity?"
- In reply to: Paul Hsieh: "Re: Writing bulletproof code"
- Next in thread: Paul Hsieh: "Re: Writing bulletproof code"
- Reply: Paul Hsieh: "Re: Writing bulletproof code"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
