For the Strict Aliasing Rule, IIUC, the compiler is complaining about the
(void*) cast from (Node *), right?

Is there any way two different pointer types have different sizes?  If not,
I agree with the assessment that this is not harmful.  The only way I can
see to fix it would be to simply inline that operation.  If that one
function is only called from that one place, perhaps that's the prudent
thing to do.

Art


On Sat, Feb 15, 2025 at 2:29 PM Arjun Ray <ara...@gmail.com> wrote:

> On Fri, 14 Feb 2025 13:29:26 -0500, Arjun Ray <ara...@gmail.com>
> wrote:
>
> | For example, I think I'm in a position to offer a set of diffs in
> | a JIRA to make the code base C++17 ready.  All that would need is
> | someone with privileges to commit the implied pull requests and
> | test them.
>
> Nearly there! :-)
>
> I've now reduced the C++17 build to 3 warnings (from 197). I don't
> think it's worth the effort to "fix" these.
>
> Two of these are calls to the same function in the OpenSSL library:
> they are "deprecated" because the API itself marks the call that way.
>
> : OSSL_DEPRECATEDIN_1_1_0 unsigned char *ASN1_STRING_data(ASN1_STRING *x);
>
> The other warning has to do with the Strict Aliasing rule at
>
> : src/main/decaf/util/concurrent/locks/AbstractQueuedSynchronizer.cpp:1080
>
> : return Atomics::compareAndSet((volatile void **)(&node->next),
> (void*)expect, (void*)update);
>
> I'm not sure about a good way to fix this; it's not doing any harm
> AFAICT; and this whole section in the depths of the decaf code needs
> to ultmately go away anyway.
>
> An appropriarely placed annotation/comment should suffice.
>
> Testing has turned out to be a problem apparently with the toolset.
> For some reason the integration tests are not building at all.  I'm
> not enough of an Aututools maven to see the problem right away, but I
> suspect it has to do with having built the distro in a separate
> subdirectory so as not to clutter the source files.  But I don't
> anticipate any issues once I have this working.  After that, I'll see
> about filing a JIRA.
>
> Arjun
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org
> For additional commands, e-mail: dev-h...@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>

Reply via email to