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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,288d9a25b0a9af53
X-Google-Attributes: gid103376,public
From: Simon Wright <simon@pogner.demon.co.uk>
Subject: Re: Segmentation fault on VADSself
Date: 1999/09/03
Message-ID: <x7v906o8qjc.fsf@pogner.moho>#1/1
X-Deja-AN: 520508763
X-NNTP-Posting-Host: pogner.demon.co.uk:158.152.70.98
References: <7qer2f$j2a$1@mars.worldonline.fr> <37CF1406.7CAA@jcdisciples.org>
X-Trace: news.demon.co.uk 936340985 nnrp-09:9624 NO-IDENT
 pogner.demon.co.uk:158.152.70.98
Organization: At Home
Newsgroups: comp.lang.ada
X-Complaints-To: abuse@demon.net
Date: 1999-09-03T00:00:00+00:00
List-Id: <comp.lang.ada>

David Tannen <bluesguy@jcdisciples.org> writes:

> Another area that could be causing problems would be 
> anyplace where you *might* have variant records that
> are being allocated space by the following method:
> 1.  You have a standard record the same size as your 
>     largest variant.
> 2.  You have access types for the standard & variant
>     record.
> 3.  You use 'is new' to create space with the standard
>     record.
> 4.  You then use unchecked conversion between the 
>     two different access types.
> 
> You will find that the moment you try to access a
> part of memory associated with the variant part of
> the record, you get a core dump.

This sounds like bitter exerience speaking :-)

My advice, FWIW, would have been to find another way of solving this
problem that didn't involve variant records; it sounds horribly
non-portable!