ttwang@polyslo.CalPoly.EDU (Thomas Wang) (09/02/89)
terrell@druhi.ATT.COM (TerrellE) writes: >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 really wish that micros could be coerced to do this kind of checking! I'd >even like my compiler to generate extra code to check for undefined variable >references (not too difficult to do - but would make the object code larger). >No check for undefined variable access leaves a gaping hole in the security >mechanisms of Pascal, Modula 2, etc. While these languages will check for >out of range variable values, out of bounds array references, you're out of >luck with undefined variables. The problems you mentioned are the problem of the particular languages. The hardware should not be be doing error detection which the software should be handling in the first place. The fact that you can use a variable before initializing it shows the flaw in the language design. Every variables should be initialized. The C++ language is a modern language which you can have a high confidence that all variables are initialized. If you take the object-oriented view, allowing the creation of an object with undefined initial state is an obvious error. >There is probably a much simpler scheme... Yes. Insist you initialize a variable when you create it. >Terrell (att!druhi!terrell) -Thomas Wang (Ah so desu ka!) ttwang@polyslo.calpoly.edu
rcd@ico.ISC.COM (Dick Dunn) (09/02/89)
terrell@druhi.ATT.COM (TerrellE) writes in response to the idea of causing bad memory parity on uninitialized values (long lines re-broken): > One of the machines that Cray designed for CDC had 1's complement (not > 2's complement) arithmetic...[description of negative 0] Didn't ALL the machines he designed for CDC use 1's comp? > 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. Not true. Negative zero did not cause a trap. There was a floating-point value which would cause a trap if used as an operand--actually there were several, but this one was distinguished by the fact that FP operations would never generate it. (It was the "negative indefinite"; whenever the hardware generated an indefinite it would produce the positive form.) But this only gives you a trap on using the uninitialized value in a floating-point operation. No integer operations trapped. Even for FP values, you could copy them around to your heart's content without trapping--which can make it hard to find where the uninitialized value really came from at the outset. Negative zero could have been used--at considerable expense in the code-- as a marker for uninitialized integers. Compiled code would have to look for it, and it would take two tests. But (as with -indef) a negative zero -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Are you making this up as you go along?
barry@PRC.Unisys.COM (Barry Traylor) (09/03/89)
On Unisys A Series systems (formerly Burroughs B5/6/7000 series), all words have tags. These tags are not part of the data portion of the word; different tags have different uses. One of the tag enumerations is 6. With this tag, all non-privleged load operations fault and all non-privileged store operations complete OK. Some, but certainly not all of the A Series languages take advantage of this feature. Barry Traylor (standard disclaimer: opinions, policies, etc.) Unisys A Series Engineering, Tredyffrin, Pa.
david@cs.washington.edu (David Callahan) (09/03/89)
In article <11347@burdvax.PRC.Unisys.COM> barry@PRC.Unisys.COM (Barry Traylor) writes: >On Unisys A Series systems (formerly Burroughs B5/6/7000 series), all words >have tags. These tags are not part of the data portion of the word; >different tags have different uses. One of the tag enumerations is 6. >With this tag, all non-privleged load operations fault and all non-privileged >store operations complete OK. Some, but certainly not all of the A Series >languages take advantage of this feature. The Horizon architecture researched at the Supercomputing Research Center and now in commercial development at Tera Computer Co has 4 data trap bits associated with each word of memory. Generally access to a word with one of these bits set will cause the accessing stream to take a trap (which in this architecture is basically an unexpected branch to a user-specified location). Eight bits in the 64-bit pointer modify this behavior: for each trap bit there is a pair of bits that suppress the trap on read and write respectively. These bits could be used to detected uninitialized access: a read that traps is an error while a write that traps simply clears the bit and is restarted. This wasn't really the intent of these bits, they were designed more for type-tagging and demand-driven evaluation. In the context of this thread of discussion (debugging C-ish langauges) two uses are immediate: very efficient data break points set by a debugger and protection of implementation data structures (such as tables & lists maintained by malloc()). David Callahan (david@tera.com, david@june.cs.washington.edu,david@rice.edu) Tera Computer Co. 400 North 34th Street Seattle WA, 98103 -- David Callahan (david@tera.com, david@june.cs.washington.edu,david@rice.edu) Tera Computer Co. 400 North 34th Street Seattle WA, 98103
barmar@think.COM (Barry Margolin) (09/04/89)
In article <14166@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes: >The problems you mentioned are the problem of the particular languages. >The hardware should not be be doing error detection which the software should >be handling in the first place. Runtime error detection slows down programs when done only in software. That's why language designers would like hardware facilities to support it. >The fact that you can use a variable before initializing it shows the flaw >in the language design. Every variables should be initialized. The C++ >language is a modern language which you can have a high confidence that >all variables are initialized. >If you take the object-oriented view, allowing the creation of an object >with undefined initial state is an obvious error. Just because a variable is initialized doesn't mean it has a *useful* value. C automatically initializes all statics to 0, but that might not be a valid value as far as the application is concerned. >Yes. Insist you initialize a variable when you create it. What if you don't know what value it should have yet? Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
seanf@sco.COM (Sean Fagan) (09/04/89)
In article <28784@news.Think.COM> barmar@think.COM (Barry Margolin) writes: >Runtime error detection slows down programs when done only in >software. That's why language designers would like hardware >facilities to support it. Some of us are of the opinion that hardware error detection slows things down. True, it's *possible* to design it in such a way that the slow-down is negligible (or, dream of dreams, nonexistant), but most people won't do that. Then again, some of us are of the opinion that virtual memory slows things down 8-). -- Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
ttwang@polyslo.CalPoly.EDU (Thomas Wang) (09/04/89)
barmar@think.COM (Barry Margolin) writes: >Runtime error detection slows down programs when done only in >software. That's why language designers would like hardware >facilities to support it. One should not need to do software check on uninitialized variables. The language can be designed so uninitialized variables are impossible to create. >Just because a variable is initialized doesn't mean it has a *useful* >value. C automatically initializes all statics to 0, but that might >not be a valid value as far as the application is concerned. You should be able to specify a default initialization value, or even to explicitly forbid the creation of variables with default value. >In article <14166@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes: >>Yes. Insist you initialize a variable when you create it. >What if you don't know what value it should have yet? You can create the variable with a default value, or delay the creation of the variable until you know what value it should have. main() { type_car my_car; /* create a car with default 4 doors */ } main() { int door_number = get_number_of_doors(stdin); some_stuff(); type_car my_car(door_number); /* create a car with # doors specified */ } >Barry Margolin -Thomas Wang (Ah so desu ka!) ttwang@polyslo.calpoly.edu
barmar@think.COM (Barry Margolin) (09/06/89)
In article <14206@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes: >barmar@think.COM (Barry Margolin) writes: >>In article <14166@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes: >>>Yes. Insist you initialize a variable when you create it. >>What if you don't know what value it should have yet? >You can create the variable with a default value, or delay the creation of >the variable until you know what value it should have. My contention is that a variable with a default value is often just as bad as an uninitialized variable. Sure, it has a well-defined value, but it's not the value you really care about, and it might not make sense to use the variable until it gets a more meaningful value. Consider a language that automatically initializes all pointer variables to NULL when they are created. Strictly speaking, there are no uninitialized pointer variables in such a language. However, it's still not valid to dereference a pointer until you REALLY initialize it to point to something. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
grover%brahmand@Sun.COM (Vinod Grover) (09/07/89)
> My contention is that a variable with a default value is often just as > bad as an uninitialized variable. As with any other feature, 'the initialized variable', is prone to misuse. It has its uses though. For an intersting example refer to the 'Ada Rationale'. In that example, a variable of type linked list, by default gets to have a linked list of the correct size with all elements initialized to to a certain value. (I do not have the exat section and page# handy, but if you are interested I could email you the example or the reference). Vinod