More C type errors by default for GCC 14

[David Brown]

On 09/05/2023 21:04, Eli Zaretskii via Gcc wrote:
>> From: Jonathan Wakely <jwakely.gcc@gmail.com>
>> Date: Tue, 9 May 2023 18:15:59 +0100
>> Cc: Arsen Arsenović <arsen@aarsen.me>, gcc@gcc.gnu.org
>>
>> On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote:
>>>
>>> No one has yet explained why a warning about this is not enough, and
>>> why it must be made an error.  Florian's initial post doesn't explain
>>> that, and none of the followups did, although questions about whether
>>> a warning is not already sufficient were asked.
>>>
>>> That's a simple question, and unless answered with valid arguments,
>>> the proposal cannot make sense to me, at least.
>>
>> People ignore warnings. That's why the problems have gone unfixed for
>> so many years, and will continue to go unfixed if invalid code keeps
>> compiling.
> 
> People who ignore warnings will use options that disable these new
> errors, exactly as they disable warnings.  So we will end up not
> reaching the goal, but instead harming those who are well aware of the
> warnings.
> 

My experience is that many of the people who ignore warnings are not 
particularly good developers, and not particularly good at 
self-improvement.  They know how to ignore warnings - the attitude is 
"if it really was a problem, the compiler would have given an error 
message, not a mere warning".  They don't know how to disable error 
messages, and won't bother to find out.  So they will, in fact, be a lot 
more likely to fix their code.


> IOW, if we are targeting people for whom warnings are not enough, then
> we have already lost the battle.  Discipline cannot be forced by
> technological means, because people will always work around.
> 

Agreed.  But if we can make it harder for them to release bad code, 
that's good overall.

Ideally, I'd like the compiler to email such people's managers with a 
request that they be sent on programming courses!