Path: utzoo!yunexus!geac!daveb From: daveb@geac.UUCP (David Collier-Brown) Newsgroups: comp.lang.c Subject: data validation (was re self-modifying code) Message-ID: <3084@geac.UUCP> Date: 27 Jul 88 18:35:04 GMT Article-I.D.: geac.3084 References: <61251@sun.uucp> Organization: GEAC Computers, Toronto, CANADA Lines: 42 From article <61251@sun.uucp>, by guy@gorodish.Sun.COM (Guy Harris): > input data before using it (unless they have good reason to know the data will > *never* be incorrect); I would prefer to see > input, line 12: value "12038" is out of range (should be between > 17 and 137) > > than to see > ILLEGAL ARRAY REFERENCE: "frobozz.q", line 31 > Subscript was 12038; should be between 17 and 137 > 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. Subroutines should not check the number or type of nor validate the correctness of their input arguements, unless it is part of their intended operation [but see below --dave]. However, subroutines which accept structure arguements should check the input structure version number for validity. 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. This is for a machine which happily passes descriptors of arrays around, and manages to bounds-check array references in parallell with the fetch. 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... The manual above is a reprint, circa 1980. --dave (see .signature below) c-b -- 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.