Author: Russell Reagan
Date: 01:24:02 08/21/02
Go up one level in this thread
On August 21, 2002 at 03:49:18, Daniel Clausen wrote: >On August 20, 2002 at 23:16:03, Russell Reagan wrote: > >[snip] > >>The levels of truth: >> >>3. What you read in a book > >Not if it's in a book which _defines_ what ANSI-C is. Definitions can't be >wrong. That can be useless probably, but not wrong. It doesn't matter what it is. If the ANSI-C standard says something, and my compiler doesn't compile code I write that is "ANSI-C compliant", what good is that? Maybe my program will compile next year when they release the next version of the compiler? I'll *ONLY* have to wait a year... >>and the highest level of truth is... >> >>1. What the thing does when you run it > >I would have put that almost at the other end of the scale, at least when it >concerns programming in C. A program which compiles w/o errors and links, >_always_ does _something_ specific, under this platform, at that day, at that >time, with this memory layout, etc. There are many (?) things, which are either >implementation-defined or undefined at all in ANSI-C. The "highest level of >truth" won't catch these. (of course, most people couldn't care less whether the >stuff runs on the neighbours CPU as well, but that's another issue) You are confusing things here I think. When I say "what it does when you run it", I don't mean that you shouldn't pay attention to what the standard is, or platform specific things, etc. My point is that if the documentation says one thing, or the book says one thing, and the thing doesn't work right, that's no good. Besides, this isn't something I just made up. These are unix rules. I had a situation last semester in school where the professor gave us an assignment to write a shell script, and there was some sorting involved, so naturally we used the 'sort' command. We ran into some problems though, since the sort command didn't do what the book said it was supposed to do, and it didn't do what the documenation that came with Solaris said it was supposed to do, and everyone, including the professor, was at a loss (granted it was a rather long sort command). Finally after playing around with it for a while I figured out that we were leaving out a space here, a comma there, etc., just syntactical things. Luckily for me this wasn't a project I was working on for a job, and lucky for me it just flat didn't run when we tried it. What would have happened if it would have been a job, and a command didn't run as documented, and it opened up a security hole and someone hacks in and downloads the companies user database, credit card numbers, names, phone numbers, addresses, etc. I'd be putting my application in at McDonald's is what would happen. My point is not that you should just "do whatever works", but that you should make sure whatever you are doing works, and make sure it's working correctly, because things don't always work as they're documented to. C and C++ are perfect examples. Look at all of the non-compliance that has gone on, and that still does go on to a lesser degree. This "truth list" isn't supporting the printf() example, BTW. Russell
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.