qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chuck Rolke (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (QPID-3540) Typecasting and alignment requirements for various platforms - "increases required alignment of target type"
Date Mon, 10 Oct 2011 16:05:30 GMT
Typecasting and alignment requirements for various platforms - "increases required alignment
of target type"
------------------------------------------------------------------------------------------------------------

                 Key: QPID-3540
                 URL: https://issues.apache.org/jira/browse/QPID-3540
             Project: Qpid
          Issue Type: Bug
          Components: C++ Broker, C++ Client
    Affects Versions: 0.12
         Environment: c++ on platforms that have strict alignment requirements
            Reporter: Chuck Rolke
             Fix For: Future


On sparc/solaris (and others) the following code generates an error:

  qpid/cpp/src/qpid/RefCountedBuffer.cpp line 37
    boost::intrusive_ptr<RefCounted>(reinterpret_cast<RefCountedBuffer*>(store)),

A workaround is the '(void *)' hack that quiets the compiler but leaves the
code exposed to a run time fault if the store object is not properly aligned:

    boost::intrusive_ptr<RefCounted>(reinterpret_cast<RefCountedBuffer*>((void*)store)),

Another error shows up in
  
  qpid/cpp/src/tests/qpid-perftest.cpp line 647
    size_t n = *reinterpret_cast<const size_t*>(msg.getData().data() + offset);

The (void *) hack silences the error here, too, but the run time code is exposed to
a data alignment fault.

I propose that these two pieces of code need work to guarantee the alignment
or to work around any memory reference fault.

1. In the store case, new() probably returns an address that meets the alignment
requirement. An assert would help diagnose when this assumption fails.

2. In the qpid-perftest case the size_t could be extracted from the raw buffer
with a memcpy and that would be safe to do in all architectures.

2A. A separate issue is the fact that size_t changes between 32-bit and 64-bit
platforms, and that the size_t does not appear to be byte swapped for interop
between big and little endian systems. If these messages are consumed only
by the sender then no problem.




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message