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

["Gordon Sim (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/QPID-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gordon Sim closed QPID-3540.
----------------------------

> 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 was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org