-Wclass-memaccess warning should be in -Wextra, not -Wall

[Martin Sebor]

On 07/09/2018 07:22 PM, Soul Studios wrote:
>> On 07/05/2018 05:14 PM, Soul Studios wrote:
>>> Simply because a struct has a constructor does not mean it isn't a
>>> viable target/source for use with memcpy/memmove/memset.
>>
>> As the documentation that Segher quoted explains, it does
>> mean exactly that.
>>
>> Some classes have user-defined copy and default ctors with
>> the same effect as memcpy/memset.  In modern C++ those ctors
>> should be defaulted (= default) and GCC should emit optimal
>> code for them.  In fact, in loops they can result in more
>> efficient code than the equivalent memset/memcpy calls.  In
>> any case, "native" operations lend themselves more readily
>> to code analysis than raw memory accesses and as a result
>> allow all compilers (not just GCC) do a better a job of
>> detecting bugs or performing interesting transformations
>> that they may not be able to do otherwise.
>>
>>> Having benchmarked the alternatives memcpy/memmove/memset definitely
>>> makes a difference in various scenarios.
>>
>> Please open bugs with small test cases showing
>> the inefficiencies so the optimizers can be improved.
>>
>> Martin
>>
>
>
> My point to all of this (and I'm annoyed that I'm having to repeat it
> again, as it my first post wasn't clear enough - which it was) was that
> any programmer using memcpy/memmove/memset is going to know what they're
> getting into.

No, programmers don't always know that.  In fact, it's easy even
for an expert programmer to make the mistake that what looks like
a POD struct can safely be cleared by memset or copied by memcpy
when doing so is undefined because one of the struct members is
of a non-trivial type (such a container like string).

> Therefore it makes no sense to penalize them by getting them to write
> ugly, needless code - regardless of the surrounding politics/codewars.

Quite a lot of thought and discussion went into the design and
implementation of the warning, so venting your frustrations or
insulting those of us involved in the process is unlikely to
help you effect a change.  To make a compelling argument you
need to provide convincing evidence that we have missed
an important use case.  The best way to do that in this forum
is with test cases and/or real world designs that are hampered
by our choice.  That's a high bar to meet for warnings whose
documented purpose is to diagnose "constructions that some
users consider questionable, and that are easy to avoid (or
modify to prevent the warning)."

Martin