From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-3.2 required=3.0 tests=BAYES_00,NICE_REPLY_A, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Jeffrey R.Carter" Newsgroups: comp.lang.ada Subject: Re: GNAT or Language Problems? Date: Sat, 24 Jun 2023 14:23:51 +0200 Organization: A noiseless patient Spider Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 24 Jun 2023 12:23:52 -0000 (UTC) Injection-Info: dont-email.me; posting-host="c876e409551b80fd0e2efd887d8b4950"; logging-data="106723"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+tfQRNxj14FTVRHLBwFDsGt2WcEn6kK80=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cancel-Lock: sha1:pN6Q24n5l2Eba7Od1EexIPT6c3I= In-Reply-To: Content-Language: en-US Xref: news.eternal-september.org comp.lang.ada:65343 List-Id: On 2023-06-23 11:55, Randy Brukardt wrote: > > Sigh. :Let's start over. My theory was that the problem came from an attempt > by AdaCore to implement AI22-0041-1, a post Ada-2022 binding interpretation. > That AI adds a static compatibility requirement to 7.4(6/3) (making it > 7.4(6/6)). (It of course could just be a bug, too, but AI22-0041-1 seems > like the only sane reason to be changing the matching code in a working > compiler that passes the ACATS.) > > There is *no* version of the RM currently that includes the wording from > post-Ada 2022 AIs (because of we had to wait for ISO to publish the thing > first). You can only find that in the >50 approved AIs. Thanks for this clarification. I didn't realize I would have to look at the AI itself. I'm using -gnat12, in hopes that the Ada-12 rules would be applied, but that doesn't seem to work. [New version of 7.4(6):] > a.. If the deferred constant declaration includes a subtype_indication > that defines a subtype S1, then the subtype_indication in the full > declaration shall define a subtype S2 that is statically compatible with S1 > (see 4.9.1). If S1 is a constrained subtype, the constraint defined by S2 > shall statically match the constraint defined by S1. [Redundant: If the > subtype S1 of the deferred constant is unconstrained, then the full > declaration is still allowed to impose a constraint.] As my case doesn't involve the concepts involved in the other PPs, aliased and null exclusion, I presume that this PP applies. The essential parts of the code are type B_String (Max_Length : Positive := 1_000) is tagged limited private; Null_B_String : constant B_String; ... Null_B_String : constant B_String := (Max_Length => 1, others => <>); I would think that the subtype indications in the two, being identical, would be statically compatible. But my understanding of this may be wrong. I'm not sure whether the deferred declaration has a constrained subtype, which would result in the constraint from the initialization expression of the full declaration not matching. But that rule has existed since Ada 95. I think it would be a mistake for the language to require explicit discriminant associations for this case. So I'm still not able to tell if this is a compiler error or intended by the language. -- Jeff Carter "Insufficient laughter--that's grounds for divorce." Play It Again, Sam 126