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=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE, XPRIO autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT or Language Problems? Date: Mon, 26 Jun 2023 16:42:55 -0500 Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Mon, 26 Jun 2023 21:42:46 -0000 (UTC) Injection-Info: dont-email.me; posting-host="6c7462d9aafb8fe3924bdd4a893577ba"; logging-data="1154685"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+kDoZFbT69tQG99fx/nrdM5MZ9a0gvt98=" Cancel-Lock: sha1:Ry6GLs1p9wrE6W+UDiDIxFEEW2U= X-RFC2646: Format=Flowed; Response X-Priority: 3 X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-MSMail-Priority: Normal Xref: news.eternal-september.org comp.lang.ada:65354 List-Id: "Jeffrey R.Carter" wrote in message news:u76n8o$3873$1@dont-email.me... > 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. A subtype is always supposed to statically match itself (even though that isn't clear from them RM wording). B_String is an unconstrained type, which technically has a "null constraint" (see 3.2(7/2), rather unfortuate terminology, IMHO(. These always statically match, so they're always statically compatible as well. So this appears to be a compiler bug. It might be related to the relatively new rule that Object_Size must match for static matching to work -- but that only applies to non-default Object_Size values (and there are none of those given here). Randy.