Re: Endianness independance

[Stephen Leake <Stephen.A.Leake@nasa.gov>]

Lionel.DRAGHI@fr.thalesgroup.com writes:

> | -----Message d'origine-----
> | De: Marin David Condic [mailto:mcondic.auntie.spam@acm.org]
> ...
> | 
> | Realistically, the answer is to assess the communications 
> | mechanisms needed,
> | establish a clearly defined protocol & representation and 
> | then build your
> | software to deal with that. Ada can be very good at handling the
> | representation selected, but it really can't define the 
> | representation for
> | you.
> 
> I agree with this. 
> What i am complaining about, is that you can't just rely on representation
> clauses to have interoperability between the same code compiled on two
> different platform, and exchanging data through a stream socket for exemple.
> I think that the representation/size/alignment clauses could give enough
> informations to the compiler to ensure interoperability (provided RM
> modifications). 

It is not possible to get compatible stream representations via
representation clauses.

You must override 'Write and 'Read to get that. 

The reason is that representation clauses can't swap bytes within
scalars (integers and floats), as is required by endian-independant
stream representations.

> Am i wrong? 

No.

> As said Amir Yantimirov: "But including notion of endianess (as kind
> of storage specifier) in existent Ada type system seems impossible
> to me."

The problem is there are _two_ requirements for endianness;

1) match the native hardware

2) match the stream representation

The compiler matches the native hardware for scalars, and rep clauses
allow you to match the native hardware for records.

Stream attributes allow you to match the stream representation. This
allows for more complex things than just endianness.

> Note that Norman Cohen's paper do not address the whole
> interoperability problem, he just propose a way to portably specify
> "a data layout". 

Correct. He addresses 1) above, but not 2).

> However, this is, i think, the most difficult part of the job.

The most difficult part is the one you haven't figured out yet;
everything else is easy :).

-- 
-- Stephe