You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Chuck Rolke (Created) (JIRA)" <ji...@apache.org> on 2011/10/10 18:05:30 UTC
[jira] [Created] (QPID-3540) Typecasting and alignment requirements
for various platforms - "increases required alignment of target type"
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
[jira] [Resolved] (QPID-3540) Typecasting and alignment
requirements for various platforms - "increases required alignment of
target type"
Posted by "Chuck Rolke (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chuck Rolke resolved QPID-3540.
-------------------------------
Resolution: Fixed
> 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