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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: AI12-0218:  What is the portable representation clause for
 processing IETF packets on little-endian machines?
Date: Sun, 27 May 2018 19:03:50 +0100
Organization: A noiseless patient Spider
Message-ID: <ly4litj7qx.fsf@pushface.org>
References: <ec0145a4-9698-41f2-bc70-964dc1850e50@googlegroups.com>
	<5f1e44fa-5b78-45a1-a12e-b8089d823540@googlegroups.com>
	<9ae54be5-0b96-4675-ad95-7a61ecc6fbd0@googlegroups.com>
	<ca1a4259-d754-4a04-9470-2d57cd9f148e@googlegroups.com>
	<a9f11f94-401d-44ef-9e78-21231bedd434@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: h2725194.stratoserver.net;
 posting-host="72c963eeffe8f0f65beee661c7eaff64";
	logging-data="27176"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19GmpTMH24uuNNlUXtxtOC7bEQIl0ZNOV0="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (darwin)
Cancel-Lock: sha1:JrLGdQyiRN+kp7iasfdYyIpz4Qg=
	sha1:uvKUq2LItlywkUW2L09Lajgg71g=
Xref: reader02.eternal-september.org comp.lang.ada:52737
Date: 2018-05-27T19:03:50+01:00
List-Id: <comp.lang.ada>

AdaMagica <christ-usch.grein@t-online.de> writes:

> Am Samstag, 26. Mai 2018 23:01:28 UTC+2 schrieb Dan'l Miller:
>> On Saturday, May 26, 2018 at 2:02:12 PM UTC-5, AdaMagica wrote:
>> > Am Samstag, 26. Mai 2018 18:15:30 UTC+2 schrieb Dan'l Miller:
>> > > Why is Norman Cohen's solution in the PDF at the URL below not
>> > > the way for the ARG to merely dismiss AI12-0218 as not-a-problem
>> > > that needs to be solved, due to already having a solution ever
>> > > since Record Representation Clause was introduced.
>> > >
>
> If you look at the last post in this AI, nobody is willing to work on
> it. And if I remember correctly, Randy once said that nobody except
> the author of the AI understands it.
>
>> > > http://www.ada-auth.org/ai-files/grab_bag/bitorder.pdf
>> >
>> > This is what has been implemented in Ada 2005. See my post of May 11.

I just don't see this in AALRM 2012, but 13.5.{2,3} are fairly
opaque. The paper is opaque, too.

AI95-00133 contains extensive references to the paper, but important
things like

   "The interpretation of component_clauses in the nondefault bit order
   is based on machine scalars, which are chunks of storage that can be
   natively loaded and stored by the machine. All of the
   component_clauses at a given offset are considered to be part of the
   same machine scalar, and the first_bit and last_bit are interpreted
   as bit offsets within that machine scalar. This makes it possible to
   write endian-independent record_representation_clauses."

only appear in the AI, not the ALRM.

And I think I'm right in saying that the size of the machine scalar
starting at a given offset is determined by the largest last_bit of any
of the components starting at that offset (so you'd better have a filler
component extending into the top byte if none of the actual components
do).

>> Yes, I know.  It seems that AI12-0218 and Scalar_Storage_Order are
>> focused on the wrong topic (i.e., the topic of a 2nd solution to the
>> endian byte-swapping).  A replacement to AI12-0218 should be focused
>> on •portably• (among all Ada compilers) choosing between the 2
>> alternative byte-swapping Record Representation Clauses on different
>> targets.
>
> I do not understand. As far as I can tell, the Ada 2005 solution with
> its machine scalars is portable.

But it doesn't do byte swapping.