data validation (was re self-modifying code)

[David Collier-Brown]

|From article <61251 at sun.uucp>, by guy at gorodish.Sun.COM (Guy Harris):
|  input data before using it (unless they have good reason to know the data will
|  *never* be incorrect);

|In article <3084 at geac.UUCP> daveb at geac.UUCP (David Collier-Brown) writes:
|   When I look in my Mutlics standard systems designers' notebook, I
| find the following words of wisdom...
| 
| 	Subroutines should not check the number or type of input
|   arguments, but assume they have been called correctly.

>From article <4661 at rpp386.UUCP>, by jfh at rpp386.UUCP (John F. Haugh II):
|  in my humble opinion, subroutines on the interface boundary SHOULD check
|  their arguments for conformity to the interface definition.

   Er, the caveat on that was to check IFF that was part of the
purpose of the subroutine.  The hierarchy proposed in the manual was
to write a user-interface which did the checking, but not a
programmer-interface with the same checks.  As Guy argues, the
checking at the programmer interface should be done with assert() or
some other facility, arguing that this was normally for debugging a
program during development.
   I tend to agree, as I make a lot of simple typos during
development, and assertions catch many of them.  I will admit I
occasionally write a checking interface to some existing packages
for testing purposes...

|  ... once inside
|  of a system of subroutines, there is no need to check for out of band
|  data.
|
|  a well defined interface will specify the action to be taken on each
|  type of out of band data.  a very well defined interface will specify
|  EXACTLY how to deal with out of band values.

   I'd suggest reserving the term "out of band data" for valid data
sent along a special channel.  Out of **range**, now...

|  unix has been around longer than since circa 1980.  
   I know.  The manual was so **old** it had to be re-printed.

|  ...DEC would seem to
|  disagree since they included the trap on overflow/etc exceptions to
|  their double precision machine operands when they created the VAX
|  family of minicomputers.

   The range/precision of our current floating-point implementations
pose some very recalcitrant problems in predicting the input data to
an individual computation.  I still recommend trying to pass correct
operands, but admit a set of suspenders to accompany my belt can be
usefull, especially when I can't figure out what the constraints
ought to be to keep the calculation from both going out of range and
losing significant figures (I'm poor at numerical analysis).

   Actually, a computer manufacturer has to provide such traps, if
only for languages which define specific processing on over- and
underflow (eg, COBOL and PL/1), for implementing the IEEE standard,
etc.
 

-----

   Probably the best approach is to try to guarantee correct data
and behavior by input-data checking and carefull logic-checking
respectively, but providing parallel checks in hardware where it was
technically and financially feasable.  Tripping over one of them
would cause the program to dump, and my old boss had a policy that
"we don't ship programs which dump"[1].


|  John F. Haugh II                 +--------- Cute Chocolate Quote ---------
|  HASA, "S" Division               | "USENET should not be confused with
|  UUCP:   killer!rpp386!jfh        |  something that matters, like CHOCOLATE"
|  DOMAIN: jfh at rpp386.uucp          |             -- with my apologizes


--dave (I like the chocolate quote) c-b
[1] Nels Patterson, Director, Honeywell TSDC.
-- 
 David Collier-Brown.  {mnetor yunexus utgpu}!geac!daveb
 Geac Computers Ltd.,  |  Computer science loses its
 350 Steelcase Road,   |  memory, if not its mind,
 Markham, Ontario.     |  every six months.