[jira] [Resolved] (QPID-3540) Typecasting and alignment requirements for various platforms - "increases required alignment of target type"

["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