On Sun, 16 Feb 2025 20:16:56 -0700, Arthur Naseef <artnas...@apache.org> wrote:
| For the Strict Aliasing Rule, IIUC, the compiler is complaining about the | (void*) cast from (Node *), right? It's complaining about (volatile void**)(&node->next). The more I look at this, the more mystified I get. The volatile keyword is meant to disallow verious kinds of compiler optimizations that could save on memory accesses. But what is volatile in (volatile void **)? The decoder at https://cdecl.org says "cast unknown_name into pointer to pointer to volatile void" Which makes no sense at all. Normally, 'void *' means universal pointer, freely convertible to any other type. So, for example if a function takes a void* argument, the caller need not cast the value being passed in to (void *). Need not, and in general should not (i.e. "best practice"). This is similar to leaving (void *) casts out of calls to malloc() in C. Which leads me to think that the problem is actually with the function declaration in Atomics.h compareAndSet(volatile void** target, void* expect, void* update); What's really wanted here for the first argument? A volatile pointer to a void pointer? That is (void ** volatile). A pointer to a volatile void pointer? That is (void * volatile *). Neither matches (volatile void **). The compiler probably just passes in the Node* unchanged and no harm is done. The context here is a linked list queue where each item is "owned" by a different thread, so when a thread wants to unlink its owh item, it needs to update the next pointer of the previous item, which is owned by some other thread. Hence either locks, or atomic operations with enforced memory accesses on both sides of the change. | The only way I can see to fix it would be to simply inline that operation. I think the better part of valor here would be to just leave this code be, unless (or until) someone who groks the deep internals of decaf can weigh in. 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
