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.133.124]) by sourceware.org (Postfix) with ESMTPS id 5B4AF3865491 for ; Thu, 15 Feb 2024 16:22:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B4AF3865491 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5B4AF3865491 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708014131; cv=none; b=ulnO8rTRl+oaPvml68V9mcv6nYi3aKHGlyQm3P3fKCe5X0GF6jpV8VqU/tEBvANKkR9X/wOZzwJN+YHPit0P2BG8LAh+y0H3GSMbGBwovmtLN5eqIDouTocWJpiYohE2XzxDIAWbeKlpikaA1y4dmujH75gXZglyLse4/qejO5k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708014131; c=relaxed/simple; bh=1CH+Wk8boNtb3LG+/GpoaZ+TgXRfOzYL23jCpar+9hI=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=uRWBLn3E4MgDUZvoVGd4+3EH1/3FHNzkJ96CKD0gacPTHkx8vxe/wFIpj4PtYLZuH6z975Gcetytsy1DvA9zuWJaZ8B1sLWb+NHE55VUB4hiPjRxnAa49i5ipmKHdZh6rO0hPekdx9uvE4WogBVHcv2goH4vohpwPcEWgrrzFCI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1708014129; 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=OKpinUOekf1rUfEBmSMv5hiw+OaWtpDW4TU4TfyzdPA=; b=HSvR95bdPy3XSSNBhiQN4uWyfL/9Dsh+SdouwClNIt4yKTW+UeQB6dwCXcrCVUAF5Yaxli y+yGfbFKdYgIahrgCxUSVJhhH6g1lQ/Xs7PPQzN/GYZAwXLQlcjXRz0rJx5j27atKea4Bj XSI+9DqApcEVyTfNrDKiaXl4fjJRJtg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-78-X9yonOCpPtOJx3rY4Uclzg-1; Thu, 15 Feb 2024 11:22:05 -0500 X-MC-Unique: X9yonOCpPtOJx3rY4Uclzg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 72B4C85A58A; Thu, 15 Feb 2024 16:22:05 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.50]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CC1AF400D5CC; Thu, 15 Feb 2024 16:22:04 +0000 (UTC) From: Florian Weimer To: Gerald Pfeifer Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Notes on the warnings-as-errors change in GCC 14 References: <87v876ssxg.fsf@oldenburg.str.redhat.com> <9fce9298-1aec-27ce-591e-a1d415d34dba@pfeifer.com> Date: Thu, 15 Feb 2024 17:22:03 +0100 In-Reply-To: <9fce9298-1aec-27ce-591e-a1d415d34dba@pfeifer.com> (Gerald Pfeifer's message of "Sat, 10 Feb 2024 00:07:45 +0100 (CET)") Message-ID: <87edddaeac.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 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=-4.7 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,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: * Gerald Pfeifer: >> This mostly happens in function definitions >> +that are not prototypes > > Naive questions: Can definitions really be prototypes (in C)? Yes, I think so: definitions can be declarations, and function prototypes are declarations. The standard uses the phrase =E2=80=9Cfunctio= n definition that does not include a function prototype declarator=E2=80=9D. Should I write =E2=80=9Cold-style function definition=E2=80=9D instead? > >> +declared outside the parameter list. Using the correct >> +type maybe required to avoid int-conversion errors (see below). > > Something feels odd with this sentence? The fix is to write =E2=80=9Cmay[ ]be=E2=80=9C, as suggested by other revie= wers. >> +Incorrectly spelled type names in function declarations are treated as >> +errors in more cases, under a >> +new -Wdeclaration-missing-parameter-type warning. The >> +second line in the following example is now treated as an error >> +(previously this resulted in an unnamed warning): > > What is an "unnamed" warning? Can we simply omit "unnamed" here? A warning not controlled by a specific -W=E2=80=A6 option. I've made the change. >> +GCC will type-check function arguments after that, potentially >> +requiring further changes. (Previously, the function declaration was >> +treated as not having no prototype.) > > That second sentence uses double negation, which logically is the same as= =20 > just the original statement. Other reviews suggests to change it to =E2=80=9Cnot having [a] prototype=E2= =80=9D. >> +

>> +By default, GCC still accepts returning an expression of >> +type void from within a function that itself >> +returns void, as a GNU extension that matches C++ rules >> +in this area. > > Does the GNU extension match C++ (standard rules)? Yes. Should I write =E2=80=9Cmatches [standard] C++ rules=E2=80=9D? Thanks, Florian