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:a6c4:: with SMTP id p187-v6mr1926708ioe.65.1526006339742; Thu, 10 May 2018 19:38:59 -0700 (PDT) X-Received: by 2002:a9d:830:: with SMTP id 45-v6mr183115oty.7.1526006339565; Thu, 10 May 2018 19:38:59 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u74-v6no120667itb.0!news-out.google.com!f20-v6ni1itd.0!nntp.google.com!u74-v6no120664itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 10 May 2018 19:38:59 -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: <9af47760-e731-4cb5-a1a0-d63e31019ce5@googlegroups.com> <877eob1cc6.fsf@nightsong.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5c9b9f90-884f-4de7-8663-d39a67949f4f@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: Fri, 11 May 2018 02:38:59 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52241 Date: 2018-05-10T19:38:59-07:00 List-Id: On Thursday, May 10, 2018 at 5:44:21 PM UTC-5, Niklas Holsti wrote: > Both the example, and the Erlang reference manual section linked from=20 > the example, describe an "endianness" attribute that can be given one of= =20 > the values "big", "little", "native", with default "big". Ah, yes, now I see it. Thank you for pointing that out. I apologize, Paul= . > However, it=20 > seems this attribute applies only to a restricted set of types: integer,= =20 > utf16, utf32 and float. >=20 > It is not clearly explained how endianness is interpreted for fields=20 > that do not align with octet boundaries. Ah, Paul & Randy & Dmitry, right there might be the best card for the oppos= ition to play: endianness (independent of Ada's record representation clau= ses) has absolutely nothing at all to do with arbitrary bitfields. Endiann= ess exists when reading 16-, 32-, 64-, 80-, 128-, 256-, and 512-bit words f= rom memory or writing them to memory. Hence, incorrect endianness of proce= ssing, say, an IETF packet header depends on the =E2=80=A2=E2=80=A2word siz= e (arbitrarily chosen to be) utilized by the software=E2=80=A2=E2=80=A2 to = (capriciously) access the fields within (or crossing the boundaries of) tha= t 16-, 32-, 64-, etc-bit word, not the =E2=80=A2record itself=E2=80=A2. It= only becomes part of the record per se when trying to utilize Ada's record= representation clauses or C's struct-of-bitfields type-casting. Endiannes= s is on a plane above the fields of the record=E2=80=94the parent nodes of = a tree (of word boundaries) hovering above the record, casting a shadow of = these boundary-lines, so to speak, on the bitwise fields that might not be = byte or word aligned at all, within the words or crossing the boundary of w= ords. Still, standard Ada has no good Ada-esque solution to heterogenous endianne= ss at the perimeter of a system, other than writing C-esque pointer-arithme= tic code with the various unchecked_ constructs (which even C programmers d= on't generally do; they utilize conditionally-compiled macros that correctl= y type-cast meticulously*-laid-out structs-of-bitfields onto that packet's = header or IC register's word. * on a per-processor, per-toolchain basis, selected via the conditional com= pilation via the C preprocessor. This selection (out of nonportable catego= rization) is what accomplishes the portability. Ada has no equivalent othe= r than AI32-0218's/GNAT's solution.