From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id CD8E4385840F for ; Fri, 12 May 2023 21:20:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CD8E4385840F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org 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> <871qjlh9t3.fsf@mid.deneb.enyo.de> <87v8gxe08l.fsf@mid.deneb.enyo.de> User-agent: mu4e 1.10.3; emacs 29.0.90 From: Sam James To: Florian Weimer Cc: Jason Merrill , Joseph Myers , Eli Zaretskii , Jakub Jelinek , gabravier@gmail.com, jwakely.gcc@gmail.com, fweimer@redhat.com, arsen@aarsen.me, gcc@gcc.gnu.org Subject: Re: More C type errors by default for GCC 14 Date: Fri, 12 May 2023 22:20:12 +0100 In-reply-to: <87v8gxe08l.fsf@mid.deneb.enyo.de> Message-ID: <874joh5jru.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_NUMSUBJECT,KAM_SHORT,SPF_HELO_PASS,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: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Florian Weimer writes: > * Jason Merrill: > >> On Fri, May 12, 2023 at 11:03=E2=80=AFAM Florian Weimer wrote: >>> >>> * 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 h= as >>> >> 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 >>> > C89 (and is invalid for versions in between). In this case, there is= an >>> > incompatible semantic change between implicit int and C++-style auto. >>> > Giving an error before we make -std=3Dgnu2x the default seems like a >>> > particularly good idea, to further alert anyone who has been ignoring= the >>> > warnings about implicit int that semantics will change incompatibly. >>> >>> Obviously makes sense to me. >> >> Agreed. But we could safely continue to accept >> >> static x =3D 42; >> >> or even >> >> auto x =3D 42; // meaning of 'auto' changes, meaning of the declaratio= n does not >> >> We might make -Wimplicit-int an error by default only if the >> initializer has a type other than 'int'. > > Based on what I saw fixing Fedora, these cases are not very common. > Sure, sometimes common program such as valgrind have an instance > , but that's really an > exception. > > Implicit int is common as the return type of main (especially in > autoconf tests), and due to a missing declaration list entry of an > old-style function definition. The main case could be treated as an > exception. The old-style function definition case is a common source > of bugs and therefore worth fixing. The addition of unnamed function > parameters as an extension actually created a new class of bugs here > (a typo in the type name of a single unnamed parameter results in an > old-style function definition by accident). > >>> > In cases where the standard requires a diagnostic, some are errors, s= ome >>> > are pedwarns-by-default or unconditional pedwarns, some are >>> > pedwarns-if-pedantic - the choice depending on how suspicious the >>> > construct in question is and whether it corresponds to a meaningful >>> > extension (this is not making an automatic choice for every such situ= ation >>> > in the standard, it's a case-by-case judgement by maintainers). By n= ow, >>> > the cases discussed in this thread are sufficiently suspicious - >>> > sufficiently likely to result in unintended execution at runtime (not= , of >>> > course, reliably detected because programs with such dodgy code are v= ery >>> > unlikely to have thorough automated tests covering all their code) - = that >>> > is it in the interests of users for them to be errors by default (for= C99 >>> > 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. >> >> What would the impact be of making -Wint-conversion an error by >> default only if the types are different sizes? > > From a distribution perspective, it does not change anything because > we build everything on 64-bit anyway. Unlike e.g. Fedora, Debian > doesn't require all builds to succeed before the new package can be > installed, but given that the primary targets are 64 bit, I don't > think a restricted -Wint-conversion error would be much of a > simplification. The target-dependent nature of the warning is > probably more confusing. I don't see us really gaining anything from restricting it. Like you said, the cases in the wild are actually all of the same "class". --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZF6tpV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZAJ0wD+Nl2fD+ggmnvzACNT5HNssRZVJMI76OsvGf+1 bKkuHOsA/09Zsm6B/tSAU54UmMrzl7JicjfIkwpleueGP113pF0H =8bUH -----END PGP SIGNATURE----- --=-=-=--