Re: AI12-0218: What is the portable representation clause for processing IETF packets on little-endian machines?

["Dan'l Miller" <optikos@verizon.net>]

On Sunday, May 27, 2018 at 9:58:57 AM UTC-5, AdaMagica wrote:
> 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.

There is a chance that the ARG is slow-walking AI12-0218 because of the political difficulty to tell AdaCore that there already existed a solution to the problem as of Ada2005, and that Scalar_Storage_Order was the 2nd solution to the problem, not the first.

Given that the 1st solution already exists in standard Ada2005 (except for the finishing-touch topic below) and that the Scalar_Storage_Order obviously* is nontrivial to implement, I am baffled why the ARG doesn't definitively reject or kill off AI12-0218 with stronger language.

* by both the AI's expansive touch-lots-of-stuff content and Randy's analogous that-would-wreak-lots-of-havoc-in-Janus-Ada's-source-code general response

> > > > 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.
> > 
> > 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.

Yes, the 2 alternative Record Representation Clauses themselves are perfectly portable (because they are in fact syntax in ISO standard Ada).

What is not portable (due to the •lack• of being syntax in ISO standard Ada) is the build-time cleverness to choose one child package (containing one of the two) versus another child package (containing the other of the two) on a per-target/per-ISA basis.  That language-undefined** selectivity is (needlessly) peculiar** to each Ada compiler's build tool.  I am pretty sure that,—if Jean Ichbiah were alive today to see this state of affairs on AI12-0218 vis a vis Norman Cohen's use-3-existing-Ada-features-together-as-they-are-already-designed pedagogical paper,—he'd say that the choice of child package to elaborate/use for this target should be overt Ada-language syntax.  I'm pretty sure that he say that it should not be some nonportable gotchya afterthought in gprbuild or other outside-of-Ada syntax/toolset that is peculiar (differently!) to each Ada toolchain.

** in roughly the same “undefined behavior” ballpark conceptually as ISO standard C++'s historical lack of control on elaboration order of libraries/objects for what C++ calls static instances.  Usually Ada cares passionately about eliminating target-specific undefined-in-the-language behavior, but, in this case of portably choosing between alternative child packages based on target/ISA via standard Ada syntax (pragma or aspect or otherwise), not so much.