Fwd: Re: Should atomic_xxx() functions reject not-_Atomic() arguments ?
Mon Mar 9 12:14:10 GMT 2020
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.
>> 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).
More information about the Gcc-help