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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: 103376,28a755ada641b984
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!wn14feed!worldnet.att.net!attbi_s51.POSTED!53ab2750!not-for-mail
From: "Jeff C," <jcreem@yahoo.com>
Newsgroups: comp.lang.ada
References: <%7XQc.100722$eM2.38916@attbi_s51>
Subject: Re: Longstanding GNAT bug, bad code, or both
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Message-ID: <5yYQc.102027$eM2.62394@attbi_s51>
NNTP-Posting-Host: 24.147.74.171
X-Complaints-To: abuse@comcast.net
X-Trace: attbi_s51 1091851521 24.147.74.171 (Sat, 07 Aug 2004 04:05:21 GMT)
NNTP-Posting-Date: Sat, 07 Aug 2004 04:05:21 GMT
Organization: Comcast Online
Date: Sat, 07 Aug 2004 04:05:21 GMT
Xref: g2news1.google.com comp.lang.ada:2614
Date: 2004-08-07T04:05:21+00:00
List-Id: <comp.lang.ada>

Ok..Original post was still a bit confused and pointed to the wrong
line...but the problem is still real.

I've decided this really is a longstanding GNAT bug so I created a bugzilla
report. If someone
can tell me that the code is not legal Ada then I'll cancel the report.


--- Here is what the bugzilla now says


I believe there is a longstanding bug that has been present in GNAT since
about GNAT 3.13. The old intermetrics Xlib Ada bindings stopped working at
that time and it seemed to be related to the processing of the XEvent
variant records. I have created a very small test program that  think
demonstrates the same failure mode.

The problem appears to be that if a variable that is a variant record is
declared as aliased, some of the constraint checking logic fails in such a
way that it relies on the default value of the discriminant rather than the
current value.

This program demonstrates the problem both on Solaris and Windows XP
using gcc 3.4.1


with Text_Io;
procedure Aaa is


  type Var (A : Integer:=0) is
  record
    case A is
      when 0 =>
        Ok : Integer;
      when 1 =>
        Bad : Integer;
      when others =>
        null;
    end case;
  end record;


  procedure See (
        X : in out Var ) is

  begin
    --
    -- The following will blow up with a discriminant
    -- check error (contraint_error) when the actual parameter
    -- associated with X is declared aliased. Note that
    -- in this code I realize there is no good reason to
    -- declare it as aliased however this still effectively
    -- shows the problem.
    --
    X:= (
      A   => 1,
      Bad => 2);

  end See;

begin
  declare
    I : aliased Var;  -- If you make this not aliased, everything works fine
    --I : Var;
  begin
    See(I);
    Text_Io.Put_Line(Integer'Image(I.Bad));
  end;
end Aaa;