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 05:48:02 PST Path: supernews.google.com!sn-xit-03!supernews.com!freenix!teaser.fr!fr.clara.net!heighliner.fr.clara.net!grolier!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.easynews.net!newsfeed2.easynews.net!easynews.net!news.cid.net!news.enyo.de!news1.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: AdaYY wish list from current projects Date: 23 Feb 2001 14:54:32 +0100 Organization: Enyo's not your organization Message-ID: <87lmqx1p47.fsf@deneb.enyo.de> References: <96ulad$r9e$1@belenus.iks-jena.de> <87u25nnfer.fsf@deneb.enyo.de> <87elwp3fw4.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Xref: supernews.google.com comp.lang.ada:5469 Date: 2001-02-23T14:54:32+01:00 List-Id: 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. 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. 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. If you do not follow these rules, you end up with code which depends heavily on the Ada implementation (even on the compiler flags used), and which is probably less robust than it could be. 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. > >> Even better: Try to write a program, which derivates the type from a pointer. > > > >Sorry, what do you want to do? Sorry, I still do not understand what you mean by 'derivates the type from a pointer'. > 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.