From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, T_FILL_THIS_FORM_SHORT autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9479ab5b9a099a61 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: gcc/gnat 4.1.1 bug References: <5llkrjn43w.fsf@hod.lan.m-e-leypold.de> <1151439688.792173.276330@u72g2000cwu.googlegroups.com> From: M E Leypold Date: 28 Jun 2006 01:45:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Some cool user agent (SCUG) NNTP-Posting-Host: 88.72.243.222 X-Trace: news.arcor-ip.de 1151451548 88.72.243.222 (28 Jun 2006 01:39:08 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news2.google.com!news.germany.com!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:5154 Date: 2006-06-28T01:45:21+02:00 List-Id: "Adam Beneschan" writes: > > Request: Could anybody knowing more about the Ada type system state > > that this is indeed a bug in gcc 4.1.1 or did some subtle point change > > here between Ada 95 and Ada 2005? > > > I think it was a bug for the compiler to accept the above code (i.e. > the code before you patched it). It's not legal in either Ada 95 or Just say that again: "for i in a'Range" is illegal if a is an array variable? I don't understand. > Ada 2005 as far as I can tell. (And you can't assume that Ada code you > get from a public source is legal. I've found numerous examples of > illegal code that still gets distributed because it's only been tried > on one compiler and that compiler has a bug.) That I understand very well: Gnat 3.15p accepted a number of constructs in my program that were plainly illegal and which I had to change when going to 4.1.1. Like that with generic type Element_Type is ...; package Alib.Set .... a reference of the kind S.Element_Type was legal (for S being an instance of the generic) whereas I understand that should not have been the case. > Here's how I piece things together: 3.6.2(7) says that for an array A, > A'Range is equivalent to A'First..A'Last (except that A is evaluated Ahh, here it comes. > only once). 4.9(8) says that a 'First or 'Last attribute reference is > static if its prefix statically denotes a statically constrained array > object. 4.9(14) defines what "statically denotes" means: the prefix > has to refer to a "direct name", "expanded name", or character literal. > However, MDI.Docks is not any of these. A direct name is a simple > identifier, and an expanded name is just like a direct name except that > it could be qualified with package names or names of subprograms or > blocks that you're inside, or things like that. MDI is an access > object, however. Sounds logical. I'll have to follow that on a weekend again when I have more time. > This means that the prefix of MDI.Docks'Range does not statically > denote anything, and therefore MDI.Docks'First and 'Last (and therefore > 'Range) are not static. Thus, the subtype of "Side" is *not* a static > subtype. I can see, why that rule has bee introduced. But: Apart from how that is formulated in the RM: Either MDI is null, than the dereferencing fails and the case will not be executed or it is not null, then refers to a range which is fixed at compile time. It might not be static in the sense of the letter in the RM, but it certainly is in effect (uh - am I clear?). So I wonder why the restriction (no access type) was introduced. > > The rules for a CASE statement say that if the index's type is a static > subtype, the choices must cover just that subtype range; while if it's > not a static subtype, the choices must cover the entire base range. So > it's correct for the compiler to require that None be one of the > choices, and incorrect for the compiler to accept a CASE statement that > doesn't have that choice (or an "others" clause). As far as I can > tell, none of the relevant rules have changed between Ada 95 and Ada > 2005; therefore, the Ada 95 compiler was incorrect. OK. > This does seem counter-intuitive. Yes. > But apparently requiring that the prefix of 'First *statically* > *denotes* the array object was put there deliberately, and I'm sure > there was a good reason, although I don't know what it is. I'd like to hear about that reason if anybody here knows about it. I'm not only a complainer about license issues but also an avid connoisseur of languages :-). > In general, if you apply 'First on something that you > have to go through an access value to get to, the compiler has to make > sure the access value is not null, even if the 'First could be > determined at compile time (see the next paragraph). > Considering a value that requires a null check to be "static" would > undoubtedly cause problems for other parts of the language. That is the point I don't see. I don't come the parts where the static value is used except if the access value is /= null. So within the block in question, actually starting from the ' of 'First, the access value is guaranteed to be not null (like with access discriminants). And this is a static condition applying to the block in question. (I hope I'm understandable here: I'm not very well versed in the jargon of the ARM, so please, just ignore me if I become garbled) > > (In Ada 95, MDI is not allowed to be null; in Ada 2005, it is. Perhaps ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Why that? > that's why the Ada 95 compiler erroneously accepted the program: since > no null check was necessary, the compiler viewed MDI.Docks'First as a > constant, and then erroneously decided that it must be static, while > the Ada 2005 compiler includes a "null check" as part of the logic to > compute the value of 'First. However, I don't see how whether null is > a legal value or not affects whether the attribute reference is treated > as static by 4.9. Experiment: Change the definition of MDI from > "access MDI_Window_Record" to "not null access MDI_Window_Record". If > this causes the program to compile, then the Ada 2005 compiler is wrong > too.) I see. I'll have to postpone that experiment. I already pickled the compiler and put it into my bit cellar for the winter and I'm now trying to teach 3.15p not to barf on my data structure (which was the original reason for this excursion). > > Hope this helps. It does. At last I can see, were I have to look. :-) Thanks. Regards -- Markus