Bug#568881: gnat-4.4: Type to stream input/output broken on big endian archs

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

xavier grave wrote:
> Ludovic Brenta a écrit :
>>> As far as I understood streams, the output should be neutral regarding
>>> of the architecture.
>>
>> Where did you get that idea?
> 
> Using gnat 3.15p I didn't have this kind of problem.
> I used to push to a stream connected to a socket an integer type
> without bothering about endianness.

Then I guess you were using a stream of a specific type that did the
bothering for you, converting everything to network byte order because
it was a *socket* stream type.  For a stream attached to a file, the
compiler cannot assume that you need to convert to network byte order.

>> The output seems perfectly normal to me. And
>> remember that I used to to embedded programming on PowerPC and deal with
>> endianness issues :)
> 
> I don't dare to question your competences :)
> 
>> ARM 13.13.2(9/2) says: "[...] the representation of those stream
>> elements is implementation defined. [...]"
> 
> Let assume I have a symmetric program to read from my stream (ie here my
> file). If I read the file on an arch different of the one that was used
> to write it, Ada should ensure me (as far as I understand the point of
> portability) that I can read from my stream without thinking about it
> because a Ada.Streams is a standard package.

No, I don't think that's true.  GNAT on amd64 and GNAT on sparc are two
different implementations of Ada and nothing forces them to use inefficient
conversions to network byte order without consent from the programmer.
Therefore, if you need such conversion, you must say so explicitly.

Maybe you'd like to look at http://www.ibpaus.de/downloads/index.html

-- 
Ludovic Brenta.