On 08/03/2020 20:11, Martin Sebor wrote:
On 3/7/20 6:04 AM, Chris Hall wrote:
...
I wonder if, by extension, the atomic_xxx() should (at least) warn when the _Atomic() parameters are passed not-_Atomic() arguments ?
I think it would be useful to expose a command-line option in GCC to request a diagnostic for uses of the APIs with non-atomic types. Making it an error would probably not be a great solution because of the risk of breaking working code that has come to rely on it.
I guess existing code could continue to be compiled without the "revised API" option (and continue to work as well as it did before). For new/updated code I think an error makes the point with suitable force. The programmer can always cast to _Atomic(), if they are confident that all their intended targets will work. The "revised API" could also fix the fetch-add for pointers.
But...
As I have said elsewhere, I think the real problem is that the Standard fails to define vital things as Implementation Defined, leaving the programmer guessing as to what their code is going to do when compiled for some machine/system they are not familiar with.
...in particular: if I feel brave and cast (say) uint64_t to _Atomic(uint64_t), I don't have any obvious way to trigger a warning/error when compiling for a machine/system for which the cast is a grave mistake (for whatever reason).
Chris
