From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 009E1384F021 for ; Thu, 20 Oct 2022 16:35:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 009E1384F021 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.95,199,1661846400"; d="scan'208";a="85118321" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 20 Oct 2022 08:35:25 -0800 IronPort-SDR: QuBOYWx8zz/AxNJW50uY1Uvb2o13Aojh/fNqXn7Ib4EWkFuZRwqcgCSU/kkQKPK0FVLRiuxj1a pqsisH7/IMsibElLFFjtWv8wfurh3PyqLZ1bUA0I66Vx1UEvb3xIcIDpYsMaJKXbt9plfg1MI8 VA2SecNfPEn4IpkZkrnBv0AfUgPy6lNMHhXv2CHqa5eGsmKdGoQ/P+rHGWmH/MPr0ZGKTpQpt8 FmpDOsJliZFkJohHa9hFkA6pM6eV9dSY/6GL5Y/b45thqvYqiEeZlBdo2RP9n3S97gTP6W76cF E3w= Date: Thu, 20 Oct 2022 16:35:20 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Richard Biener CC: Subject: Re: No-named-argument variadic functions In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3110.6 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP 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 Thu, 20 Oct 2022, Richard Biener via Gcc wrote: > > 1. How should (...) be represented differently from unprototyped functions > > so that stdarg_p and prototype_p handle it properly? Should I add a new > > language-independent type flag (there are plenty spare) to use for this? > > I'd say unprototyped should stay with a NULL TYPE_ARG_TYPES but > a varargs function might change to have a TREE_LIST with a NULL type > as the trailing element? Not sure if we want to change this also for > varargs functions with actual arguments. > > If we want to go down the route with a flag on the function type then > I'd rather flag the unprototyped case and leave varargs without any > actual arguments as NULL TYPE_ARG_TYPES? The issue with both of those options is that they don't seem very safe for code that accesses TYPE_ARG_TYPES directly, of which I think we have a lot. Such code is quite likely to fall over on a TREE_LIST with a NULL type entry, and having code that encounters a (...) prototype treat it like an unprototyped function seems safer than having code that encounters an unprototyped function treat it like a (...) prototype because the code that created the function type failed to set a flag to say it's unprototyped. (In principle TYPE_ARG_TYPES could change to have static type other than tree, with explicit flags both for stdarg_p and for prototype_p, which would provide GCC-build-time assurance that there's no non-updated code left that expects an old representation. But that would be a very large change.) -- Joseph S. Myers joseph@codesourcery.com