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
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.ada
Subject: Re: AI12-0218:  What is the portable representation clause for
 processing IETF packets on little-endian machines?
Date: Thu, 10 May 2018 16:07:16 -0700
Organization: A noiseless patient Spider
Message-ID: <87po23yusb.fsf@nightsong.com>
References: <ec0145a4-9698-41f2-bc70-964dc1850e50@googlegroups.com>
	<9af47760-e731-4cb5-a1a0-d63e31019ce5@googlegroups.com>
	<877eob1cc6.fsf@nightsong.com>
	<c9986056-cc3d-432b-839d-fa226eb6e5f8@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org;
 posting-host="8ee8a87c586ad688bbbd7b3afaf6ee4e";
	logging-data="28373"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/uE35UUfL5/q1O113cdH1h"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
Cancel-Lock: sha1:1ELK/XKmF88fdzjsK7wx/y5Os1Q=
	sha1:PT0ZnJkP1tYMy/9boh6co3yhZpU=
Xref: reader02.eternal-september.org comp.lang.ada:52228
Date: 2018-05-10T16:07:16-07:00
List-Id: <comp.lang.ada>

"Dan'l Miller" <optikos@verizon.net> writes:
> Btw, bitfields in C and in Erlang are •the• roughly analogous language
> feature corresponding to representation clauses in Ada

Can you suggest a more complete description of representation clauses
than in Ada 95 Distilled?  If they mean what I expected them to mean,
they actually specify the memory layout of the data object.

That is, if you use a hypothetical endianness representation clause to
declare something like "type bigint32 is int32 big_endian", then a
record containing "x, y : bigint32" will actually require x and y to be
stored in memory in big-endian byte order, and will show up that way if
you dump the memory region to disk.

That particularly means if the hardware happens to be little-endian and
you want to add x and y together with a 32-bit "add" machine
instruction, you are requiring the compiler to generate code that reads
x and y from memory and performs byte swaps before doing the addition.

There is an analogous situation where you declare a decimal integer in
PL/I or COBOL on a binary machine (i.e. almost any machine of the past
several decades).  In that case the integer is stored in BCD and
converted before and after any arithmetic.  It is ok to do that because
those sorts of programs simply don't do much arithmetic, so the
performance hit is not so bad.

I've never seen a network program do it like that though.  Everyone just
makes sure that network integers are converted to the host format before
being stored in memory, and converted back when sent over the network.