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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,23f57930ddc13e1c X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!y42g2000hsy.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Missing Index Value in Array Aggregate Date: Wed, 26 Sep 2007 08:54:31 -0700 Organization: http://groups.google.com Message-ID: <1190822071.488118.316450@y42g2000hsy.googlegroups.com> References: <1i50iqb.14r2zb11w8eyc2N%csampson@inetworld.net> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1190822071 29363 127.0.0.1 (26 Sep 2007 15:54:31 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 26 Sep 2007 15:54:31 +0000 (UTC) In-Reply-To: <1i50iqb.14r2zb11w8eyc2N%csampson@inetworld.net> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: y42g2000hsy.googlegroups.com; posting-host=66.126.103.122; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:2146 Date: 2007-09-26T08:54:31-07:00 List-Id: On Sep 26, 6:21 am, csamp...@inetworld.net (Charles H. Sampson) wrote: > The compiler used in my work allowed an aggregate for > an array with an elaboration type index to omit one of the > index values. (There was no others choice.) As a result, > Constraint_Error was raised at library elaboration time, > which is a nasty bug to run down in this environment. > > I was getting ready to file a bug report, certain > that this was a compile-time error rather than run-time, > when I decided to take a close look at that old LRM. I > was surprised to find that the legality rules of 4.4.3 Should be 4.3.3 > appear to be designed to allow just that, particularly the > second clause of paragraph 18. > > Does anyone know what the purpose of this is? I can > see that there's an occasional need for it, as in the case > of an aggregate for a formal parameter of an unconstrained > array type. It certainly seems to me that in the case of > an aggregate for a constrained array object, catching this > error at compile time in is line with Ada's concept of > doing as much as possible at compile time. Or am I wrong? > Are there other paragraphs that do require this to be > caught during compilation? There can be nothing illegal about an aggregate such as (2 => 1010, 3 => 2020, 4 => 3030) when taken by itself. Any problems have to happen only when the compiler knows what type is expected for the aggregate. When the expected type is determined, the aggregate can resolve to any one- dimensional array type whose index and element types are some integer type; if the expected type is something else, then the aggregate is illegal. Note, though, that array *types* don't have bounds on their indexes. An array subtype is an array type plus (possibly) a constraint, where the constraint puts bounds on the indexes. Once the type of the above aggregate is determined, the aggregate will have an (unnamed) subtype of that type with a constraint of (2..4). Then, depending on what you do with that aggregate, the subtype will be *converted* to some other subtype. If you declare an object: type int4 is array(1..4) of integer; A : int4 := (2 => 1010, 3 => 2020, 4 => 3030); the semantics involve a type conversion of the unnamed aggregate subtype to "int4". The rules for type conversions are spelled out in 4.6. The result is that a Constraint_Error will be raised. In general, type conversions raise Constraint_Error when the constraint isn't satisfied; they don't make a program illegal. This is consistent, because of course a compiler can't always catch every case where a type conversion can cause a Constraint_Error: type intx is array (I..J) of integer; A : intx := (2 => 1010, 3 => 2020, 4 => 3030); where I and J are, say, procedure parameters. Ada 83 was consistent about this. In Ada 95, I believe that some constraint violations can make a program illegal, when static expressions are involved, but only if they occur in the *middle* of evaluating a static expression (4.9(34)), not when a static expression can be evaluated but is known to be outside the bounds of the subtype it will be converted to. In any event, though, when it comes to catching subtype constraint violations, I don't think "doing as much as possible at compile time" is part of the Ada philosophy, since it leads to inconsistencies, and having clear and consistent rules is very important also. That's just my guess at an explanation for why this isn't illegal. Our compiler, by the way, would probably have caught the aggregate you tried to use (depending on the exact construct). It would have displayed a warning that an exception will be raised at runtime. I just tried GNAT, and it also displays a warning at least in the case I tried. Our compiler also has an option that will treat a program as illegal if it encounters any such cases where an exception is known to be raised, but then of course this isn't strictly Ada. -- Adam