[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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





Reply to: