On Sun, 14 May 2023, 10:47 David Brown, <david.br...@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

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

Reply via email to