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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,fdbf6f8330ffcbf5
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news1.google.com!news2.google.com!postnews.google.com!h7g2000yqn.googlegroups.com!not-for-mail
From: Shark8 <onewingedshark@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Odd/Broken behavior DOTNET-GNAT vs GNAT regarding tagged types.
Date: Fri, 22 Oct 2010 12:58:21 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: <4c89d345-c3ce-4ac4-a9d1-c1c93727f819@h7g2000yqn.googlegroups.com>
References: 
 <512951a6-bcc3-4c1a-a5ce-5bd3402d7143@j25g2000yqa.googlegroups.com>
 <8f6d51ed-69f9-4e76-a03e-b5601aa714e1@w30g2000prj.googlegroups.com>
NNTP-Posting-Host: 174.28.203.45
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1287777501 12861 127.0.0.1 (22 Oct 2010 19:58:21
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Fri, 22 Oct 2010 19:58:21 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: h7g2000yqn.googlegroups.com; posting-host=174.28.203.45;
 posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.10)
 Gecko/20100914 Firefox/3.6.10 ( .NET CLR 3.5.30729;
 .NET CLR 4.0.20506),gzip(gfe)
Xref: g2news1.google.com comp.lang.ada:14686
Date: 2010-10-22T12:58:21-07:00
List-Id: <comp.lang.ada>

On Oct 22, 10:22=A0am, Adam Beneschan <a...@irvine.com> wrote:
> On Oct 21, 8:35=A0pm, Shark8 <onewingedsh...@gmail.com> wrote:
>
> > Hey everyone; I just got bit with a bit of a surprise regarding the
> > differences in how tagged types are treated by GNAT vs DOTNET-GNAT,
> > The output of 'external_tag shows why the behavior of the Ada.Tags
> > Package is broken under DOTNET.
>
> Not sure what you're trying to do here, or why this is causing a
> problem. =A0The RM says that the default 'External_Tag is implementation-
> defined, so you shouldn't depend on it being a certain value, or else
> you should write your own "for Tagged_Base'External_Tag use ..."
> clause. =A0My apologies if you already knew this and had some other
> reason for being surprised.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Ad=
am
>
> [snip]
>
> > -- .NET output
> > ----------------------
> > C:\PROGRA~3\TEMPOR~1\testing>tag_error.exe
> > External tag for base type: tagged_base_pkg.tagged_base
> > External tag for child type: tagged_base_pkg.tagged_child
>
> > Tagged child is NOT a decendant.
>
> > -- Native output
> > ----------------------
> > C:\PROGRA~3\TEMPOR~1\testing>tag_error.exe
> > External tag for base type: TAGGED_BASE_PKG.TAGGED_BASE
> > External tag for child type: TAGGED_BASE_PKG.TAGGED_CHILD
>
> > Tagged child is a decendant.
>
>

Ah, the only reason there's an 'External_Tag reference is for output
onscreen display {lazy shortcutting of
Ada.Tags.External_Tag(Item'Tag), which should give the same thing};
the real oddity is the behavior of Is_Descendant_At_Same_Level which
doesn't readily appear to use the external formatting of the tag.