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 X-Received: by 2002:a6b:9c8f:: with SMTP id f137-v6mr5081083ioe.27.1527444240954; Sun, 27 May 2018 11:04:00 -0700 (PDT) X-Received: by 2002:a9d:4503:: with SMTP id w3-v6mr874088ote.7.1527444240708; Sun, 27 May 2018 11:04:00 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u74-v6no4407116itb.0!news-out.google.com!f20-v6ni4250itd.0!nntp.google.com!v8-v6no4436099itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 27 May 2018 11:04:00 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <5f1e44fa-5b78-45a1-a12e-b8089d823540@googlegroups.com> <9ae54be5-0b96-4675-ad95-7a61ecc6fbd0@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <8b3dc953-4720-4226-a4a8-9166f31a394f@googlegroups.com> Subject: Re: AI12-0218: What is the portable representation clause for processing IETF packets on little-endian machines? From: "Dan'l Miller" Injection-Date: Sun, 27 May 2018 18:04:00 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52738 Date: 2018-05-27T11:04:00-07:00 List-Id: 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=C2=A0at the URL below not= the way for the ARG to merely dismiss AI12-0218 as not-a-problem that need= s to be solved, due to already having a solution ever since Record Represen= tation Clause was introduced. > > > > >=20 > 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 pol= itical difficulty to tell AdaCore that there already existed a solution to = the problem as of Ada2005, and that Scalar_Storage_Order was the 2nd soluti= on 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 obviousl= y* is nontrivial to implement, I am baffled why the ARG doesn't definitivel= y reject or kill off AI12-0218 with stronger language. * by both the AI's expansive touch-lots-of-stuff content and Randy's analog= ous that-would-wreak-lots-of-havoc-in-Janus-Ada's-source-code general respo= nse > > > > http://www.ada-auth.org/ai-files/grab_bag/bitorder.pdf > > >=20 > > > This is what has been implemented in Ada 2005. See my post of May 11. > >=20 > > Yes, I know. It seems that AI12-0218 and Scalar_Storage_Order are focu= sed on the wrong topic (i.e., the topic of a 2nd solution to the endian byt= e-swapping). A replacement to AI12-0218 should be focused on =E2=80=A2port= ably=E2=80=A2 (among all Ada compilers) choosing between the 2 alternative = byte-swapping Record Representation Clauses on different targets. >=20 > 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 perfect= ly portable (because they are in fact syntax in ISO standard Ada). What is not portable (due to the =E2=80=A2lack=E2=80=A2 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 ot= her of the two) on a per-target/per-ISA basis. That language-undefined** s= electivity is (needlessly) peculiar** to each Ada compiler's build tool. I= am pretty sure that,=E2=80=94if Jean Ichbiah were alive today to see this = state of affairs on AI12-0218 vis a vis Norman Cohen's use-3-existing-Ada-f= eatures-together-as-they-are-already-designed pedagogical paper,=E2=80=94he= 'd say that the choice of child package to elaborate/use for this target sh= ould be overt Ada-language syntax. I'm pretty sure that he say that it sho= uld not be some nonportable gotchya afterthought in gprbuild or other outsi= de-of-Ada syntax/toolset that is peculiar (differently!) to each Ada toolch= ain. ** in roughly the same =E2=80=9Cundefined behavior=E2=80=9D ballpark concep= tually as ISO standard C++'s historical lack of control on elaboration orde= r of libraries/objects for what C++ calls static instances. Usually Ada ca= res passionately about eliminating target-specific undefined-in-the-languag= e behavior, but, in this case of portably choosing between alternative chil= d packages based on target/ISA via standard Ada syntax (pragma or aspect or= otherwise), not so much.