From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NOR01-SV0-obe.outbound.protection.outlook.com (mail-sv0nor01on2046.outbound.protection.outlook.com [40.107.225.46]) by sourceware.org (Postfix) with ESMTPS id 083D63858CDA for ; Wed, 11 Oct 2023 11:28:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 083D63858CDA Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=westcontrol.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=westcontrol.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V1U0fzsSdD7wMaiiZI84cYeMDxBQjT2hXsPVa5qwMXSdGdQ/rArXLo9umB5k5n5h0VgaOuGto8r4U0F+UaDxQWRFbbsI9hbrZarSpX1qG9c5rV2M7ESEmjOvDCCDHufTzi0UPz8EdvHz9u3ey3JoU91lBGWqLe7wOLOFeruosIK426q4neADKLwWYi50fVXcjWL0eRQ/fKZ81EOWcUA/PWaqKnw4QI0y3R2lljSrSld+lp3DH7KVQUyBAqKcdOibOupcXwRnVW8P0MOM5VBbg3Yi10EawjqUiTWzi69DKxOYQcTFlg9xcJSx6CJ8cBk8cfQ5Jp9mY7MJyXLilmhQqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FvuAtGQnX1ny9xQQvpovEPyx/j+Cib8XyU0kOjQbKUQ=; b=W0aj8rl9sw1SI6kiZW3YXU5lCce4/c3I6gI1Iqc0rETobAYntgVNe8RbG2xa5c26aylyY3MWab3JJDbmWrbXURC8felM59fmISqTy8a6xVjK1EvlEa+bD/cWb7HrziTSu3vwh7EZhg9xD2S48M61TxoxKCQs/U9qmJs5mdgjVl20R3gyakS3WfdaMVYcbbDMnkboSjhT1MzUFvQPjm8XxZ7FTUZ419Q5boZLlRGnlOr/LFnHlntRPrxpUVa62orpJFt5ELXSMbsk9kBlqMAycKB/gIygomo809OxAA4xAjNpwameoSGu47Cevx+915HV3NhXXOnsO82ZQyElcqzlKw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=westcontrol.com; dmarc=pass action=none header.from=westcontrol.com; dkim=pass header.d=westcontrol.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=westcontrol.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FvuAtGQnX1ny9xQQvpovEPyx/j+Cib8XyU0kOjQbKUQ=; b=cQx2mpK2whoxC+a7LTrN3bB1G2+y5Lg4Io+4ZprHbVa8HSjS7qha3Nm/ageGl92ECEw7EETuax4Bw+XsWByhePG4Lz/43qNwQte+JaC13QhzE95AYAl5CQyLl92JXostNPMVRwrH0JVLYfjP/LzsDgAtzLTgrUzFn1nOSMwWd+b0sE3MUlalV8glmUHsq6m07D0rOtjwFkXMGdaso1TOu5zatypdcuPcfrSVbujym6AXzKxLbLA/KMTvpYA63j58hBb5U5fKwO7ensOLN0ldcNegfWnbPp8KyufyzbHxR3E6NV9wvCGsoguROwvoD4EM5AGe3VD3VHYpAH1itvyFSw== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=westcontrol.com; Received: from SV0P279MB0233.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:b::13) by OL1P279MB0244.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6863.43; Wed, 11 Oct 2023 11:28:14 +0000 Received: from SV0P279MB0233.NORP279.PROD.OUTLOOK.COM ([fe80::1e40:a4aa:a2b2:3c70]) by SV0P279MB0233.NORP279.PROD.OUTLOOK.COM ([fe80::1e40:a4aa:a2b2:3c70%4]) with mapi id 15.20.6863.032; Wed, 11 Oct 2023 11:28:14 +0000 Message-ID: Date: Wed, 11 Oct 2023 13:28:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: C89 question: Do we need to accept -Wint-conversion warnings Content-Language: en-GB To: Florian Weimer Cc: Jason Merrill , gcc@gcc.gnu.org References: <87h6myaf6b.fsf@oldenburg.str.redhat.com> <75b14d17-896c-db03-fad1-1931f39533e6@westcontrol.com> <8734yhy3yq.fsf@oldenburg.str.redhat.com> <87lec9wji7.fsf@oldenburg.str.redhat.com> From: David Brown In-Reply-To: <87lec9wji7.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SV0P279CA0045.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:13::14) To SV0P279MB0233.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:b::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SV0P279MB0233:EE_|OL1P279MB0244:EE_ X-MS-Office365-Filtering-Correlation-Id: 716de4de-9ece-4179-41e2-08dbca4d288c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +8LGd3GPcIH5kQU24Os/GmJef2OaH+GdDNb0PpohI/cta2OixLF/NIbFLyUzdO4l5motSxD25OkuwCLlRZp2x0b/zZfFY+rWp4+hlr/xB2RsS26uOMGdkjCZrJPtNNx1br5N0Dk+bk7KMa16QjudLVZCEGVLYDFOOlcXXxw45uvJveWarn04hTtN54+YF+1OTHKprVAaOojhbduffUYmheIH3DMx1wARmpMcHfvXxtVbJuHJMIrUBbnIu+n71/zRZ3aHgxvOm5FsygRxsGX9uQkvOZPtRyBxzJKizVS+JVhodJ9Moma+WH5HFGMxg1cemLfwdOouAz0iZm5HQ1dcffeNRxUA4DG7+yCf/SLv3FrDXEJ5Ojw8PTX1AUbaoGNJnfSVP9mFHUNEFdnlyylhnmxXLmhjGelUmLQGpHD3/Q7d+3gI5aKXNHw7pN9arnVJrtBANo3R4YV/7sqjpLfAmkx3l2N2vgF3/Wcn2gbXPDxG8ij0UqnwgfxOyQPyenw1eWCRMXmr4FRygGBCnY5stPTUoiCUgVP/0nIqK/tNlmR1C2iTTUReKC2rErnBZ1FFSdDV/jtVDWnyX3Zlv40QliX3pwza5Y6TvJbYc4MlY6E5hqZkCUSjR4ZTCE+0BYXJBrzaKFsn21w7lv5zPZKv3w== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SV0P279MB0233.NORP279.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230031)(366004)(136003)(346002)(39840400004)(396003)(376002)(230922051799003)(451199024)(186009)(1800799009)(64100799003)(66899024)(478600001)(6486002)(2616005)(36756003)(26005)(53546011)(6512007)(38100700002)(86362001)(31696002)(83380400001)(6506007)(2906002)(66476007)(66556008)(66946007)(41300700001)(8676002)(8936002)(4326008)(31686004)(316002)(6916009)(5660300002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SUtDRlBUYmY4dEt3bFQ2UFNwVldtcC9HdXk4UEhENEF0TUtZRzluNzNlV242?= =?utf-8?B?S3lFTTdoWVZvTmdrZzNJZE5FMlRieFplditPcWtGeEROVkYwVzl2bWUxYXJV?= =?utf-8?B?SzJ3NThrZzBIYnZtU2hoL0p0UmQ4M010OHh5ZEt1K1l4REJhamk1K09HbXpH?= =?utf-8?B?RG1mMEgvNnhXd1pRYVg1SjdVSUlEeENZWm9pSjJtOENiNUlSUEtIdWlBTlY3?= =?utf-8?B?WE02SFFsTDMxY3BnTWVSdEcyZUxXUnNvU1NZVE9KbXU0ZUZvRG1SV3JsWjh2?= =?utf-8?B?U2k2SmpoU1l2TXRUY2VqVkQ2WGxMaXdQckdoa09tS1Q4ekFlbHY3L3NXSEZ5?= =?utf-8?B?TVZMTHhlUWI0TkQyN2NzeXk2ZHFraW93Zi9sVHVoQkI2UXNacFR4YTNQY3NO?= =?utf-8?B?OTFiN21xNEpsRncrMklyMTdpSEN6ZGdnTWw3RGE5UjRrQVVMM0tmbDNlTDBU?= =?utf-8?B?bzJWYk9ndzROL2RaVFFpUnViN3QwS1VJYmdlb2tEOHpsYVYvNHQzVW44YjJN?= =?utf-8?B?STduWW5RN0wvSVpjdVlVMmVyK1hUSnM4VHp2cHVVUmx4eVl2SW1tWUFRRTdm?= =?utf-8?B?em94alVqTHZOU1ZHT2RJUzZKVUQ1T0pXSXJpUmV1a0NSS3V5UlBKNFIzbUYw?= =?utf-8?B?aUJ1RUVoMHhxSDZ4SGwvQ0NhS0Z6SUhFeklBNTREUUwwYjkrbnNpNHpVSnBs?= =?utf-8?B?djhPV0pqRXhMdVFOblMxVEw4VGtnM1RTZEVrdUJyRzlocStZa0hRQzVCM2VV?= =?utf-8?B?cVN0SEZoV2NlQ012ajNFNHpadnkzM01tTDVWUUUzOVVsWWtYQXV3MHRFVmE4?= =?utf-8?B?VWlpc2JTMENSeTVOWHkxMFRtR2JiL1drWVFDNkR3Zmpmam41cDlQRTBLYW1T?= =?utf-8?B?OU5JR211R2IvMUdZaWRaUnJ4L1BvSVd6bVNyL0RpazN0blVhcjNrbHZnL2p6?= =?utf-8?B?WXFjakFFU3lTSTlURUg3M0t4bDhxeEROVERnSTQwdExGbmlncVR3djFXanNl?= =?utf-8?B?Tlh4aTg1RzhFTGFwZ2dOUE1UTjFYOXlHZlhOeU1TZC9zT1NMeHp2MFkxdXVL?= =?utf-8?B?d3ZWNldGN0txbDRSRkQxTGIzMVJEdnBwM1ZER3ZVRUdTcmE3bkQ0UGhJT3pp?= =?utf-8?B?dXk0dnBtSDNRU0czSFJZeHdpU3Zxa1puUDlId2NtRWlIbndLU3ZjR0tWc3Vr?= =?utf-8?B?cDV2bTJaN3ZhVFRBTnJJYm9kSDJYMDlrUzZaVG5YUW5ib1ZEK0IvUFJxellk?= =?utf-8?B?amRpVUdFUmJhYkl0MHFoUWtabWRnVndPd0FKRGxSQUxSd0p6L2QvTUhIaVBx?= =?utf-8?B?ZncxUWFXdXRyWHhPbnI5OHh4a2xqKzlBZHVmK1pUL3BaTUJDNXdRTldBQlFr?= =?utf-8?B?RWp0QVZnU1BtcDAyUnVpN0J1RVNLRTE1S3RPNmRjb2xZTERLcXh1R1pMRko3?= =?utf-8?B?RFd2d1paNnFnemlpMlNHUUNSalFkVjFyMk9mK0R1R3ZNekw0bmo2Uzc3WklO?= =?utf-8?B?UzZTZ0dtK0wvSDY1WE9hZEd4NEI1SHB2MjVqb3VqWnl4OGlVQ0wzanRiSERJ?= =?utf-8?B?TTJlSG16ZDBkK2o4M3pqakJNall2SEEvTHZVZEVvRkl6Rk9ZTzgzdEg3VGhG?= =?utf-8?B?SnJNd2J4VnNpV3o1NnZVdWI1TmRzYXA3TjRJY0w0eVhHWlJrV05VbURrSkpo?= =?utf-8?B?K0kyUkdEYXpmNUJySnBXN1ptOFErbFVIbnZCbGJ5YkRUTVBPUlYvZmJzUFJm?= =?utf-8?B?Wi9tb0h1K2RPNFV3U1RXTm9NRkhmUVNDbDU5OFFiM08rRFlUMzhuVzkzbVIw?= =?utf-8?B?TXhvOWpmUFg5eGx3UFZpUS8zcG0zSVdZZCtyS1c0eVJJZG5YMzd4Tnd5NDFX?= =?utf-8?B?d1RBbUlmbjYzMjI4SGJJcmlzUTAvdWZPTHJ0SkZKSnhSWGFObDg5KzNzUlFq?= =?utf-8?B?eUovZkpiSHEwZ1BqZEJyWllCbFVjYVk4ZHVrNXE0VUUyU0kzS2s4RGJFdm1K?= =?utf-8?B?ZmJ5YUdTd0ZXZFIyQTJYdW1GbGd0eDE2NmQ3RjBxTTljaE5EYkR3bG9ycDlN?= =?utf-8?B?VDE2MHk5eEQ5Y25ZOGtZWG02aERDZ2EyZUs3SFdGT2d3aFM1K3ZqdWFSSzlu?= =?utf-8?Q?XDJOWicNMXl4DGyqxJOdzICZK?= X-OriginatorOrg: westcontrol.com X-MS-Exchange-CrossTenant-Network-Message-Id: 716de4de-9ece-4179-41e2-08dbca4d288c X-MS-Exchange-CrossTenant-AuthSource: SV0P279MB0233.NORP279.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2023 11:28:14.6215 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c75fbd3c-42ad-4db0-9cff-972faf83ae45 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: yeRto8wGDY9+a1ze+NA6uGPj2/MbAm/ohJ0dy264p6hkIGcBP4AcfgBV1ehNbzk6BM9bHOrNGR4j5VCvfO2LiQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OL1P279MB0244 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/10/2023 12:17, Florian Weimer wrote: > * David Brown: > >> On 11/10/2023 10:10, Florian Weimer wrote: >>> * David Brown: >>> >>>> So IMHO (and as I am not a code contributor to GCC, my opinion really >>>> is humble) it is better to be stricter than permissive, even in old >>>> standards. It is particularly important for "-std=c89", while >>>> "-std=gnu89" is naturally more permissive. (I have seen more than >>>> enough terrible code in embedded programs - I don't want to make it >>>> easier for them to write even worse code!) >>> We can probably make (say) -std=gnu89 -fno-permissive work, in a way >>> that is a bit less picky than -std=gnu89 -pedantic-errors today. >>> >> >> The gcc manual has "-permissive" under "C++ Dialect Options". Are you >> planning to have it for C as well? > > Yes, I've got local patches on top of Jason's permerror enhancement: > > [PATCH v2 RFA] diagnostic: add permerror variants with opt > > > >> That sounds like a good idea (perhaps with some examples in the >> documentation?). Ideally (and I realise I like stricter checking than >> many people) some long-obsolescent features like non-prototype >> function declarations could be marked as errors unless "-permissive" >> were used, even in C89 standards. > > For some of such declarations, this falls out of the implicit-int > removal. Yes. > > C23 changes meaning of of extern foo(); to match the C++ interpretation > of extern foo(void);. I don't think we should warn about that. If we > warn, it would be at the call site. I'm not sure I fully agree. "extern foo();" became invalid when implicit int was removed in C99. But "extern T foo();", where "T" is void or any type, has changed meaning between C17 (and before) and C23. With C23, it means the same as "extern T foo(void);", like in C++ (and like all C standards if it is part of the definition of the function). However, prior to C23, a declaration of "T foo();" that is not part of the definition of the function declares the function and "specifies that no information about the number or types of the parameters is supplied". This use was obsolescent from C90. To my mind, this is very different. I think it is fair to suppose that for many cases of pre-C23 declarations with empty parentheses, the programmer probably meant "(void)". But the language standards have changed the meaning of the declaration. IMHO I think calling "foo" with parameters should definitely be a warning, enabled by default, for at least -std=c99 onwards - it is almost certainly a mistake. (Those few people that use it as a feature can ignore or disable the warning.) I would also put warnings on the declaration itself at -Wall, or at least -Wextra (i.e., "-Wstrict-prototypes"). I think that things that change between standards, even subtly, should be highlighted. Remember, this concerns a syntax that was marked obsolescent some 35 years ago, because the alternative (prototypes) was considered "superior to the old style on every count". It could be reasonable to consider "extern T foo();" as valid in "-std=gnu99" and other "gnu" standards - GCC has an established history of "back-porting" useful features of newer standards to older settings. But at least for "-std=std99" and other "standard" standards, I think it is best to warn about the likely code error. > >> (As a side note, I wonder if "-fwrapv" and "-fno-strict-aliasing" >> should be listed under "C Dialect Options", as they give specific >> semantics to normally undefined behaviour.) > > They are code generation options, too. I see them as semantic extensions to the language, and code generation differences are a direct result of that (even if they historically arose as code generation options and optimisation flags respectively). Perhaps they could be mentioned or linked to in the C dialect options page? Maybe it would be clearer to have new specific flags for the dialect options, which are implemented by activating these flags? Perhaps that would be confusing. > >>> And of course there's still -Werror, that's not going to go away. So if >>> you are using -Werror=implicit-function-declaration today (as you >>> probably should 8-), nothing changes for you in GCC 14. >> >> I have long lists of explicit warnings and flags in my makefiles, so I >> am not concerned for my own projects. But I always worry about the >> less vigilant users - the ones who don't know the details of the >> language or the features of the compiler, and don't bother finding >> out. I don't want default settings to be less strict for them, as it >> means higher risks of bugs escaping out to released code. > > We have a tension regarding support for legacy software, and ongoing > development. Agreed, and I fully understand that there is no easy answer here. On the one hand, you don't want to break existing code bases or build setups, and on the other hand you want to help developers write good code (and avoid bad code) going forwards. > I think we should draw the line at C99. That's the first > language standard that removes most of these obsolescent features, after > all. > C99 removed implicit int and implicit function declarations (though these are still merely warnings by default in GCC!). Non-prototype function declarations were not removed until C23, and some things (minor issues, to be fair) have been explicitly marked obsolescent from C89 up to and including C23 ! Still, I fully agree with the principle of being stricter for later standards versions than older standards versions. Having had to maintain code where a function's definition, declarations and uses varied wildly in parameter types and count throughout a program, I am favour of anything that makes it harder for people to write such nonsense and claim "it compiles, let's ship it!". I appreciate your taking the time to read and consider my opinions, whether you implement any of them or not. And - as always - thank you all for your work on GCC. David