albaugh@dms.UUCP (Mike Albaugh) (09/02/89)
From article <4322@druhi.ATT.COM>, by terrell@druhi.ATT.COM (TerrellE): > > One of the machines that Cray designed for CDC had 1's complement (not 2's complement) > arithmetic. 1's complement has two representations for 0 (positive and negative). > > Cray took advantage of this and made one of the 0 representations a designated > undefined value. The hardware would trap on an attempt to read a variable with > this undefined value. I believe this is a mis-remembering of the moral equivalent of NaN's used for memory-fill on 6000/7000 series, but not terribly important. > I really wish that micros could be coerced to do this kind of checking! [ Much about how wonderful this would be ...] > Some C compilers (with the LINT utility) will make a half-hearted attempt to find > possible references to undefined variables, but this cannot work in the general case > (equivalent to the halting problem)... Why does everybody seem to want to leave de-bugging to the user? This sort of "testing" is _not_ adequate for a program that will _ever_ be used by another person. Imagine how you would feel if, instead of _designing_ your car to work under all anticpated conditions, the engineers had just put in some "magic" which would cause it to come to a screeching halt as soon as it encountered something they didn't think of in a day or so of casual thought. Would you really consider that a feature? How about if Boeing took that attitude about airplane design? _Any_ program should do "bounds checking", but preferably at the earliest, hence likely highest level of abstraction, point possible. To depend on "magic" hardware is to doom the user to "Uninitialized variable at line 42 of routine glarf" instead of "must supply matrix size for run" > 1. Run a memory-diagnostic program before testing the program. If you're > lucky, it will leave funky values in memory that will cause a failure > when an undefined variable is referenced. A _very_ bad idea. Tantamount to rolling dice and checking only those lines of the program ending with the resulting digits. > 2. Some compilers will automatically initialize all variables to 0. This > may give more predictable behavior of the program... Maybe it's a good > idea to use this option only after most of the ininitialized variable > problems have been fixed... A reasonable C program on a reasonable C host can use this quite effectively, but beware the creeping assumption that (char *)0 is the all_bits_zero pattern. This is discussed at length and often in comp.lang.c [ hypothesizing about possible run-time checks ] In a debugging environment, all sorts of things are possible, but _please_ don't make this your only (or even primary) way of detecting these problems. Your users will thank you. So why did I leave this thread in comp.arch? To try to prevent machine architects from bending _too_ far over to fill a "need" that actually tends to create _more_ buggy software. If your hammer is doing a lousy job on that fastener, perhaps you need a screwdriver :-) > There is probably a much simpler scheme... There is no free lunch. | Mike Albaugh (albaugh@dms.UUCP || {...decwrl!turtlevax!}weitek!dms!albaugh) | Atari Games Corp (Arcade Games, no relation to the makers of the ST) | 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709 | The opinions expressed are my own (Boy, are they ever)