Fwd: Re: Should atomic_xxx() functions reject not-_Atomic() arguments ?

Fwd: Re: Should atomic_xxx() functions reject not-_Atomic() arguments ?

[Chris Hall]

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