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 1144F3851C12 for ; Wed, 10 May 2023 12:03:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1144F3851C12 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=1683720189; h=from:from:reply-to: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=lZwGeW48Ch1iBJqdT51Zg2pt65pWkQysjk5ezNm6xxo=; b=CKOZ+fGdcCV/k/vaHsrNnGgPFiuqY7f8Te/GoS5jA2NV0jHiQj9cx9smQrB9nyiVAh1xHS 177Cjo5YAukEnu1kEsSygCLKDXUW17/MZwiO40NYJiTrgJQHyD7PbrgTRLjCBcD0DtuWwl HqFd7cHLs7dRUzLa4fg5wsZPtikuYW4= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-209-saMPsZE7PbO38PpaG0c3Pw-1; Wed, 10 May 2023 08:03:06 -0400 X-MC-Unique: saMPsZE7PbO38PpaG0c3Pw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id F35FD1C0D9EF; Wed, 10 May 2023 12:03:05 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.156]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B087A40C2077; Wed, 10 May 2023 12:03:05 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 34AC32EO3915011 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 10 May 2023 14:03:03 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 34AC31s13915010; Wed, 10 May 2023 14:03:01 +0200 Date: Wed, 10 May 2023 14:03:01 +0200 From: Jakub Jelinek To: Eli Zaretskii Cc: Jonathan Wakely , fweimer@redhat.com, gcc@gcc.gnu.org, arsen@aarsen.me Subject: Re: More C type errors by default for GCC 14 Message-ID: Reply-To: Jakub Jelinek References: <87r0rp5uf8.fsf@aarsen.me> <83ttwla1ep.fsf@gnu.org> <83lehx9vix.fsf@gnu.org> <83fs859unu.fsf@gnu.org> <87y1lx1avj.fsf@oldenburg.str.redhat.com> <83ednoapb6.fsf@gnu.org> <831qjoa0g0.fsf@gnu.org> MIME-Version: 1.0 In-Reply-To: <831qjoa0g0.fsf@gnu.org> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 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 Wed, May 10, 2023 at 02:30:07PM +0300, Eli Zaretskii wrote: > > From: Jonathan Wakely > > Date: Wed, 10 May 2023 09:04:12 +0100 > > Cc: Florian Weimer , "gcc@gcc.gnu.org" , > > Jakub Jelinek , Arsen Arsenović > > > > void foo(int); > > void bar() { foo("42"); } > > > > Why should this compile? > > Because GCC is capable of compiling it. That is not a good argument. GCC is capable of compiling any code in all the reported accepts-invalid bugs on which it doesn't ICE. That doesn't mean those bugs shouldn't be fixed. C99 for the above says: 6.5.2.2/7 "If the expression that denotes the called function has a type that does include a prototype, the arguments are implicitly converted, as if by assignment, to the types of the corresponding parameters, taking the type of each parameter to be the unqualified version of its declared type." and "One of the following shall hold: — the left operand has qualified or unqualified arithmetic type and the right has arithmetic type; — the left operand has a qualified or unqualified version of a structure or union type compatible with the type of the right; — both operands are pointers to qualified or unqualified versions of compatible types, and the type pointed to by the left has all the qualifiers of the type pointed to by the right; — one operand is a pointer to an object or incomplete type and the other is a pointer to a qualified or unqualified version of void, and the type pointed to by the left has all the qualifiers of the type pointed to by the right; — the left operand is a pointer and the right is a null pointer constant; or — the left operand has type _Bool and the right is a pointer." For the above case, none of that holds and it isn't something desirable to be supported as GNU extension, because while it could happen to work as the user wanted after cast back to pointer in foo on ilp32 architectures, it doesn't make any sense on lp64 or llp64 architectures. Note, this isn't valid even in C89 and is already rejected with -pedantic-errors for years. The proposal is essentially to stop accepting this as a GNU extension which was added for K&R compatibility I assume and do that only for C99 and later. > It compiles today with a warning, so that whoever is interested to fix > the code, can do that already. The issue at hand is not whether to > flag the code as highly suspicious, the issue at hand is whether > upgrade the warning to errors. So let's talk about the issue at hand, > not about something else, okay? We do such changes several times a year, where we reject something that has been previously accepted in older standards, admittedly mostly in C++. Yes, it is done far less in C, but still, as the above is invalid already in C89, users had over 3 decades to fix their code, and in many cases they didn't and without this move they will never bother. A lot of such broken code has been even written in those 3 decades, doesn't predate it, but because the compiler just warned on it, it still appeared in the code bases. If we wait with this change another 2 decades, nothing will change and we'll have the same problem then. Jakub