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 06:18:06 PST
From: lutz@iks-jena.de (Lutz Donnerhacke)
Newsgroups: comp.lang.ada
Subject: Re: AdaYY wish list from current projects
Date: 23 Feb 2001 14:16:21 GMT
Organization: IKS GmbH Jena
Distribution: world
Message-ID: <slrn99cs08.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>
 <slrn99cdnh.ju.lutz@taranis.iks-jena.de> <87lmqx1p47.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)
Path: 
 supernews.google.com!sn-xit-03!supernews.com!freenix!fr.clara.net!heighliner.fr.clara.net!grolier!newsfeed00.sul.t-online.de!t-online.de!stueberl.r-kom.de!news-ffm.transmedia.de!news1.transmedia.de!news-FFM2.ecrc.net!news.iks-jena.de!lutz
Xref: supernews.google.com comp.lang.ada:5473
Date: 2001-02-23T14:16:21+00:00
List-Id: <comp.lang.ada>

* Florian Weimer wrote:
>lutz@iks-jena.de (Lutz Donnerhacke) writes:
>> >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.
>
>I think you've missed the point.

Yep. I talk about values crossing a storage_element boundary and you talk
about invalid values.

>If you use enumeration representation clauses which are sparse (i.e. not
>every representation has a corresponding enumeration literal), you're
>dealing with invalid representations.

The same is true for all subtypes I use:
  subtype Header_Length is Integer range 5 .. 15;

>If you never, ever copy any such values and always check using the Valid
>attribute that the representation is not invalid before using it in
>computations, you might actually have portable code.

Full ACK. But it's a difference between:
    if not data'Valid then ...
and
    declare
       data1 : Component_Type_1 := Endianess_Conversion_1 (data.f1);
       data2 : Component_Type_2 := Endianess_Conversion_2 (data.f2);
       data3 : Component_Type_3 := Endianess_Conversion_3 (data.f3);
       data4 : Component_Type_4 := Endianess_Conversion_4 (data.f4);
    begin
       if not data1'Valid or else not data2'Valid or else
          not data3'Valid or else not data4'Valid then
	   ...
       end if;
    end;

>So I still claim that little endian/big endian integers are sufficient
>for most (almost all?) applications and it's not necessary to an
>endian property to enumeration types, or to add even more complexity
>to representation clauses.

I do not talk about endianess of enumeration types but of repesentation
issues of record types.

>Sorry, I still do not understand what you mean by 'derivates the type
>from a pointer'.

procedure t is
   type pstring(len : Integer) is record
      data : String (1 .. len);
   end record;
   pragma Pack (pstring); --  record representation clause not possible
   
   ex : pstring;  --  Won't work;
   for ex'Address use 16#00000#;
begin
   Put_Line (Integer'Image (ex.len) & " => " & ex.data);
end t;

Using Address_To_Access_Conversions does solve the problem but is really ugly.

>> The problem escaped from a 'multiprotocol router'. Please try to map a IPv4
>> header incl. payload and IP-header options.
>
>Ah.  Well, obviously, you can't use a single record in this case.

So I'm stuck to implement gather-scatter from the beginning. ;-/