Deprecating arithmetic on std::atomic<void*>

Jonathan Wakely jwakely@redhat.com
Thu Apr 20 10:03:00 GMT 2017


On 20/04/17 11:57 +0200, Florian Weimer wrote:
>On 04/20/2017 11:52 AM, Jonathan Wakely wrote:
>>On 20/04/17 11:43 +0200, Florian Weimer wrote:
>>>On 04/20/2017 11:25 AM, Jonathan Wakely wrote:
>>>
>>>>>I mean, with -pedantic-errors we already error on void * arighmetics
>>>>>or function pointer arithmetics.  If std::atomic<void*> would use
>>>>>the void * arithmetics, it would also reject it.  Or does it 
>>>>>use integer
>>>>>arithmetics instead?
>>>>
>>>>No, it does it on void*, but the __atomic built-ins still perform that
>>>>arithmetic even with -pedantic-errors.
>>>
>>>sizeof is not defined for the relevant types, either, and already 
>>>triggers a warning by default:
>>>
>>>t.cc:25:58: warning: invalid application of ‘sizeof’ to a void 
>>>type [-Wpointer-arith]
>>>  _M_type_size(ptrdiff_t __d) const { return __d * sizeof(_PTp); }
>>
>>That could be easily avoided if we care about supporting arithmetic on
>>std::atomic<void*>.
>>
>>>I think the actual problem here is the suppression of warnings 
>>>from system headers.
>>
>>The atomic built-ins still don't warn even with -Wsystem-headers
>
>Sorry, this is what I meant: -pedantic-errors does not catch this case 
>due to the system header warning suppression.  Otherwise, with the 
>current std::atomic implementation, -pedantic-errors would already 
>disable the extension on std::atomic alongside with the extension on 
>built-in pointer types, due to the use of sizeof in the definition of 
>_M_type_size.

Ah yes, you're right.

Yet another case where warning suppression in system headers hurts the
library's ability to give diagnostics. We can't warn about using
incomplete types in std::unique_ptr because the -Wdelete-incomplete
warning gets suppressed, and the interaction of #pragma GCC diagnostic
with -Wsystem-headers is ... interesting. We need a way to enable
warnings for specific blocks of code, to say "do not suppress warnings
here, even though it's in a system header".




More information about the Libstdc++ mailing list