More C type errors by default for GCC 14

[David Brown]

On 14/05/2023 07:38, Po Lu via Gcc wrote:

> No, all you have to do is to tell GNU CC to compile Standard C.  But
> what's being debated here is the behavior of GNU CC when translating
> both Standard C and GNU C, so your demonstration is almost completely
> pointless.
> 
You keep using the term "Standard C", but you are using it incorrectly.

"Standard C" means "The language C as recognised by standardisation 
bodies".  It is, currently, ISO/IEC 9899:2018 - also known as C17/C18. 
(The standard was completed in C17, but not actually published until C18.)

If you want to refer to older standards (or unpublished future 
standards), you should do so explicitly - C90, C99, C11, C23.

Then there are "extended standards" - specific documented extensions on 
top of an official standard.  "gnu17" would be an example of that.

Any language from before the first ANSI C is /not/ standard, since it is 
not based on any standards document.  The nearest would be the de-facto 
"standard" (anything "de-facto" is, by definition, not an actual 
standard) language described in the first edition of "The C Programming 
Language", and known as "K&R C".  Many of the C compilers of that time 
followed the book and implemented - modulo bugs, extensions, 
inconsistencies, and missing features - the language "K&R C".  Many also 
had their own variants, as "C" was already popular before the book was 
published.


So - if you are referring to "K&R C", then use that term.  It is quite 
well defined, and accurately describes a popular pre-standard C language.

And you may note that if you look at the GCC manual, it supports all 
standards of C (at least as closely as possible).  All /standards/. 
"K&R C" is not a standard, and not officially supported by GCC - there 
has never, to my knowledge, been any kind of guarantee that GCC would 
support pre-standard syntax.  There has only been a guarantee that 
appropriate choices of flags would cause pre-standard syntax to be 
detected and rejected or diagnosed.  Ironically, the discussion here, 
with its suggestions of explicit flags to allow "K&R C" constructs, has 
come closer to guaranteeing support for that pre-standard dialect than 
GCC has ever had before.

<https://gcc.gnu.org/onlinedocs/gcc/Standards.html>
<https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html>




(When people refer to "ANSI C", they almost invariably mean the ANSI 
standard from 1989 that formed, after a bit of section renumbering, ISO 
C90, it is worth remembering that ANSI actually delegates the C 
standardisation to ISO.  So "ANSI C" refers to the same language as 
C17/C18.)