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.





--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Also read
http://groups.google.ca/group/comp.lang.ada/browse_thread/thread/4c06e1e4fc2bf2d1

--
Ludovic Brenta.




--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

----------------original message-----------------
De: "Ludovic Brenta" ludovic@ludovic-brenta.org
A: xavier.grave@ipno.in2p3.fr
Copie à: 568881@bugs.debian.org
Date: Mon, 08 Feb 2010 17:02:09 +0100
-------------------------------------------------


>
> 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.

You are right (as usual , sorry for this new non useful bug report), I
have found in a lab corner an old gnat-3.15p install (x86 and ppc) and the
behaviour is exactly the same (different files). So this is the stream
implementation for the sockets in gnat-3.15 that swap the things and no more
with gnat-4.4 ?


>>
>> 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.

So may be I should find the place where the problem is in g-socket*, if
there is a problem at all ?

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

Thanks for the link.





--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org