* Constraint checking of actuals passed to Attributes @ 2000-05-05 0:00 Matt Brennan 2000-05-05 0:00 ` Keith Thompson 2000-05-08 0:00 ` Tucker Taft 0 siblings, 2 replies; 30+ messages in thread From: Matt Brennan @ 2000-05-05 0:00 UTC (permalink / raw) Quick question: Is an implementation required to generate code to check that an actual parameter passed to an attribute (for example, 'Image of a scalar type) is subtype conformant with the formal parameter? Opinions with ARM references most welcome! :-) Matt ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-05 0:00 Constraint checking of actuals passed to Attributes Matt Brennan @ 2000-05-05 0:00 ` Keith Thompson 2000-05-08 0:00 ` Tucker Taft 1 sibling, 0 replies; 30+ messages in thread From: Keith Thompson @ 2000-05-05 0:00 UTC (permalink / raw) Matt Brennan <zschub@hotmail.com> writes: > Is an implementation required to generate code to check that an actual > parameter passed to an attribute (for example, 'Image of a scalar type) > is subtype conformant with the formal parameter? Yes, but the formal parameter may not be what you expect it to be. In the specific case of 'Image, 3.5(35..36) says: S'Image denotes a function with the following specification: function S'Image(Arg : S'Base) return String So, for example, Natural'Image(-1) is the same as Integer'Image(-1), and will not raise Constraint_Error. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> Welcome to the last year of the 20th century. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-05 0:00 Constraint checking of actuals passed to Attributes Matt Brennan 2000-05-05 0:00 ` Keith Thompson @ 2000-05-08 0:00 ` Tucker Taft 2000-05-09 0:00 ` Robert Dewar 2000-05-10 0:00 ` Matt Brennan 1 sibling, 2 replies; 30+ messages in thread From: Tucker Taft @ 2000-05-08 0:00 UTC (permalink / raw) Matt Brennan wrote: > > Quick question: > > Is an implementation required to generate code to check that an actual > parameter passed to an attribute (for example, 'Image of a scalar type) > is subtype conformant with the formal parameter? Most attribute functions like 'Image, 'Pos, etc., have the base subtype as the parameter subtype, meaning that no constraints apply. Hence, the only possible problem occurs if the actual parameter is not a value of the *type* which could happen due to unchecked conversion, (unchecked) binary input, or an uninitialized variable. Implementations are not required to deal nicely with the unchecked conversion or binary input situation, but are required to at least "survive" the uninitialized variable situation in Ada 95. This is because the first two are "erroneous" situations whereas the last one is merely a "bounded error." This means that in the first two cases, anything could happen (incineration of disk drive, etc.), whereas in the uninitialized case, Program_Error, Constraint_Error, or producing some arbitrary value as the result would be acceptable. In Ada 83, using uninitialized variables is erroneous as well, so some compilers out there might still misbehave on them due to bugs or ancestry. > Opinions with ARM references most welcome! :-) RM95 A.13(17) -- unchecked binary input RM95 13.9(11)/13.9.1(8) -- unchecked conversion/abnormality RM95 13.9.1(9-11) -- uninitialized variable bounded error > > Matt -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Commercial Division, AverStar (formerly Intermetrics) (http://www.averstar.com/services/IT_consulting.html) Burlington, MA USA ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-08 0:00 ` Tucker Taft @ 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Ted Dennison 2000-05-09 0:00 ` Robert A Duff 2000-05-10 0:00 ` Matt Brennan 1 sibling, 2 replies; 30+ messages in thread From: Robert Dewar @ 2000-05-09 0:00 UTC (permalink / raw) In article <39171B69.2F983487@averstar.com>, Tucker Taft <stt@averstar.com> wrote: > but are required to at least "survive" the uninitialized > variable situation in Ada 95. This is because the first two > are "erroneous" situations whereas the last one is merely a > "bounded error." This means that in the first two cases, > anything could happen (incineration of disk drive, etc.), > whereas in the uninitialized case, Program_Error, > Constraint_Error, or producing some arbitrary value as the > result would be acceptable. A lot of things would be acceptable, including incineration of disk drives. Why? let's read the RM: 11 If the representation of the object does not represent a value of the object's type, the semantics of operations on such representations is implementation-defined, but does not by itself lead to erroneous or unpredictable execution, or to other objects becoming abnormal. Unfortunately, implementation-defined is a HUGE hole, through which almost any truck can be driven. OK, so it is probably not acceptable for an implementation to say: In this implementation, the semantics of such operations is erroneous. But I can't see anything wrong in a statement that says In this implementation, the semantics of such operations is that the following horrible things may happen: Long list of horrible consequences, which does not explicitly mention erroneousness or abnormal values, but whose consequences are equally severe. OK, Bob and Tuck will argue that this does not meet the "intent" of the authors in writing the above statement. Arguments from intent are always suspect, but never more so than when the intent is vague and unclear. I really cannot see the thoughts behind trying to carefully bound the effects of an error, and then allowing one of the possible effects to be implementation defined. The notion of "anything short of erroneous" is definitely not one that is well defined, or testable. Ken -- time for another of your complaints about dubious requirements :-) > > In Ada 83, using uninitialized variables is erroneous as well, > so some compilers out there might still misbehave on them due > to bugs or ancestry. > > > Opinions with ARM references most welcome! :-) > > RM95 A.13(17) -- unchecked binary input > RM95 13.9(11)/13.9.1(8) -- unchecked conversion/abnormality > RM95 13.9.1(9-11) -- uninitialized variable bounded error > > > > > Matt > > -- > -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ > Technical Director, Commercial Division, AverStar (formerly Intermetrics) > (http://www.averstar.com/services/IT_consulting.html) Burlington, MA USA > Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Robert Dewar @ 2000-05-09 0:00 ` Ted Dennison 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Robert A Duff 1 sibling, 1 reply; 30+ messages in thread From: Ted Dennison @ 2000-05-09 0:00 UTC (permalink / raw) In article <8f93lm$1es$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > of disk drives. Why? let's read the RM: > > 11 If the representation of the object does not represent a > value of the object's type, the semantics of operations > on such representations is implementation-defined, but > does not by itself lead to erroneous or unpredictable > execution, or to other objects becoming abnormal. > > Unfortunately, implementation-defined is a HUGE hole, through > which almost any truck can be driven. OK, so it is probably > not acceptable for an implementation to say: It does seem that this constrains the possible effects to just the object in question. To me that means that if I overlay a small object with a large one, then the compiler has to somehow prevent writes to the large object from hosing nearby objects. That can't be right. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Ted Dennison @ 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Ted Dennison 0 siblings, 1 reply; 30+ messages in thread From: Robert Dewar @ 2000-05-09 0:00 UTC (permalink / raw) In article <8f99gf$8eo$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > It does seem that this constrains the possible effects to just > the object in question. If you say so, I guess people can read all sorts of things into a vague requirement that is not well stated. I certainly don't see the slightest hint to justify this viewpoint. It only talks about other values becoming abnormal, not about being affected in other ways, e.g. having values outside their subtype. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Robert Dewar @ 2000-05-09 0:00 ` Ted Dennison 2000-05-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: Ted Dennison @ 2000-05-09 0:00 UTC (permalink / raw) In article <8f9a87$97r$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > In article <8f99gf$8eo$1@nnrp1.deja.com>, > Ted Dennison <dennison@telepath.com> wrote: > > > It does seem that this constrains the possible effects to just > > the object in question. > > If you say so, I guess people can read all sorts of things into > a vague requirement that is not well stated. I certainly don't > see the slightest hint to justify this viewpoint. It only talks > about other values becoming abnormal, not about being affected > in other ways, e.g. having values outside their subtype. Not having to have ever written a full Ada compiler, I'm not as aquainted with the nuances of the meaning of "abnormal" as it pertains to objects as many others here are. But my reading of the context of 13.9.1("Data Validity":3-7) implies more or less just that. It talks about objects that are "normal" having valid values for their type. So it would seem that any requirement to keep objects "normal" means that they cannot have garbage values placed in them. What am I missing? -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Ted Dennison @ 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Ted Dennison 0 siblings, 1 reply; 30+ messages in thread From: Robert Dewar @ 2000-05-09 0:00 UTC (permalink / raw) In article <8f9c45$be5$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > Not having to have ever written a full Ada compiler, I'm not > as aquainted with the nuances of the meaning of "abnormal" as > it pertains to objects as many others here are. The term "abnormal" has nothing to do with Ada compilers or any other compilers, it is a term specifically coined for use in the Ada RM, and fully defined therein. > But my reading of the context of > 13.9.1("Data Validity":3-7) implies more or less just that. It > talks about objects that are "normal" having valid values for > their type. Nope, that's not careful enough reading. The whole point of this section is to distinguish abnormal from other cases where values may be outside the subtype range. An uninitialized value is NOT abnorma. That's at the heart of the discussion here, since referencing an abnormal object is for sure erroneous: 8 It is erroneous to evaluate a primary that is a name denoting an abnormal object, or to evaluate a prefix that denotes an abnormal object. But an uninitialized variable may well not have a valid value. Confused? I am not surprised. I find this whole attempt to differentiate between these two states pretty ill-defined. > So it would seem that any requirement to keep objects "normal" > means that they cannot have garbage values placed in them. > What am I missing? See above! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Robert Dewar @ 2000-05-09 0:00 ` Ted Dennison 2000-05-09 0:00 ` Robert A Duff 0 siblings, 1 reply; 30+ messages in thread From: Ted Dennison @ 2000-05-09 0:00 UTC (permalink / raw) In article <8f9sjg$v3t$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > Nope, that's not careful enough reading. The whole point of > this section is to distinguish abnormal from other cases where > values may be outside the subtype range. An uninitialized > value is NOT abnorma. That's at the heart of the discussion Ahh, I see. It looks like I mentally added an "ab" at an unfortunate place in the first sentence of section 4. > Confused? I am not surprised. I find this whole attempt to > differentiate between these two states pretty ill-defined. Horribly, yes. I'm not upset or grinding an axe here, just curious and confused. I still fail to see the reason for the distinction between a variable that got hosed because an assignment was aborted and a variable that got hosed because of an assignment to an inappropriate overlay on a neighboring object. I can't think of any possible logical distinction, other than that perhaps someone desparately wanted type-hosing overlays to not be erronious anymore. I guess you could say that the difference is that in the first case the values it managed to put in were probably valid values, and the ones it didn't were also valid; they just may not be valid together. But in the second case the value really is completely undefined. But the other listed "abnormailty" is when you get a garbage value from an imported subprogram. So so much for that idea. I mean, what's the difference *how* the garbage was achieved? The affect of trying to work with it is what matters, and there is no difference I can see there (no matter how you want to word the standard). -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Ted Dennison @ 2000-05-09 0:00 ` Robert A Duff 0 siblings, 0 replies; 30+ messages in thread From: Robert A Duff @ 2000-05-09 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > I mean, what's the difference *how* the garbage was achieved? The affect > of trying to work with it is what matters, and there is no difference I > can see there (no matter how you want to word the standard). The discussion was about uninitialized variables, completely within the Ada world. That's a big difference from "values" produced by Unchecked_Conversion or interface to some other language. The latter are isolated in specific modules (one hopes), whereas variable declarations appear all over the place. It's fine with me if one has to inspect the interfaced values carefully, or call 'Valid or some such, but it shouldn't cause havoc to simply forget to initialize a variable in plain vanilla Ada code. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Ted Dennison @ 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` Robert Dewar 1 sibling, 1 reply; 30+ messages in thread From: Robert A Duff @ 2000-05-09 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > OK, Bob and Tuck will argue that this does not meet the > "intent" of the authors in writing the above statement. Yes. > Arguments from intent are always suspect, True. My rule of thumb is that you shouldn't argue from intent unless you've found something wrong with the RM (an inconsistency, an onerous implementation burden, a requirement that makes the language useless, etc). Having found such a bug, I think it makes sense to talk about what the original authors must have meant, in some informal sense. Sometimes, they can even *remember* what they meant. ;-) >...but never more > so than when the intent is vague and unclear. Well, it's clear to me. ;-) Apparently, it's not clear to you, but I'm not sure what to do about that at this point. I agree with you that the RM words do not precisely capture the intent. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Robert A Duff @ 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Robert A Duff 0 siblings, 1 reply; 30+ messages in thread From: Robert Dewar @ 2000-05-09 0:00 UTC (permalink / raw) In article <wcc4s8721fj.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > Well, it's clear to me. ;-) > > Apparently, it's not clear to you, but I'm not sure what to do > about that at this point. You could try expressing your intent. > I agree with you that the RM words do not precisely capture > the intent. Seeing as you agree the RM words do not capture the intent, I guess the only way to determine the intent is to ask the intenders to divulge otherwise unknowable information. Seems to me that implementation-defined is pretty clear, you apparently have in mind, implementation-defined-but-please-don't-do-anything-I-did-not-in tend which is a harder concept to follow! > > - Bob > Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Robert Dewar @ 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` Keith Thompson ` (3 more replies) 0 siblings, 4 replies; 30+ messages in thread From: Robert A Duff @ 2000-05-09 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In article <wcc4s8721fj.fsf@world.std.com>, > Robert A Duff <bobduff@world.std.com> wrote: > > > Well, it's clear to me. ;-) > > > > Apparently, it's not clear to you, but I'm not sure what to do > > about that at this point. > > You could try expressing your intent. Well. First of all, it's not "my" intent. It's the intent of the language design team (of which I was but a part), and I think I understand that intent, but I don't entirely agree with it. (English suffers from not having a clear singular for "your".;-)) My job was to help write a coherent reference manual, and only secondarily to push for my own wishes as to the language rules. I suppose I could try expressing the intent by example: If you say: Uninit: Integer; -- Uninitialized variable! ... if Uninit < 10 then ... The condition must be either True or False, or it must raise an exception. It must not destroy other variable's values. Inside the if statement, Uninit must evaluate to a value less than 10. Obviously that's not a formal definition -- it's just an example of the intent. If I could give a formal definition of the intent, I would have done so in the RM -- I didn't then, because it's hard, and it's still hard today. I don't think it's impossible to formalize that intent. If you start asking me about floating-point NaN's, or holes in rep-speced enums, I'll start hemming and hawing. But for plain old integers and enums, I think I kown what was "intended". At least I can give lots of examples. ;-) > > I agree with you that the RM words do not precisely capture > > the intent. > > Seeing as you agree the RM words do not capture the intent, I > guess the only way to determine the intent is to ask the > intenders to divulge otherwise unknowable information. Correct. ;-) I'm not convinced that the RM always has to be read in such a formal way. Sometimes (most times) it should. But there are some rules of the form, "nudge, nudge, you know what I mean". - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Robert A Duff @ 2000-05-09 0:00 ` Keith Thompson 2000-05-10 0:00 ` Robert A Duff 2000-05-12 0:00 ` Tucker Taft 2000-05-10 0:00 ` David C. Hoos, Sr. ` (2 subsequent siblings) 3 siblings, 2 replies; 30+ messages in thread From: Keith Thompson @ 2000-05-09 0:00 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: [...] > I suppose I could try expressing the intent by example: > > If you say: > > Uninit: Integer; -- Uninitialized variable! > ... > if Uninit < 10 then > ... > > The condition must be either True or False, or it must raise an > exception. It must not destroy other variable's values. Inside the > if statement, Uninit must evaluate to a value less than 10. > > Obviously that's not a formal definition -- it's just an example of the > intent. If I understand the context of this example correctly, the intent is to make these guarantees if Uninit is merely uninitialized, but not if it's abnormal (say, if an assignment to it was disrupted; see RM95-13.9.1). The standard doesn't require bizarre things to happen under such circumstances, it merely withdraws its usual guarantee that bizarre things won't happen. If the underlying hardware has no abnormal representations for type Integer, Integers will never become abnormal ("Whether or not an object actually becomes abnormal in these cases is not specified.") This kind of thing is more likely to show up (on most systems) for things like composite objects with corrupted descriptors. The most plausible scenario for type Integer that I can think of is a system that represents an integer as a floating-point value with the exponent set to zero (I'm not sure whether Ada allows this); something like a floating-point NaN would then be an abnormal value for type Integer. A less plausible scenario is an integer with the low-order bit set to 0.5. I suppose the real requirement being imposed here is that, if the underlying system has "abnormal" representations for a given type, the Ada implementation must guarantee that an uninitialized variable isn't set to one of those representations. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> Welcome to the last year of the 20th century. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Keith Thompson @ 2000-05-10 0:00 ` Robert A Duff 2000-05-14 0:00 ` Simon Wright 2000-05-12 0:00 ` Tucker Taft 1 sibling, 1 reply; 30+ messages in thread From: Robert A Duff @ 2000-05-10 0:00 UTC (permalink / raw) Keith Thompson <kst@cts.com> writes: > If I understand the context of this example correctly, the intent is > to make these guarantees if Uninit is merely uninitialized, but not if > it's abnormal Yes. > I suppose the real requirement being imposed here is that, if the > underlying system has "abnormal" representations for a given type, the > Ada implementation must guarantee that an uninitialized variable isn't > set to one of those representations. Yes, that's necessary. Eg, an uninitialized array has to have bounds or whatever dope the implementation uses properly initialized, so that things like "A(1) := ...;" will work. But the real bone of contention here, I think, is the requirement that, for example: My_String: String(1..10); My_Index: Integer range 1..5; ... My_String(My_Index) := ...; will need a check (that My_Index is in 1..10) unless the compiler can prove that My_Index is initialized. (Or, more precisely, is valid.) In Ada 83, no such check was required, because either My_Index is in 1..5, and therefore in 1..10, or else the program was erroneous, and therefore can do anything. This intended change was a deliberate attempt to increase safety at the expense of a small inefficiency. In the run-time model the AverStar compiler chooses, the compiler can prove validity quite often. For example, an 'in' parameter of an integer type is always valid, because it was constraint checked at the call site. The constraint check at the call site is not required -- the compiler is allowed to propagate invalid values all over the place, but I think that's less efficient, because then you have more checks inside the called procedure. We also do flow analysis, to find cases where variables are initialized by assignment statements on every path leading to some place, rather than on the variable's declaration. Again, I'm talking about the *intent* of the language design team. Whether Robert Dewar or anyone else can see that intent in the RM wording is another story. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-10 0:00 ` Robert A Duff @ 2000-05-14 0:00 ` Simon Wright 2000-05-17 0:00 ` Robert A Duff 0 siblings, 1 reply; 30+ messages in thread From: Simon Wright @ 2000-05-14 0:00 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: > In the run-time model the AverStar compiler chooses, the compiler can > prove validity quite often. For example, an 'in' parameter of an > integer type is always valid, because it was constraint checked at the > call site. Presumably this isn't true if the subprogram was exported .. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-14 0:00 ` Simon Wright @ 2000-05-17 0:00 ` Robert A Duff 0 siblings, 0 replies; 30+ messages in thread From: Robert A Duff @ 2000-05-17 0:00 UTC (permalink / raw) Simon Wright <simon@pogner.demon.co.uk> writes: > Robert A Duff <bobduff@world.std.com> writes: > > > In the run-time model the AverStar compiler chooses, the compiler can > > prove validity quite often. For example, an 'in' parameter of an > > integer type is always valid, because it was constraint checked at the > > call site. > > Presumably this isn't true if the subprogram was exported .. You mean exported as in pragma Export? It's true even in that case. Eg: procedure P(X: Positive) is S: String(1..10); begin S(X) := 'x'; end P; Inside P, we assume X is in Positive. On the assignment, the generated code will check that X <= 10, but will *not* check that X >= 1. If you call P from C code, it's your responsibility to pass the correct stuff. If you pass in a negative value, you will overwrite an arbitrary memory location. This is always true: you always lose all checking (compile time and run time) at the interface between Ada and some foreign language. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Keith Thompson 2000-05-10 0:00 ` Robert A Duff @ 2000-05-12 0:00 ` Tucker Taft 2000-05-12 0:00 ` Ted Dennison 1 sibling, 1 reply; 30+ messages in thread From: Tucker Taft @ 2000-05-12 0:00 UTC (permalink / raw) Keith Thompson wrote: > ... > If I understand the context of this example correctly, the intent is > to make these guarantees if Uninit is merely uninitialized, but not if > it's abnormal (say, if an assignment to it was disrupted; see > RM95-13.9.1). The standard doesn't require bizarre things to happen > under such circumstances, it merely withdraws its usual guarantee that > bizarre things won't happen. If the underlying hardware has no > abnormal representations for type Integer, Integers will never become > abnormal ("Whether or not an object actually becomes abnormal in these > cases is not specified.") > > This kind of thing is more likely to show up (on most systems) for > things like composite objects with corrupted descriptors. The most > plausible scenario for type Integer that I can think of is a system > that represents an integer as a floating-point value with the exponent > set to zero (I'm not sure whether Ada allows this); something like a > floating-point NaN would then be an abnormal value for type Integer. > A less plausible scenario is > an integer with the low-order bit set to 0.5. > > I suppose the real requirement being imposed here is that, if the > underlying system has "abnormal" representations for a given type, the > Ada implementation must guarantee that an uninitialized variable isn't > set to one of those representations. That wasn't the problem we worried about when inventing the "invalid" versus "abnormal" distinction. Imagine the following: X : Very_Long_Integer range -5..5; Y : Very_Long_Integer range -5..5 := 4; A : array(Very_Long_Integer range -5..5) of Integer; ... A(X) := 37; -- X might be invalid here, but not abnormal. -- the implementation should not trash random memory A(Y) := 37; -- Y is valid here (and normal) Y := -5; -- imagine abort or other "disruption" happens in middle -- of this multi-word assignment, and Y ends up with a weird value -- like -4 billion (due to setting the high 32 bits to -1, -- while leaving the low 32 bits as +4). -- If then in finalization code or an exception handler -- we write "A(Y) := 36". Y might be abnormal and the -- implementation is free to trash random memory. In other words, abnormal means out of range due to disruption, or "bad" binary input or unchecked conversion, whereas invalid means out of range due to lack of initialization or other "normal" behavior. The implementation is supposed to "survive" out-of-range due to "normal" behavior (e.g. forgetting an initializer) but not due to one of these "bad" things like disruption, etc. Without this distinction, the implementation would have to assume the worst about the value stored in a constrained object in many more cases, making it that much harder to eliminate redundant range checks. > > -- > Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> > San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> > Welcome to the last year of the 20th century. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Commercial Division, AverStar (formerly Intermetrics) (http://www.averstar.com/services/IT_consulting.html) Burlington, MA USA ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-12 0:00 ` Tucker Taft @ 2000-05-12 0:00 ` Ted Dennison 2000-05-12 0:00 ` Robert A Duff 0 siblings, 1 reply; 30+ messages in thread From: Ted Dennison @ 2000-05-12 0:00 UTC (permalink / raw) In article <391C543F.83B2A408@averstar.com>, Tucker Taft <stt@averstar.com> wrote: versus "abnormal" distinction. Imagine the following: > > Y : Very_Long_Integer range -5..5 := 4; > ... > Y := -5; -- imagine abort or other "disruption" happens in middle > -- of this multi-word assignment, and Y ends up with a weird value > -- like -4 billion (due to setting the high 32 bits to -1, > -- while leaving the low 32 bits as +4). > -- If then in finalization code or an exception handler > -- we write "A(Y) := 36". Y might be abnormal and the > -- implementation is free to trash random memory. > > In other words, abnormal means out of range due to disruption, or > "bad" binary input or unchecked conversion, > whereas invalid means out of range due to lack of initialization or > other "normal" behavior. The implementation is supposed to "survive" Thanks for the explanation. That distinction was exactly what I was wondering about. But I still don't understand the logic behind making misuse of an overlay an "invalid" case rather than an "abonormal" (and thus erronious) case. Couldn't it cause the same -4 billion value to get placed into Y? The compiler would have no easy way to detect that the state has changed to "invalid". How do you enforce that the program "survives" this? -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-12 0:00 ` Ted Dennison @ 2000-05-12 0:00 ` Robert A Duff 2000-05-12 0:00 ` Ted Dennison 0 siblings, 1 reply; 30+ messages in thread From: Robert A Duff @ 2000-05-12 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > But I still don't understand the logic behind making misuse of an > overlay an "invalid" case rather than an "abonormal" (and thus > erronious) case. Couldn't it cause the same -4 billion value to get > placed into Y? The compiler would have no easy way to detect that the > state has changed to "invalid". How do you enforce that the program > "survives" this? I'm not sure what you mean, here. Could you post a specific example? (Maybe you already did, but I've long since forgotten about it. ;-)) Certainly you can cause abnormal objects, and erroneousness, by certain misuses of address clauses and unchecked conversions of access values, both of which can be used to make overlays. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-12 0:00 ` Robert A Duff @ 2000-05-12 0:00 ` Ted Dennison 2000-05-16 0:00 ` Robert A Duff 0 siblings, 1 reply; 30+ messages in thread From: Ted Dennison @ 2000-05-12 0:00 UTC (permalink / raw) In article <wccsnvnsdpv.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > Ted Dennison <dennison@telepath.com> writes: > > > But I still don't understand the logic behind making misuse of an > > overlay an "invalid" case rather than an "abonormal" (and thus > Certainly you can cause abnormal objects, and erroneousness, by certain > misuses of address clauses and unchecked conversions of access values, > both of which can be used to make overlays. Can you? The relevant section in 13.9.1 only mentions aborted assignements and parameters passed to imported procedures. But then paragraph 14 does say that objects can become abnormal in other ways too. Perhaps my problem is that I'm missing where "abmormal" is truly defined. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-12 0:00 ` Ted Dennison @ 2000-05-16 0:00 ` Robert A Duff 2000-05-16 0:00 ` Ted Dennison 2000-05-17 0:00 ` Robert Dewar 0 siblings, 2 replies; 30+ messages in thread From: Robert A Duff @ 2000-05-16 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > > In article <wccsnvnsdpv.fsf@world.std.com>, > Robert A Duff <bobduff@world.std.com> wrote: > > Certainly you can cause abnormal objects, and erroneousness, by > certain > > misuses of address clauses and unchecked conversions of access values, > > both of which can be used to make overlays. > > Can you? The relevant section in 13.9.1 only mentions aborted > assignements and parameters passed to imported procedures. Well, for address clauses, I guess I should have said just "cause erroneousness". If it can do that, then it can do any other bad thing you can name, so it's kind of silly to argue about whether it can cause abnormal values. 13.3(13) says it can be erroneous. For unchecked conversions, 13.9(11) says the result can be abnormal except in certain (non-pointerish) cases. The difference between abnormal and erroneous is pretty small -- abnormal is just one small step short of disaster (where erroneous = disaster). >... But then > paragraph 14 does say that objects can become abnormal in other ways > too. Perhaps my problem is that I'm missing where "abmormal" is truly > defined. Well, I was going to admonish you to look it up in the index, but I see the index is incomplete in this case. :-( I suggest you get the plain-ascii version of the AARM, and search for abnormal. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-16 0:00 ` Robert A Duff @ 2000-05-16 0:00 ` Ted Dennison 2000-05-17 0:00 ` Robert Dewar 1 sibling, 0 replies; 30+ messages in thread From: Ted Dennison @ 2000-05-16 0:00 UTC (permalink / raw) In article <wccln1a5wh8.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > Ted Dennison <dennison@telepath.com> writes: > > Can you? The relevant section in 13.9.1 only mentions aborted > > assignements and parameters passed to imported procedures. > > Well, for address clauses, I guess I should have said just "cause > erroneousness". If it can do that, then it can do any other bad thing > you can name, so it's kind of silly to argue about whether it can cause > abnormal values. 13.3(13) says it can be erroneous. That just said that the address has to be "valid", not the value at that address. So I had interpreted that to mean that the address had to be within the program's adddress space, and perhaps allocated. For instance, on DOS it can't refer to an unallocated I/O memory location. In VMS, it can't have the high address bit set, etc. After all, one could argue that any address on the stack is "valid". Some may not contain valid values for type Foo, but the addresses themselves are valid. > > too. Perhaps my problem is that I'm missing where "abmormal" is > > truly defined. > > Well, I was going to admonish you to look it up in the index, but I > see the index is incomplete in this case. :-( :-) Thanks for checking. I *did* try that first. > I suggest you get the plain-ascii version of the AARM, and search for > abnormal. Done. 7.6.1(2) sort of defines it by context. The whole reason for this LRM-diving expedition on my part was to try to figure out how exactly the 95 LRM views the address clause type-hosing technique. In the old Ada it used be erronious. My reading of what I have seen in the LRM says that it is not defined by the language to ever be erronious, as long as the addressee object exists and any extra bytes the addressor type needs also happen to be in existing objects. Since there's no way to guarantee the latter, then one could say its perfectly OK, as long as the addressee object is at least as large as the addressor. Based on your text above about the meaning of 13.3(13), I'm guessing you'd say that the execution can be erronious if the value at that address is not valid for the addressor's type. However, using 13.3(13) for this purpose seems inconvienent, because it is only talking about the addressor object. So technically its not defined as erronious if the program causes the value to be invalid for the addressee type by assigning that value via the addressor type. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-16 0:00 ` Robert A Duff 2000-05-16 0:00 ` Ted Dennison @ 2000-05-17 0:00 ` Robert Dewar 1 sibling, 0 replies; 30+ messages in thread From: Robert Dewar @ 2000-05-17 0:00 UTC (permalink / raw) In article <wccln1a5wh8.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > The difference between abnormal and erroneous is pretty small > abnormal is just one small step short of disaster (where > erroneous disaster). Hmmm! It would clearly be absolutely conformant to have a compiler which when you accessed an abnormal variable and caused erroneousity which in practice was mild in effect, and on the other hand where any access to an uninitialized variable was defined by the implementation to delete all picture and movie files from your disk, send messages to all the people on your outlook list, and send messages about your configuration back to the Phillipines. As long as this was appropriately documented (see thread on documentation requirements), this would be valid behavior. Trying to categorize levels of disaster is a tricky game :-) No doubt Bob will protest that the reference to implementation defined that I am exploiting here was not intend to allow this *particular* definition, arguing from (reverant music starts --- O R I G I N A L I N T E N T). In practice, I think the important thing is that compilers do reasonable things, and have several modes corresponding to various desirable behaviors in terms of undefined behavior. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` Keith Thompson @ 2000-05-10 0:00 ` David C. Hoos, Sr. 2000-05-10 0:00 ` Robert Dewar 2000-05-22 0:00 ` Kenneth Almquist 3 siblings, 0 replies; 30+ messages in thread From: David C. Hoos, Sr. @ 2000-05-10 0:00 UTC (permalink / raw) ----- Original Message ----- From: Robert A Duff <bobduff@world.std.com> Newsgroups: comp.lang.ada Sent: May 09, 2000 6:13 PM Subject: Re: Constraint checking of actuals passed to Attributes <snip> (English > suffers from not having a clear singular for "your".;-)) How about "thine?" Yes, I saw the smiley -- but I think modern "English" usage is to 17th-/18th-century English somewhat as C is to Ada. ----- Original Message ----- From: Robert A Duff <bobduff@world.std.com> Newsgroups: comp.lang.ada Sent: May 09, 2000 6:13 PM Subject: Re: Constraint checking of actuals passed to Attributes <snip> (English > suffers from not having a clear singular for "your".;-)) How about "thine?" Yes, I saw the smiley -- but I think modern "English" usage is to 17th-/18th-century English somewhat as C is to Ada -- less to be desired. Give me precision over brevity every time. <snip> ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` Keith Thompson 2000-05-10 0:00 ` David C. Hoos, Sr. @ 2000-05-10 0:00 ` Robert Dewar 2000-05-10 0:00 ` Robert A Duff 2000-05-15 0:00 ` Bill Greene 2000-05-22 0:00 ` Kenneth Almquist 3 siblings, 2 replies; 30+ messages in thread From: Robert Dewar @ 2000-05-10 0:00 UTC (permalink / raw) In article <wccitwnmi4r.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > I suppose I could try expressing the intent by example: > > If you say: > > Uninit: Integer; -- Uninitialized variable! > ... > if Uninit < 10 then > ... > > The condition must be either True or False, or it must raise > an exception. It must not destroy other variable's values. > Inside the if statement, Uninit must evaluate to a value less > than 10. Now wait a cotton pickin moment (is that the way that phrase is spelled? :-) What does the RM say: 9 If the representation of a scalar object does not represent a value of the object's subtype (perhaps because the object was not initialized), the object is said to have an invalid representation. It is a bounded error to evaluate the value of such an object. If the error is detected, either Constraint_Error or Program_Error is raised. Otherwise, execution continues using the invalid representation. The rules of the language outside this subclause assume that all objects have valid representations. The semantics of operations on invalid representations are as follows: 10 If the representation of the object represents a value of the object's type, the value of the type is used. 11 If the representation of the object does not represent a value of the object's type, the semantics of operations on such representations is implementation-defined, but does not by itself lead to erroneous or unpredictable execution, or to other objects becoming abnormal. Where on earth do you manage to narrow down the result to raising CE or PE or proceeding normally. It would be absolutely FINE to terminate the program with an error message, and we SPECIFICALLY discussed this as an appropriate meaning of implementation-defined when we discussed this clause. That's why I dislike this business of divining intent so intensely. You end up asking the design team what they remember having in mind, and they may not even remember correctly. I can't see any possible way to read the "implementation defined" above [which applies ONLY if you do NOT recognize the situation and raise CE or PE) as being anywhere NEAR as restrictive as Bob implies. For example, the following is quite reasonable: If an object in a boolean expression has an invalid value, the result will always be false, regardless of the form of the expression, e.g. a > 10 and a < 10 will both be false. This is perfectly predictable, quite reasonable (think about NaN's in floating point, and ENTIRELY allowable from the quoted paragraph read in the most friendly form possible). In fact I would find a compiler that initialized all "uninitialized" floating point values to NaN and then said the predictable behavior was specified by the IEEE rules for handling NaN's to be a very good implementation of uninitialized. Similarly if I was on an IBM 7040, then it would be free to cause a fatal parity error terminating the program on any access to an uninitialized variable, and that would be just fine too (again, very NICE behavior, at least during the testing phase). The WATFOR compiler used to do this (it used the hardware diagnostic instruction to set parity wrong on all uninitialized data). It was my understanding that we put the words implementation defined in that paragraph precisely to allow a variety of possible implementations, all of which are reasonable. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-10 0:00 ` Robert Dewar @ 2000-05-10 0:00 ` Robert A Duff 2000-05-15 0:00 ` Bill Greene 1 sibling, 0 replies; 30+ messages in thread From: Robert A Duff @ 2000-05-10 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > Now wait a cotton pickin moment (is that the way that phrase > is spelled? :-) > > What does the RM say: >... You asked me about the *intent*. I don't claim that the RM precisely specifies the intended rules, so you're quoting of the RM is irrelevant. I do claim that the intent should be clear, at least for simple things like integers, to someone who doesn't use an overly legalistic reading of the RM. After all, you argue that the RM wording has the same effect as the Ada 83 wording. Clearly, if that were the intent of the language design team, then we would have left the wording as in Ada 83, because it's much simpler wording -- it just says that using an uninit scalar var is erroneous. We must have intended to make *some* change, since we introduced new terminology ("invalid", "abnormal"), and new rules. > That's why I dislike this business of divining intent so > intensely. You end up asking the design team what they remember > having in mind, and they may not even remember correctly. It is indeed possible that I don't remember the intent correctly, or never understood it correctly. > This is perfectly predictable, quite reasonable (think about > NaN's in floating point, and ENTIRELY allowable from the quoted > paragraph read in the most friendly form possible). Yes, NaN's are part of the reason the "intent" is so hard to specify precisely, which is why the RM doesn't try. > Similarly if I was on an IBM 7040, then it would be free to > cause a fatal parity error terminating the program on any > access to an uninitialized variable, and that would be just > fine too (again, very NICE behavior, at least during the > testing phase). ... I believe the intent was not to allow such abrupt termination of the program. I agree that's "NICE behavior". I've always thought Ada should have a notion of killing a program (like "exit" or "abort" in C) stronger than exceptions. But it doesn't, and there was no mandate to add such a notion in Ada 9X, so the only possible way of notifying of errors is to raise an exception. >... The WATFOR compiler used to do this (it used > the hardware diagnostic instruction to set parity wrong on > all uninitialized data). ASIDE: You have to be careful about these low-level hardware-oriented implementations, because they might not match Ada's notions. For example, in Ada, it is perfectly OK to copy an array full of uninitialized components, using an assignment statement. If the hardware complains about that, then it's wrong. I learned this when writing an Ada compiler for the Symbolics Lisp machine, which had a 4-bit tag on every word, and there was an "undefined" tag, and it detected any load of an undefined word. But we had to disable that (by zeroing uninit vars), which was kind of sad. > It was my understanding that we put the words implementation > defined in that paragraph precisely to allow a variety of > possible implementations, all of which are reasonable. Perhaps, but if doing so allows absolutely anything, then we made a mistake (ie, we didn't write words precisely defining our intent). We certainly did not intend to allow the use of an uninit var as an array index to trash arbitrary memory locations. I realize that some reviewers didn't like that (Bevin Brett, for example, thought the trade-off should be in favor of efficiency). - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-10 0:00 ` Robert Dewar 2000-05-10 0:00 ` Robert A Duff @ 2000-05-15 0:00 ` Bill Greene 1 sibling, 0 replies; 30+ messages in thread From: Bill Greene @ 2000-05-15 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Now wait a cotton pickin moment (is that the way that phrase > is spelled? :-) "cotton-pickin' minute" -- William R. Greene 1100 Perimeter Park Drive Ganymede Software, Inc. Suite 104 http://www.ganymede.com Morrisville, NC 27560 USA Phone: (919) 469-0997, ext. 280 Fax: (919) 469-5553 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-09 0:00 ` Robert A Duff ` (2 preceding siblings ...) 2000-05-10 0:00 ` Robert Dewar @ 2000-05-22 0:00 ` Kenneth Almquist 3 siblings, 0 replies; 30+ messages in thread From: Kenneth Almquist @ 2000-05-22 0:00 UTC (permalink / raw) Robert A Duff wrote: > I suppose I could try expressing the intent by example: > > If you say: > > Uninit: Integer; -- Uninitialized variable! > ... > if Uninit < 10 then > ... > > The condition must be either True or False, or it must raise an > exception. It must not destroy other variable's values. Inside the > if statement, Uninit must evaluate to a value less than 10. > > Obviously that's not a formal definition -- it's just an example of the > intent. > > If I could give a formal definition of the intent, I would have done so > in the RM -- I didn't then, because it's hard, and it's still hard > today. I don't think it's impossible to formalize that intent. > > If you start asking me about floating-point NaN's, or holes in > rep-speced enums, I'll start hemming and hawing. But for plain old > integers and enums, I think I kown what was "intended". > > At least I can give lots of examples. ;-) As I understand it, the main reason for deviating from Ada 83 was that in Ada 83 an uninitialized variable could result in memory overwrites when used as a subscript and wild jumps when used in a case statement: type Index is new Integer range 1 .. 5; A : array(Index) of Integer; I : Index; A(I) := 1; -- The compiler need not check that I is in 1..5. case I is -- The compiler may generate code that branches ... -- to an arbitrary location if I is not in 1..5. end case; Fixing these two problems is tedious, but not particularly hard. In outline: 1. The value of an uninitialized scalar variable or scalar component of a composite type is either a valid value of the specified subtype, or an "illegal value." 2. If the value of X is an illegal value, then X'Valid is false. 3. If the value of X is an illegal value, then reading the value of X is a bounded error. The possible results are: 1. Program_Error is raised, 2. Constraint_Error is raised, 3. the result is an illegal value, or 4. the result is some valid value. 4. If X names a scalar object, then assigning an illegal value to X is a bounded error. The possible effects are: 1. Program_Error is raised, 2. Constraint_Error is raised, 3. X is set to an illegal value, or 4. X is set to some valid value. 5. Using an illegal value as the operand to a predefined operator, or as the argument to a function specified by the attributes S'floor, S'ceil, S'adjacent, S'leading_part, S'length, S'max, S'min, S'pos, S'pred, S'succ, or S'val, is a bounded error. The possible results are the same as those for reading a variable with an illegal value. 6. The result of applying the T'Image operation to an illegal value is implementation defined. 7. Using an illegal value as a subscript is a bounded error. The possible results are: 1. Program_Error is raised, 2. Constraint_Error is raised, 3. a valid value is substituted for the illegal value, or 4. the result of the subscript operation refers to an "illegal object". 8. Reading the value of an illgal object or a component of an illegal object is a bounded error. If the type of the object or component is not a pointer type, then the possible results are the same as those for reading an uninitialized variable. Otherwise, the possibilities are that Program_Error is raised, Constraint_Error is raised, or a null pointer value is returned. 9. Writing to an illegal object is a bounded error. It has no effect except for possibly raising Program_Error or Constraint_ Error. 10. It is a bounded error to use an illegal value as the control value for an if, while, or case statement. The possible results are: 1. Program_Error is raised, 2. Constraint_Error is raised, 3. a valid value is substituted for the illegal value. 11. It is a bounded error for the limit on a range used in a subtype or array type specification to be an illegal value. The result is that the set of values included in the range is undefined. In addition, the use of attributes defined in terms of the illegal value (X'first, X'last, X'length) is a bounded error; the possible results are the same as those for reading an uninitalized variable. 12. It is a bounded error for the limit on the range in a "for" statement to be an illegal value. The results is that the sequence of values taken on by the control variable of the for loop is undefined. [We don't require the sequence to be finite because a sequence of length 2**64 (which is possible on 64 bit machines) is effectively infinite.] Probably I've missed a few cases, but it should be fairly obvious how to fill in the gaps. Your requirement that, "Inside the if statement, Uninit must evaluate to a value less than 10," does not have anything to do with safety that I can see (unless the value of Uinit is passed to a routine written in another language). So your example makes it clear that the intent goes beyond avoiding the memory overwrite and wild jump problems that I list at the start of this article. However, I still have no clue as to what this additional intent is. So my question is: Beyond avoiding the two problems that I identified above, what else was the team attempting to accompish? Kenneth Almquist ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Constraint checking of actuals passed to Attributes 2000-05-08 0:00 ` Tucker Taft 2000-05-09 0:00 ` Robert Dewar @ 2000-05-10 0:00 ` Matt Brennan 1 sibling, 0 replies; 30+ messages in thread From: Matt Brennan @ 2000-05-10 0:00 UTC (permalink / raw) Tucker Taft wrote: > > Implementations are not required to deal nicely with the unchecked > conversion or binary input situation, but are required to at least > "survive" the uninitialized variable situation in Ada 95. Tucker (and all others), thanks for your views and references. It seems another grey, 'implementation defined' area to investigate more fully with our compiler vendor... Regards, Matt -- -- Matt Brennan || Vision Systems Ltd || +61 8 8300 4686 -- ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2000-05-22 0:00 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-05-05 0:00 Constraint checking of actuals passed to Attributes Matt Brennan 2000-05-05 0:00 ` Keith Thompson 2000-05-08 0:00 ` Tucker Taft 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Ted Dennison 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Ted Dennison 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Ted Dennison 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` Keith Thompson 2000-05-10 0:00 ` Robert A Duff 2000-05-14 0:00 ` Simon Wright 2000-05-17 0:00 ` Robert A Duff 2000-05-12 0:00 ` Tucker Taft 2000-05-12 0:00 ` Ted Dennison 2000-05-12 0:00 ` Robert A Duff 2000-05-12 0:00 ` Ted Dennison 2000-05-16 0:00 ` Robert A Duff 2000-05-16 0:00 ` Ted Dennison 2000-05-17 0:00 ` Robert Dewar 2000-05-10 0:00 ` David C. Hoos, Sr. 2000-05-10 0:00 ` Robert Dewar 2000-05-10 0:00 ` Robert A Duff 2000-05-15 0:00 ` Bill Greene 2000-05-22 0:00 ` Kenneth Almquist 2000-05-10 0:00 ` Matt Brennan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox