From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id B7D3C3858C54 for ; Fri, 12 May 2023 15:03:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B7D3C3858C54 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de Received: from [172.17.203.2] (port=47247 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1pxUIC-001oGs-RS; Fri, 12 May 2023 15:02:48 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.96) (envelope-from ) id 1pxUIC-000BjJ-2M; Fri, 12 May 2023 17:02:48 +0200 From: Florian Weimer To: Joseph Myers Cc: Eli Zaretskii , Jakub Jelinek , , , , , Subject: Re: More C type errors by default for GCC 14 References: <87y1lx1avj.fsf@oldenburg.str.redhat.com> <83ednoapb6.fsf@gnu.org> <831qjoa0g0.fsf@gnu.org> <83o7ms8is7.fsf@gnu.org> <2ffbf210-1b58-737b-888c-4f84c5cc5e0f@gmail.com> <837ctg8e98.fsf@gnu.org> <83wn1g6w67.fsf@gnu.org> <83mt2c6tch.fsf@gnu.org> Date: Fri, 12 May 2023 17:02:48 +0200 In-Reply-To: (Joseph Myers's message of "Wed, 10 May 2023 17:08:18 +0000") Message-ID: <871qjlh9t3.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_NUMSUBJECT,KAM_SHORT,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: * Joseph Myers: > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote: > >> That is not the case we are discussing, AFAIU. Or at least no one has >> yet explained why accepting those old K&R programs will adversely >> affect the ability of GCC to compile C2x programs. > > At block scope, > > auto x =3D 1.5; > > declares x to have type double in C2x (C++-style auto), but type int in=20 > C89 (and is invalid for versions in between). In this case, there is an= =20 > incompatible semantic change between implicit int and C++-style auto.=20= =20 > Giving an error before we make -std=3Dgnu2x the default seems like a=20 > particularly good idea, to further alert anyone who has been ignoring the= =20 > warnings about implicit int that semantics will change incompatibly. Obviously makes sense to me. > In cases where the standard requires a diagnostic, some are errors, some= =20 > are pedwarns-by-default or unconditional pedwarns, some are=20 > pedwarns-if-pedantic - the choice depending on how suspicious the=20 > construct in question is and whether it corresponds to a meaningful=20 > extension (this is not making an automatic choice for every such situatio= n=20 > in the standard, it's a case-by-case judgement by maintainers). By now,= =20 > the cases discussed in this thread are sufficiently suspicious -=20 > sufficiently likely to result in unintended execution at runtime (not, of= =20 > course, reliably detected because programs with such dodgy code are very= =20 > unlikely to have thorough automated tests covering all their code) - that= =20 > is it in the interests of users for them to be errors by default (for C99= =20 > and later modes, in the cases that were valid in C89). Just to recap, those are controlled by -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and -Wincompatible-pointer-types, roughly in increasing order of compatibility impact with old sources. > It might also make sense to review other pedwarns-by-default and=20 > unconditional pedwarns to consider if any of those should be errors by=20 > default, though I suspect most of those are less significant. I went through the pedwarn calls in the C front end. First, these two appear to be genuine bugs: Incompatible pointer types in ?: not covered by -Wincompatible-pointer-ty= pes Pointer/integer mismatch in ?: not covered by -Wint-conversion location, OPT_Wpedantic, "obsolete use of designated initializer without %<=3D%>"); Unclear whether we still need to support that, but also harmless, I guess.) This one seems to be hack to support obsolete wait function usage. We probably don't need it any more because the union wait was removed from glibc 2.24, and the function prototypes in glibc are now more standard. The union wait type was deprecated in the early 90s. /* Given wait (union {union wait *u; int *i} *) and wait (union wait *), prefer union wait * as type of parm. */ pedwarn (input_location, OPT_Wpedantic, "function types not truly compatible in ISO C") And furher below in c-typeck.cc: /* Allow wait (union {union wait *u; int *i} *) and wait (union wait *) to be compatible. */ I think it should be safe to error for these by default. I couldn't figure out what these warnings are about: pedwarn (input_location, OPT_Wpedantic, "function types not truly compatible in ISO C"); pedwarn (location, OPT_Wpedantic, "types are not quite compatible"); This seems to be mainly for &*p if p is of type void *: warning_at (loc, 0, "dereferencing % pointer"); pedwarn (location, 0, "taking address of expression of type %"); Rather hideous, but maybe harmless in the grand scheme of things? One rather large set of pedwarns concerns qualifier mismatches. I believe this is about technically undefined behavior, so maybe the warning is not about things that are entirely harmless. Implicitly dropping const-ness from pointers could cause crashes at a later stage, so more rigorous errors could point at the location of the actual mistake. On the other hand, C programs aiming for full const-correctness are quite rare. Adding all those casts for things like volatile int x[4]; memset (x, 0, sizeof (x)); would be quite cumbersome, too. So I'm not sure what to do about these. Then there is -Wpointer-sign. The Linux kernel really dislikes that warning, so we would want a mechanism to control that separately. Again not sure what to do about those. This sone seems to be a good candidate for additional errors, though: warned_here =3D pedwarn (loc, warn_return_type >=3D 0 ? OPT_Wreturn_type : 0, "% with no value, in function returning non-void"); It's a clear type volation that can lead to obscure bugs. Maybe the converse as well. In summary, all these seems to be good candidates for errors by default: * int-conversion as errors (already raised separately * -Wint-conversion for ?: * parameter names in non-prototype function declarations * the union wait function pointer compatibility kludge * return-with-out-value for non-void functions * -Wincomatible-pointer-types warning for ?: (but no error yet, see below) This are more =E2=80=9Cmaybe=E2=80=9C: * incompatible-pointer-types as errors (already raised separately) * int-conversion and incompatible-pointer-types in comparisons * return with value in a function returning void * dereferencing void * * taking the address of void * "function types not truly compatible in ISO C" and "types are not quite compatible" (depending on what they actually mea= n) * qualifier mismatches (may need separate opt-out) * sign mismatches in pointers (definitely needs separate opt-out) I can do experiments on the Fedora code base in the coming weeks for at least a subset of those. The second list likely has a few with quite high cost for us. I suspect even incompatible-pointer-types is problematic in that regard. The first list seems more manageable, although int-conversion is also a fairly big work item (and I need to find a way to cut down the number of false positives from the tester).