Bug 468026 - Problem in FieldTable encoding of doubles
Problem in FieldTable encoding of doubles
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
1.0
All Linux
high Severity high
: 1.1
: ---
Assigned To: Gordon Sim
Kim van der Riet
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-22 09:56 EDT by Matthew Farrellee
Modified: 2009-03-20 04:08 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-20 04:08:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Farrellee 2008-10-22 09:56:40 EDT
On the producer side (C++) a FieldTable::setDouble(..., double) is called, e.g. setDouble("CURRENT", 3.000000)

10/22 09:44:05 Limit: b; Current: 3.000000, Max: 3.000000
10/22 09:44:05 Limit: c; Current: 3.000000, Max: 3.000000
10/22 09:44:05 Limit: a; Current: 3.000000, Max: 3.000000

On the consumer side (python) the doubles appear to have been corrupted

qpid: Call Result: GetLimits  0 (OK) {'Limits': {u'a': {u'CURRENT': 1.0434666440167127e-320, u'MAX': 1.0434666440167127e-320}, u'c': {u'CURRENT': 1.0434666440167127e-320, u'MAX': 1.0434666440167127e-320}, u'b': {u'CURRENT': 1.0434666440167127e-320, u'MAX': 1.0434666440167127e-320}}}
Comment 1 Gordon Sim 2008-10-24 07:38:47 EDT
Fixed in r707604. Also added test: qpid/cpp/src/tests/run_header_test. This involves a c++ client sending a message with a float and a double in the header (header_test.cpp) and a python client reading that message and verifying the values of those two headers (header_test.py).

Ideally want to expand this to be bi-directional and to cover a wider range of types.
Comment 2 Frantisek Reznicek 2008-11-11 12:06:40 EST
RHTS test qpid_test_fieldtable_encoding_issue_bz468026 shows that double value is now correctly handled. 
There is apparently problem with int64_t type which is going to be filled as separate problem.
->VERIFIED

Note You need to log in before you can comment on or make changes to this bug.