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:a24:1a57:: with SMTP id 84-v6mr459457iti.36.1525991082532; Thu, 10 May 2018 15:24:42 -0700 (PDT) X-Received: by 2002:a9d:73c9:: with SMTP id m9-v6mr150445otk.9.1525991082388; Thu, 10 May 2018 15:24:42 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!paganini.bofh.team!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!v8-v6no751177itc.0!news-out.google.com!f20-v6ni891itd.0!nntp.google.com!u74-v6no762645itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 10 May 2018 15:24:42 -0700 (PDT) In-Reply-To: <877eob1cc6.fsf@nightsong.com> 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: Subject: Re: AI12-0218: What is the portable representation clause for processing IETF packets on little-endian machines? From: "Dan'l Miller" Injection-Date: Thu, 10 May 2018 22:24:42 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52220 Date: 2018-05-10T15:24:42-07:00 List-Id: On Thursday, May 10, 2018 at 3:32:11 PM UTC-5, Paul Rubin wrote: > "Dan'l Miller" writes: > =E2=80=A6 In C programs you usually just call some > macros to convert machine integers to and from network byte order. In > the case where the machine int's bytes are already in network order, the > macro does nothing. >=20 > Example 4 of this page >=20 > http://erlang.org/doc/programming_examples/bit_syntax.html >=20 > shows how you describe an IP datagram in Erlang: >=20 > -define(IP_VERSION, 4). > -define(IP_MIN_HDR_LEN, 5). >=20 > DgramSize =3D byte_size(Dgram), > case Dgram of=20 > < ID:16, Flgs:3, FragOff:13, > TTL:8, Proto:8, HdrChkSum:16, > SrcIP:32, > DestIP:32, RestDgram/binary>> when HLen>=3D5, 4*HLen=3D > OptsLen =3D 4*(HLen - ?IP_MIN_HDR_LEN), > <> =3D RestDgram, > ... > end. >=20 > It isn't bad, if you are used to Erlang syntax. Those fields like > FragOff:13 are bit fields of the specified lengths. Ummmmmm, Paul, neither your example of C-esque bitfields in Erlang nor the = Erlang tutorial page that you provided nor the Erland reference manual link= in that tutorial page provided a solution to the byte-swapping. How to ac= tually accomplish the byte-swapping portably is the core topic of this enti= re thread and the core topic of AI12-0218. Why post clearly off-topic mate= rial? (Not only Erlang is prima facie off-topic, but bit fields in local-m= achine's endianness without any byte swapping is evermore off-topic, which = could have been made somewhat on-topic if anything in Erlang demonstrated b= yte-swapping in opposing-endianness inter-machine communications, with an a= ir of: if Erlang can elegantly declare the byte-swapping portably on heter= ogenous endianness, then is there an analogous design in pre-AI12-0218 Ada?= ) Everyone: For example, in standard Ada without AI12-0218's proposal, how can one code= up byte-swapping the fields of network byte order (big-endian) IETF packet= headers on a little-endian machine? Is there some clever switcheroo with = processor-specific choice of child packages that contain little- versus big= -endian subroutines analogous to the conditionally-compiled different defin= itions of C macros that both Paul and I have mentioned? Paul: Btw, bitfields in C and in Erlang are =E2=80=A2the=E2=80=A2 roughly analogo= us language feature corresponding to representation clauses in Ada; all the= undefined behavior regarding bitfields in C notwithstanding. Indeed, AIUI= , C's bitfields & their 1970s-known undefined behavior when porting among d= ifferent processors were the public enemy #1 on Ichbiah et al's minds when = they put bitwise representation clauses in Ada. So you undermined your own= line of reasoning there.