Re: Endian-specific types

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Sep 10, 2016 at 04:39:18PM -0400, Mouse wrote:
 > >> Much of the problem with endian-specific types is that - at least in
 > >> C, and I think in C++ - types describe values, and endianness is not
 > >> a property of a value; it's a property of a value as serialized into
 > >> an octet (or other unit smaller than the value) stream.  [...]
 > > But it does make sense to talk about the byte-endianness of a word in
 > > memory, and then hey what do you know, it's a property of a variable.
 > 
 > True as far as it goes.  But what you really want there is a type with
 > type-specific methods for loading and storing.  That is, you need a
 > language that has a distinction - or at least has the ability to create
 > a distinction - between values qua values and values-as-stored.

Maybe. But on most machines, if you load an opposite-endian word from
memory, you get an opposite-endian word in a register, which you then
need to swap before you do arithmetic on it. Which is what happens in
ordinary (unannotated) code when you read e.g. sin_port and call ntohs
on it.

So it doesn't really work that way. In any event it's a useful
annotation, whether or not the compiler understands it, because a
program checker certainly can.

 > That's why I think trying to do endian-specific types in C - possibly
 > excepting as a compiler extension - is a mistake.

Well, it has to be a compiler extension because it's not in the
language spec...

-- 
David A. Holland
dholland%netbsd.org@localhost