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,e408bb0b4469b67c X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Mon, 11 Dec 2006 17:12:02 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1165585768.342140.201110@16g2000cwy.googlegroups.com> <1165602630.553040.134960@n67g2000cwd.googlegroups.com> <1165822851.141177.13460@79g2000cws.googlegroups.com> Subject: Re: Default comparison of tagged variant records Date: Mon, 11 Dec 2006 17:12:58 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-yS2xNvz5rKuphGOup8oEn2/qwA+nQyX5pcjJ1eT3QiEeuvojl5C30PEV0LiqrMcNz/VdVigJ5yGiehj!h7IsbSXKt+sRqQdhBYjSpRc9K8k4iXQdP8sogmnPbY+RO9ZDx4yrbzuMgfOtK/Y+8/Fdg4UY+dt2!fc6EQOBV6q2hPA== X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:7896 Date: 2006-12-11T17:12:58-06:00 List-Id: wrote in message news:1165822851.141177.13460@79g2000cws.googlegroups.com... > > Randy Brukardt napisal(a): > > "Adam Beneschan" wrote in message > > news:1165602630.553040.134960@n67g2000cwd.googlegroups.com... > > > > This looks like a compiler bug to me. It should return TRUE in those > > > all cases. > > > > I agree with Adam that it *looks* like a compiler bug. OTOH, I tried it on > > Janus/Ada and it also gave FALSE. Something else is going on... ... > > ...and so does the call to "=". Your program should print TRUE and this is > > clearly a Gnat bug. ;-) > > Do you mean comparing the Unbounded_String components of record? This > works in Gnat too and I've used it to define equality for the > troublesome type as a workaround. No, I mean the original full record compare should work properly. > > (If anyone cares, the problem with Janus/Ada was that it was not picking up > > the primitive "=" for the untagged private type Unbounded_String, as it was > > only looking for primitive *dispatching* operations. Thus it was using the > > predefined one, and that always returned False unless the objects were the > > same object. Gnat's problem may very well be different.) > > In GNAT "=" also returns True when comparing the same object with > itself. > > It looks like there might be some explanation that has its roots > somewhere in ARM, that's why I asked. Not really. Ada 95 was rather silent on this issue: in particular, there was no requirement that the predefined "=" work right for language-defined types. So some implementations caused trouble by not considering this issue; re-emergence could be a problem. The ARG thought that this was bad for usability, so that problem was addressed in the Corrigendum (2001) by adding 4.5.2(32.1/1): For all nonlimited types declared in language-defined packages, the "=" and "/=" operators of the type shall behave as if they were the predefined equality operators for the purposes of the equality of composite types and generic formal types. There is a further note to implementers in the AARM: If any language-defined types are implemented with a user-defined "=" operator, then either the full type must be tagged, or the compiler must use "magic" to implement equality for this type. A normal user-defined "=" operator for an untagged type does not meet this requirement. Janus/Ada did indeed implement Unbounded_String as a tagged type, but a compiler bug prevented the compiler from noticing this when creating "=" for a type with Unbounded_String components. GNAT seems to have a similar bug; but make no mistake, it is a bug, because the behavior reported for GNAT violates 4.5.2(32.1/1). [As well as good taste! ;-)] I suspect that the main reason that implementations have bugs in this area is that there is no ACATS test for 4.5.2(32.1/1). It was considered a low priority to test that last time such things were considered; perhaps that judgement was wrong. Randy. Randy.