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:3e8a:: with SMTP id l132-v6mr1950710ioa.35.1526004665624; Thu, 10 May 2018 19:11:05 -0700 (PDT) X-Received: by 2002:a9d:4509:: with SMTP id w9-v6mr179810ote.10.1526004665418; Thu, 10 May 2018 19:11:05 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder3.usenet.farm!feed.usenet.farm!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u74-v6no106237itb.0!news-out.google.com!b185-v6ni2itb.0!nntp.google.com!v8-v6no97609itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 10 May 2018 19:11:05 -0700 (PDT) In-Reply-To: <87wowbx9e6.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> <87po23yusb.fsf@nightsong.com> <87603vyqxc.fsf@nightsong.com> <38ef3024-cc04-43bf-991f-7569eae82f45@googlegroups.com> <87wowbx9e6.fsf@nightsong.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <3c2c787e-227e-4066-b397-47b23bad3c43@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:11:05 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52240 Date: 2018-05-10T19:11:05-07:00 List-Id: On Thursday, May 10, 2018 at 8:34:46 PM UTC-5, Paul Rubin wrote: > =E2=80=A6 if you want to increment n on a > little-endian machine, you have to read it from memory, swap the bytes > around, increment, swap around the bytes of the result, and write them > back out to memory. Reading and assignment are the only operations that are essential to suppor= t on fields whose representation is governed by endian representation claus= es. Arithmetic on temporaries extracted from the oddball representation wo= uld be an expendable luxury. > Normally a network programmer wouldn't do that. My point is normally a network programmer does exactly what you describe = =E2=80=A2=E2=80=A2in C=E2=80=A2=E2=80=A2, not Ada, because the engineer yea= rs or decades ago established that C's macros and pointer arithmetic can do= what Ada's record representation clauses cannot, and C's macros and pointe= r arithmetic can do what is disdained as uncouth to be performed by Ada's v= arious accesses: byte manipulations. > They'd read the > big-endian sequence 07 5B CD 15 from the network, convert it (using a > macro) Ada doesn't have such a macro processor. > to the endianness of whatever machine they are running on, and > store it in memory in the machine's native byte order. Then if they > want to increment it, they just use an increment instruction with no > byte swapping needed. Finally if they want to write it back out to the > network, they convert it to network byte order before sending. Of course this whole topic is focused on the perimeter of the system at the= incoming edge of input from network (or reading from registers in a memory= -mapped IC) and at the outgoing edge of output to network (or writing to re= gisters in a memory-mapped IC). Of course this is not about heterogenous e= ndianness utilized deep throughout the guts of software designs. (Nor is t= his about [preposterous] heterogenous endianness among the registers within= a single processor=E2=80=94memory, memory, memory of a transient artifact = incoming to the system or outgoing from the system.)