Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: data validation (was re self-modifying code)
Message-ID: <8267@brl-smoke.ARPA>
Date: 29 Jul 88 07:45:35 GMT
References: <61251@sun.uucp> <3084@geac.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 31

In article <3084@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes:
>	Subroutines should not check the number or type of input
>  arguments, but assume they have been called correctly.
>  What the Multicians are saying is exactly what Guy says: input
>routines validate input as part of their purpose in life.  Other
>routines assume the data is valid, and don't put in checks unless
>thay have to deal with "versioned" structures.
>  Depending on the hrdware or compiler to catch invalid data by
>trapping on its use has been a known bad practice since well before
>Unix...

Yes.  The basic problem is that errors detected at unanticipated
points within the bowels of a program will not be handled intelligently.
(In theory it would almost be possible to provide reasonable recovery
from every such possible error, but in practice life is too short.)

On the other hand, unless the code is developed under some formal
verification system, there is a non-negligible chance that a high-
level oversight will permit a low-level routine to be invoked
improperly.  Rather than behaving randomly, a suitable compromise
is to perform simple, CHEAP plausibility tests in the low-level
routines.  For example, check that a pointer is non-null before
dereferencing it, or check that a count is nonnegative.  Low-level
routines should try to behave as sanely as is reasonably possible.

I usually code up such verifications under control of assert(),
and turn them all off after the whole system has been thoroughly
shaken out.  Some people recommend leaving the tests enabled
forever, as inexpensive insurance.  Good run-time error handling
for a production release of a system should not rely on recovery
from such low-level interface errors anyway.