More C type errors by default for GCC 14

[David Brown]

On 11/05/2023 04:09, Po Lu via Gcc wrote:
> jwakely.gcc@gmail.com (Jonathan Wakely) writes:
> 
>> So let's do it. Let's write a statement saying that the GCC developers
>> consider software security to be of increasing importance, and that we
>> consider it irresponsible to default to accepting invalid constructs in the
>> name of backwards compatibility. State that we will make some changes which
>> were a break from GCC's traditional stance, for the good of the ecosystem.
> 
> I'm sorry you think that way.
> 
>> Given recent pushes to discourage or outright ban the use of memory-safe
>> languages in some domains, I think it would be good to make a strong
>> statement about taking the topic seriously. And not just make a statement,
>> but take action too.
>>
>> If we don't do this, I believe it will harm GCC in the long run. The vocal
>> minority who want to preserve the C they're used to, like some kind of
>> historical reenactment society, would get their wish: it would become a
>> historical dead end and go nowhere.
> 
> Vocal minority? Do you have any evidence to back this claim?
> 
> What I see is that some reasonable organizations have already chosen
> other C compilers which are capable of supporting their existing large
> bodies of C code that have seen significant investment over many years,
> while others have chosen to revise their C code with each major change
> to the language.
> 
> The organizations which did not wish to change their code did not
> vocally demand changes to GCC after GCC became unsuitable, but quietly
> arranged to license other compilers.
> 
> Those that continue write traditional C code know what they are doing,
> and the limitations of traditional C do not affect the quality of their
> code.  For example, on the Unix systems at my organization, the SGS is
> modified so that it will not link functions called through a declaration
> with no parameter specification with a different set of parameters than
> it was defined with.
> 
> Naturally, the modified linker is not used to run configure scripts.
> 

Let's be absolutely clear here - gcc has been, and will continue to be, 
able to compile code according to old and new standards.  It can handle 
K&R C, right through to the cutting edge of newest C and C++ standards. 
It can handle semantic requirements such as two's complement wrapping 
and "anything goes" pointer type conversions - features that a lot of 
old code relies on but which are not documented or guaranteed behaviour 
for the vast majority of other compilers.  It can handle all these 
things - /if/ you pick the correct flags.

With the proposed changes, you can still compile old K&R code with gcc - 
if you give it the right flags.  No features are being removed - only 
the default flags are being changed.  If anyone is changing from gcc to 
other compilers because they think newer gcc does not support older 
code, then they are perhaps doing so from ignorance.

If some users are willing to change to different compilers, but 
unwilling to learn or use new flags in order to continue using their 
existing compiler after it changes its defaults, then perhaps gcc could 
pick different defaults depending on the name used for the executable? 
If it is invoked with the name "gcc-kr", then it could accept K&R code 
by default and have "-std=gnu90" (I believe that's the oldest standard 
option).  If it is invoked as "gcc", then it would reject missing 
function declarations, implicit int, etc., as hard errors.

Then these users could continue to use gcc, and their "new" compiler to 
handle their old code would be nothing more than a symbolic link.

David