Re: More C type errors by default for GCC 14

[Jonathan Wakely <jwakely.gcc@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3298 bytes --]

On Sun, 14 May 2023, 11:21 Jonathan Wakely, <jwakely.gcc@gmail.com> wrote:

>
>
> On Sun, 14 May 2023, 10:47 David Brown, <david.brown@hesbynett.no> wrote:
>
>> 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 used to be the -traditional option which was deprecated in gcc 3.1
> and removed in gcc 3.3
>
> https://gcc.gnu.org/gcc-3.1/changes.html
> https://gcc.gnu.org/gcc-3.3/changes.html
>

But even as far back as gcc 2.95.3 that was documented only to "attempt" to
support "some" features of pre -standard C:

"Attempt to support some aspects of traditional C compilers."



>
> 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.)
>>
>>
>>