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!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: AI12-0218: What is the portable representation clause for processing IETF packets on little-endian machines? Date: Tue, 29 May 2018 17:17:43 -0500 Organization: JSA Research & Innovation Message-ID: References: <5f1e44fa-5b78-45a1-a12e-b8089d823540@googlegroups.com><9ae54be5-0b96-4675-ad95-7a61ecc6fbd0@googlegroups.com> Injection-Date: Tue, 29 May 2018 22:17:55 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="3262"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:52769 Date: 2018-05-29T17:17:43-05:00 List-Id: "Simon Wright" wrote in message news:ly4litj7qx.fsf@pushface.org... > AdaMagica 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. Thank goodness. People use rep. clauses all the time in code that permeates an entire program; having very expensive byte swapping code easily triggered would give Ada a reputation of being a slug (rather than understanding that the code misuses the features). The whole idea of portable representation clauses is close to misuse of the feature (the entire value is to ensure that compilers for the same target intepret the clauses the same way). Byte-swapping by its nature has to be restricted to an interface layer, and that layer is almost always target-dependent. Making it easy to "leak" interface info out of that layer is not helping anything. Randy.