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-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,e5fae12a81834f90
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-02-23 02:22:06 PST
Path: 
 supernews.google.com!sn-xit-03!supernews.com!news-out.usenetserver.com!news-out.usenetserver.com!newsfeed.direct.ca!look.ca!news-FFM2.ecrc.net!news.iks-jena.de!lutz
From: lutz@iks-jena.de (Lutz Donnerhacke)
Newsgroups: comp.lang.ada
Subject: Re: AdaYY wish list from current projects
Date: 23 Feb 2001 10:12:43 GMT
Organization: IKS GmbH Jena
Distribution: world
Message-ID: <slrn99cdnh.ju.lutz@taranis.iks-jena.de>
References: <96ulad$r9e$1@belenus.iks-jena.de> <87u25nnfer.fsf@deneb.enyo.de>
 <slrn99a396.l0.lutz@taranis.iks-jena.de> <87elwp3fw4.fsf@deneb.enyo.de>
NNTP-Posting-Host: taranis.iks-jena.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: slrn/0.9.6.3 (Linux)
Xref: supernews.google.com comp.lang.ada:5466
Date: 2001-02-23T10:12:43+00:00
List-Id: <comp.lang.ada>

* Florian Weimer wrote:
>lutz@iks-jena.de (Lutz Donnerhacke) writes:
[Regenerating the access to an aggregate from an access to a component]
>> Very bad. I'd like to suggest a language feature in order to solve this.
>
>Perhaps general introspection? ;-)

Not yet. I'd like to obtain it from Objective-Ada.

>To be honest, I don't think that access-to-component variables can be
>added to Ada as transparently as it is possible in, say C++.  The involved
>offset might not be constant for types with discriminants, which makes
>implementations of this feature quite complicated.

That's why I want to add it to the compiler, because only it can decide how
to determine it or reject it completly for such reasons. I can only write my
generic package, distribute it, and fail a few years later in a complicated
production enviroment (usually a few hours before deadline).

>>>> Problem 2: Defining Byte_Order of record representations
>
>> Unfortunly I have to deal with memory mapped I/O (i.e. network cards)
>
>You didn't mention this...

Sorry, I shortend the problem a bit.

>> You miss the point. Providing such packages does not allow the compiler to
>> generate good maschine code.
>
>You need the conversion package anyway, at least that's my experience.
>Otherwise, your code is quite unportable, as you're passing around
>invalid values.

If my suggestion is part of the AdaYY specification, it would be perfectly
portable. Currently only packed bit fields can be used to address
representation issues correctly in a portable way.

>> >> Problem 3: Static expressions of discriminants in record representations
>
>> *Gna* And now remove the limitation, that the discriminants have to appear
>> first.
>
>Aha, this was the intent of your comment (I thought you were talking
>about the source code location).  Are trailing size specifies really
>common?  To me, they don't make much sense.
>
>> Even better: Try to write a program, which derivates the type from a pointer.
>
>Sorry, what do you want to do?

The problem escaped from a 'multiprotocol router'. Please try to map a IPv4
header incl. payload and IP-header options.
 
    head_len at 0 range 0 .. 3; -- or 4 .. 7 depending on the bit order.
    ...
    payload at head_len*4 range 0 .. packet_len - 32*head_len;