So, as it turns out the code I looked at didn’t use volatile. I also wondered how could they get away without using volatile, but here is a simplified version of what I saw:
uint32_t value = *(uint32_t *)(0xDEADBEEF);
I figured it really should be uint32_t value = *(volatile uint32_t *)(0xDEADBEEF); but I’d need to carefully understand when volatile is valid and when it’s not. I still believe that they should use volatile, and the checker should also recognise and suppress if the pointee is volatile. I planned to implement that.
This confirms my suspicion and I’m happy I reached out. Thank you!
Now that we are here, my plan for the checker is to move it out of the core package so it wouldn’t be enabled by default, into the optin. Update the docs that it recognises the address_space attribute and suppress reports there; but you should probably use volatile that the checker considers as a suppression. Otherwise just prefer not “opting-in” to the checker.
This means that I wouldn’t need to point them (intentionally/unintentionally) to using the address_space attribute. This would solve the issue that prompted me writing this post.