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