activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Strasheim (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQCPP-41) Byte swap on float and double truncates values
Date Wed, 10 Jan 2007 15:37:48 GMT

    [ https://issues.apache.org/activemq/browse/AMQCPP-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37854
] 

Albert Strasheim commented on AMQCPP-41:
----------------------------------------

Looking at the stack trace produced by Valgrind when it detects the error that happens in
byteSwap also seems to indicate that inlining is happening. Valgrind reports the method at
the top of the stack as readDouble from BytesMessageCommand, but the source line as being
in Endian.h.

> Byte swap on float and double truncates values
> ----------------------------------------------
>
>                 Key: AMQCPP-41
>                 URL: https://issues.apache.org/activemq/browse/AMQCPP-41
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>    Affects Versions: 1.1
>            Reporter: Albert Strasheim
>         Assigned To: Timothy Bish
>            Priority: Critical
>             Fix For: 1.1
>
>         Attachments: doublefloat-truncate.diff
>
>
> activemq::util::Endian::byteSwap truncates float and double values due to the C-style
cast it uses.
> Patch for BytesMessageCommandTest is attached that shows the problem. One might consider
expanding this test to check that the minimum, maximum, -1, 0, 1 (and -inf and inf where appropriate)
and a few other values can successfully be serialised and deserialised for each of the types.
> Also in the patch is our attempt at fixing byteSwap. You'll notice that we do something
very strange: we take the argument of byteSwap and make a copy on the heap. The reason for
this is that simply doing:
> {noformat}
> const uintxx_t swapped_val = byteSwap( *(uintxx_t*)(&value) );
> {noformat}
> i.e. taking the address of value instead of using the copy on the heap, fails with GCC
4.0.2 and GCC 4.0.3. I'm guessing GCC might be trying to inline the call to byteSwap and then
something goes very wrong when taking the address of a variable on the stack. Hopefully someone
has a better idea for a workaround.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message