From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 7B6CC3858D35 for ; Sun, 14 May 2023 10:23:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7B6CC3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-965ab8ed1fcso2153000066b.2 for ; Sun, 14 May 2023 03:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684059828; x=1686651828; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JJQR3auP1bqJWWdBNkjbqVjmHKhoIsi3+F95oePZQ+4=; b=KZMemu4XR4cuEYNTdZ5vrrONt7xPMUfI3C/KFXLczHm/MYuOLRBhonhYQj/kyyBAnw 8kXfc0UzfuLnMmrOgv4S405GyjRVxJNixdBxmzEvu7Hlm4pnClHWhA+dUfj8O5xYHChY i005a0FrphGe/kq53KEPz17xlGdNs5yhfFw10stvZAppfZO/ud9w46T+7JIQo6y2zux6 8j0TXPKHIWuU+iv/HAqFRu3lAQSQ6E3wcrCulNxIbKF1CVtPIcsmoysku4wzF83qI4cF +tH+BZWPJfaaUGQENGfKo80f1mPtytXdZjfnf426tTmFDvKTZOIUQih1FqhuJQ92U9We 0Bgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684059828; x=1686651828; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JJQR3auP1bqJWWdBNkjbqVjmHKhoIsi3+F95oePZQ+4=; b=d898JHJvFOWkHftgClMzxXM9CF8D2AO9s2ucdvhRrQQffEFnsp0azt3tc5G7oR0LCi 7UZzaHUtMBHW/RNz6Q+kUhdiIO+LLfkRr4LkG9kz+hv8pEsdErB6L1B4AGvO6KXQHmvn zrZ+s+s5NJkESV97uoo51fFbpBE1IH9yRnwONuK1x8XvIioyKZh1cZ2YeUEmtoMHWNoL HihsDggBuFkxGzgsrQO6GWvekG/L+ME5i2lQBCjQrRtzAKOXLroLJ59rSP+ceh0Vtv/A zPcJ6mDYMvg7/wwYPP/L0UHgPvJxYsvIkqzBQW0XfpxCajM3TZXELYzEkcFE2VCJk/Ui ILEQ== X-Gm-Message-State: AC+VfDxSBXyZ5+dK5cYR+T+91DKmY9TuvQiyV8UHORRRTZBmZ6jhyzN2 uelcJ1Iv9MeKffKDpGODS2I2dta6iQmCRKOPI/I= X-Google-Smtp-Source: ACHHUZ5e27XPu+5jpMZsXwW21/L2/7US6ojx4MwL+7qDkwBqrKctVgzLuGrkZwVQT0RiTaCsfUKQO5jKxl3XTeusRmE= X-Received: by 2002:a17:907:8a14:b0:8ae:11ca:81de with SMTP id sc20-20020a1709078a1400b008ae11ca81demr25077640ejc.34.1684059828091; Sun, 14 May 2023 03:23:48 -0700 (PDT) MIME-Version: 1.0 References: <87mt2behdl.fsf@yahoo.com> <57238276-5966-98d6-d5f0-f5451013ed17@gmail.com> <871qjned25.fsf@yahoo.com> <67e65b41-5400-d1c2-9f43-f94d0ea7da9b@gmail.com> <87wn1fcrw4.fsf@yahoo.com> <4d2af697-2f28-9e17-6b35-3a4ba19313d2@gmail.com> <87mt2ab8te.fsf@yahoo.com> <83bkiq3umf.fsf@gnu.org> <87sfc18z66.fsf@yahoo.com> <1cb56b16-1ee0-e233-30f2-464c30d19fd4@gmail.com> <87y1lt6ouy.fsf@yahoo.com> <95ae59d6-097b-ebc2-06c5-b74a0544a2cc@netcologne.de> <87mt287p64.fsf@yahoo.com> <80defba2-5e0e-7e67-9d17-94e676716dd1@gmail.com> <87y1lr5v6r.fsf@yahoo.com> In-Reply-To: From: Jonathan Wakely Date: Sun, 14 May 2023 11:23:36 +0100 Message-ID: Subject: Re: More C type errors by default for GCC 14 To: David Brown Cc: "gcc@gcc.gnu.org" Content-Type: multipart/alternative; boundary="000000000000d57d7005fba4bb07" X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000d57d7005fba4bb07 Content-Type: text/plain; charset="UTF-8" On Sun, 14 May 2023, 11:21 Jonathan Wakely, wrote: > > > On Sun, 14 May 2023, 10:47 David Brown, 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. >> >> >> >> >> >> >> >> (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.) >> >> >> --000000000000d57d7005fba4bb07--