From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 6D6FD3858D35 for ; Sun, 14 May 2023 10:21:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6D6FD3858D35 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-x630.google.com with SMTP id a640c23a62f3a-966287b0f72so1720218966b.0 for ; Sun, 14 May 2023 03:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684059694; x=1686651694; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BfsV76De5IJa6vkgXVm4lAc7MYUV7V6Eliq0alpXDJ0=; b=plZxLDVik/yhu+lV0omhq7n/irfhxBg8KdLORryIUL7SEn5UykHOLBeCEq6XLE/Sv4 W5j29uUT4ssyFbbPP2ip5DD6TtPUTeFs/zxEYsVDQY5Pw4RWfy66Fts1vz/oAQs0853+ ZhQT/zDHOotBJmRv0WunOwh4B2CSJcmDTbTsEgASaW3DhlFlqpXhwmd74kPIelUzXpsv BYS+3t7F7j1iFAfa2GZ7WVC8pmbCN1Bac+fhy0Ve7hQHGSP1E9yMtNpW7SFwLNjxozi7 dw6jpUdU3u/LNWapAOzXyDfXRaQjA9Kp/SRO66lLdqDSFtnB9zSk2br2QQSURCVKuCpD I72g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684059694; x=1686651694; 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=BfsV76De5IJa6vkgXVm4lAc7MYUV7V6Eliq0alpXDJ0=; b=Ofr3Sywg+afjZE+G5tcUMqKaMYyqEev5pmnQoB4kiPdQPC4dQBKxjBD9gKy4scQWdX gl1CHHvbDOFLEfKnLRP4DDDUtG/wDkCWSa9xHyOOb+F6sJ4a4ZPEHVqqSAokMV0KMCfu H0kGLpiDnCaRiwdL6qnjcIFx7b26UTeoxooTKKIDMGGp/4ftvYOEYiJmRyAxasdO5N3p ehaUNLmrdhBK05xswrEzVqqnJ5KIYiZrpNgxAdJddtJzNr67VANpw7LT6hAAMRWGdZO8 vx5rxQMBDRmdQpeaRi0PKAMs0+dNc8OXBBEYRuV6npnTScJiTibn5A0A7OaRnpyYIbE1 vcMg== X-Gm-Message-State: AC+VfDxM9yKsY7R/eiBIv2HYzTDLkIgSsNxeMXOMMlP5LbyiJguwFm6a lCFvQxX8jeMZRyImN0h9LYW3xYHSbUm8TMLsMpA/i9X+ X-Google-Smtp-Source: ACHHUZ4RBrSH+vvcZF6iju+aabJkXXmsKphqEFEEr2AYEK4hij+ARa+j9IJFm7f0G6adrSXqDtzeF6y5iRVn8oL9Rc0= X-Received: by 2002:a17:907:8a04:b0:95f:de3c:6c98 with SMTP id sc4-20020a1709078a0400b0095fde3c6c98mr28710855ejc.58.1684059693828; Sun, 14 May 2023 03:21:33 -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:21:21 +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="000000000000d4d09605fba4b35a" 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: --000000000000d4d09605fba4b35a Content-Type: text/plain; charset="UTF-8" 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 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.) > > > --000000000000d4d09605fba4b35a--