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=unavailable autolearn_force=no version=3.4.4
X-Received: by 2002:ac8:7282:: with SMTP id v2mr3766131qto.75.1574429211808;
 Fri, 22 Nov 2019 05:26:51 -0800 (PST)
X-Received: by 2002:a05:6830:15a:: with SMTP id
 j26mr10461512otp.342.1574429211495; Fri, 22 Nov 2019 05:26:51 -0800 (PST)
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!feeder5.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!j16no2843468qtl.0!news-out.google.com!g53ni774qtg.0!nntp.google.com!j16no2843465qtl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Fri, 22 Nov 2019 05:26:51 -0800 (PST)
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=134.206.121.213;
 posting-account=iV1hDQoAAADj-LMkLVCARAp8f-n9fYeB
NNTP-Posting-Host: 134.206.121.213
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9bee64ac-42c4-495e-9ce6-69c306b8e3a5@googlegroups.com>
Subject: yes another gnat bug (inherited tagged type as record field is too
 much for gnat??)
From: gerrshapovalov@gmail.com
Injection-Date: Fri, 22 Nov 2019 13:26:51 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: reader01.eternal-september.org comp.lang.ada:57587
Date: 2019-11-22T05:26:51-08:00
List-Id: <comp.lang.ada>

Hello,

This bug gets triggered while trying to use a tiny "list library", that pro=
vides a uniform interface for an indexed/iterable storage a-la Ada.Containe=
rs.Vectors, that can be implemented in various ways: using A.C.Vecotrs inte=
rnally or even plain "fixed" or "bounded" arrays..

This "library" is a part of ada_composition demo, now made into a stnandalo=
ne library, with tests as separate package, and can be found here:
https://github.com/gerr135/ada_composition

The lib itself is under ada_lists
and tests for the lib are under ada_lists_tests


Everything works just fine,.. - as long as I use these lists as "plain vari=
ables". However when such list is uses as a record field, gnat just commits=
 suicide trying to compile it.=20

Basically:

with Lists.Fixed;

package PL  is new Lists(Natural, Positive);
package PLF is new PL.Fixed;

LS : PLF.List(5);

type FRec (N : Positive) is record
    f : PLF.List(N);
end record;

LC : FRec(5);


LS(1)   :=3D 1; -- works fine
LC.f(1) :=3D 1; -- triggers gnat bug

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3DGNAT BUG DETECTED=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
| Community 2019 (20190517-83) (x86_64-pc-linux-gnu) Storage_Error stack ov=
erflow or erroneous memory access

The code in the "library" is pretty much minimal (needed to implements inde=
xed access and iteration), and the tests are just repeated blocks or basic =
code to test assignment and iteration (in the form of indexed and of loops)=
.

So, the easiest way to reproduce this should be to just clone the project m=
entioned above ( https://github.com/gerr135/ada_composition )
and then:
cd ada_lists_tests
make

Quite "weirdly" the stock A.C.Vectors work fine as record fields. However, =
is this due to
1. them being "proper" types rather than descendants of some interface
2. some ACT black magic in their implementation (they do use locks and Unre=
stricted_Access) in the corresponding bodies, I looked)
is not quite clear to me..

Am I overlooking something here?=20
This should be a really common use case, a very basic composition idea:
1. do all the algorithmic stuff at the "higher level", using abstract data =
accessor methods
2. Defer data storage and other implementation details to child packages..

Yes every time I am trying to do a very basic separation of this kind I tri=
gger yet another gnat bug :(.