[ 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-subscr...@qpid.apache.org