Thank you for answers!
Maybe you didn't notice that the number is not little-endian nor big-endian,
but middle-endian.
It means that it's little-endian in bytes, but big-endian in words. (see
http://en.wikipedia.org/wiki/Endianness#Middle-endian)
Maybe a middleware solve the problem (introducing a little overhead) and lots
of work (i never used), but before, I'll try to upgrade the kernel to armel (as
i read, it's little-endian).
Now, the question is: why, the hell, arm has this "stupid" representation? :)
So, after upgrading I tell you!
Best regards,
Adriano
--- In David Hawkins <> wrote:
>
> Anssi Kolehmainen wrote:
> > On Mon, Mar 23, 2009 at 08:39:26PM -0000, Adriano Naspolini wrote:
> >> I'm having some problems with arm endianess of floating types.
> >
> > Use htonl(), ntohl() and others when writing/reading data. For example
> > keep the data in file in network byte order and then just convert it to
> > host byte order when you read it.
> >
>
> htonl() is for 32-bit data, the original question was regarding
> 8-byte doubles.
>
> The htonl() functions and friends are for XDR data representation,
> so the OP can check the XDR API functions for a double conversion
> routine, or a function to implement it can be easily written.
>
> CDR functions for doubles definitely exist.
>
> Cheers,
> Dave
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|