From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 58C993856968 for ; Fri, 12 May 2023 15:52:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 58C993856968 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683906727; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ehgxJ8CZHisBHMQ4wmGpuXvr1WqzWn8L7hih8+bEgoE=; b=fVYdOXwxA/XrNW4OpDtmO8WgeEqUaRSHIZf4R/iFbyXRpWfAoGhRDHWxciSZ7x+s5Fmcpv JnWTR5Jmw1PUwA/19MHTEx4j7fv93BTznfkTSdCE4bQZmO7zv0BUC2p4hs3Dis6Vqvq0mR snhDrlPspv8y+EzkPxmj5pWjgCW+M2M= Received: from mail-il1-f199.google.com (mail-il1-f199.google.com [209.85.166.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-633-CzZ5tWJfNcqzU0qwkejwKw-1; Fri, 12 May 2023 11:52:06 -0400 X-MC-Unique: CzZ5tWJfNcqzU0qwkejwKw-1 Received: by mail-il1-f199.google.com with SMTP id e9e14a558f8ab-331ab91abdeso139282615ab.0 for ; Fri, 12 May 2023 08:52:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683906726; x=1686498726; h=content-transfer-encoding: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=ehgxJ8CZHisBHMQ4wmGpuXvr1WqzWn8L7hih8+bEgoE=; b=HUljHt0plGDO+A8fKoXndP+sEXdjXoIyJya/EUje5qG6KDkLSrh+8WRQSYyPF+Cj8p he/YUvPcv+gIEThsTToA3N37J5IibX+n7WDinjFSteSRwiOnSHOU0G3jXHqhUHYZP48I zqAymOP2+7FTNj59qMUg/JzPpdtmjdAJY4K1zw2clDOW16UV/be21rlCK4QH/X+vpW+H ed/kr4qZ9ArGnyIaFEqqSps3GnyW1J7mZ2PKB+9Y/1amptkbu8pBh9unMlO3GpD3PJKO 8unUCo0lG9GWdVskriMhhIPDkb1GKGsC2ZxBYbNSmyyNXt/i1ReYndaCZRdykZlfQJH3 U7dA== X-Gm-Message-State: AC+VfDwMTOugtfvvhbiWAhHBJsKq+9SavPbM1PQY3gNzykpInJLNBD14 RCt23GLUMox5n/6n1/RJBlZKnarTazGqLcJiuMk/bXToTFwP0UQAMKwO10BN+prrFR+679yIUNs gUANDb/5MXM9G286VdHpYUDw= X-Received: by 2002:a92:4a06:0:b0:328:39a6:ed13 with SMTP id m6-20020a924a06000000b0032839a6ed13mr15066538ilf.4.1683906726137; Fri, 12 May 2023 08:52:06 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5GaCI9na3mBgbgUYhTQyPk6p8bBovYdjuCn0tRpA2dIHxnQuG0P3h8u3jOqFZAV7RjHogSVGqU3fJPLfAS6dM= X-Received: by 2002:a92:4a06:0:b0:328:39a6:ed13 with SMTP id m6-20020a924a06000000b0032839a6ed13mr15066534ilf.4.1683906725806; Fri, 12 May 2023 08:52:05 -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> In-Reply-To: <87sfc18z66.fsf@yahoo.com> From: Jason Merrill Date: Fri, 12 May 2023 11:51:54 -0400 Message-ID: Subject: Re: More C type errors by default for GCC 14 To: Florian Weimer Cc: "gcc@gcc.gnu.org" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-16.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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: On Fri, May 12, 2023 at 9:20=E2=80=AFAM Po Lu via Gcc wro= te: > Yes, just these quotes from a former GCC maintainer: > > In C, we cannot divide all user code into "right" and "wrong" in this > kind of simple way, and certainly not based on the ISO standard. That > standard is just the decisions of a certain committee (which I was a > member of) about what cases conforming compilers should commit to > support. We must not let ourselves start thinking that C code is > "wrong", just because it is not conforming ISO C code. > > C programs use many cases that are not conforming, but do work. This > will be true for as long as C is used, because changing it would > require major changes in the C language. > > From time to time, there is a real *need* to make some of these cases > stop working, for the sake of some benefit that users want. When this > happens, we should do it; the user community will accept it, because > they will see that it is being done for their sake. Some will > grumble, but the users who appreciate the benefits will convince them. > > But when there is no *need* to break these cases, when we can keep > them working fairly easily, we should keep them working. If we break > them unnecessarily, we invite the legitimate anger of the users. Absolutely. The debate is really over the degree of "need" and the degree of "break". The proposal argues that the need is to help developers using GCC avoid a common class of wrong-code bugs that have gotten worse with the rise of platforms with 64-bit pointers and 32-bit int, and even more with the adoption of position-independent executables as a security measure. The "break" is asking affected legacy code to adjust build flags, if they don't want to adjust their code. Note that some such legacy code does in fact need to be fixed to work properly on modern systems, e.g. https://developers.redhat.com/blog/2019/04/22/implicit-function-declaration= s-flexs-use-of-reallocarray Certainly there are people in both camps with valid perspectives, as Florian pointed out early in his initial email. Previously, we've leaned toward the second camp for these particular issues. But the problem above strengthens the case of the first camp. And the dwindling amount of affected code weakens the case of the second camp. And so the proposal suggests that we change the default behavior. As a compromise, it should be possible to error by default only in cases where the implicit int (including as a return value) is either the source or target of a non-value-preserving conversion, as those are very likely to be bugs. That seems desirable for both camps. A simpler change to catch this particular bug would be to make -Wint-conversion an error by default iff the sizes differ. (Incidentally, for the first camp, it seems desirable to have a flag to upgrade all currently enabled pedwarns to errors without also enabling pedwarns that depend on -pedantic/-Wpedantic; -pedantic-errors does both; -Werror=3Dpedantic makes only the latter set errors, which seems unlikely to be useful to anyone.) Jason