Thou shalt have no other gods before the ANSI C standard 1610

On Mon, 28 Feb 2005 05:19:39 -0800 in alt.folklore.computers, "Tom

One problem is that C is also an acceptable surrogate for Ada, COBOL, ForTran, Pascal, PL-I, and any other compiled language, but programmers of those languages are not acceptable surrogates for C programmers.

Another problem is that if there any safety checks not enabled by default, they will never be turned on by those programmers who need them most, and if they are on, they will be then be (unfairly) blamed for program failures, performance problems, and so on, so they will end up being turned off, probably at the site configuration level.

I've seen this happen when presented with COBOL, ForTran, PL-I program crash dumps; I knew what the abend code symptom was, I knew what the instructions were which caused the abend, and I knew what the options defaulted at compile time were; my "helpful" advice was always: turn on bounds checking to show you where the problem is, and leave it on even after you're running in production; never, ever heard back from any of those programmers; doubt they turned the checking on for more than the compile required to get source level diagnostics. When I wasn't actually in development, that was their problem, and I didn't want to waste my time fighting their management problems.

At least bounds checking in my C programs can't be turned off: it's part of the algorithm, so if I don't get the limits correct the program will have a defect, which will probably be caught quickly because of defensive programming, and also malicious testing to ensure error paths are followed, and recovery or termination code is exercised fully.

I figure it's my job in unit testing to ensure that the program executes as designed, and that it does not fail, as gracefully as possible, whenever and wherever incorrect data is encountered. It's the testers' job to validate that my design matches the requirements, specs, etc. on which I based my design, and to see if they can catch my implementation doing something defectively. We all dance the "dance of joy" when a defect in the code is verified, because then we know the design and implementation weren't too bad, the testing is effective, and one less defect is carried forward to acceptance testing.

The problem is you can't get anyone to eat your cake, even when the frosting is free, because not everyone likes the frosting.

-- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

fake address use address above to reply