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 3B6B5385AC19 for ; Wed, 19 Oct 2022 23:54:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3B6B5385AC19 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,196,1661846400"; d="scan'208";a="85068306" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 19 Oct 2022 15:53:59 -0800 IronPort-SDR: +GZ/7dYQatepgOADnWQQXVR/Hh2aAS2FDYRq1RDu0PDZbVMAtj/hzCDi/7rP1K/mOgEkZOTtr7 JbfWxjGworMfKvJE8mqzhkegnuUMiVySrQs44u7HdxNfWRX0ij6ivnjw2XeryquSWOHNlBsH35 n45MPMVMRzJBjsY4uNaQisaZVsRc4JkTGhxlX9AkSgMp35n9MDQr6OD3VMG/AQVLgov15a6teR mfyFEL9Psi3uywHp+s+Ktxxl3T0l8BYxm7ZOpUpiPuyAXW2oUctgLnPxKludvR3fRGerYWKdLe lJU= Date: Wed, 19 Oct 2022 23:53:53 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Subject: No-named-argument variadic functions Message-ID: 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-10.mgc.mentorg.com (139.181.222.10) 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: C2x allows variable-argument functions declared with (...) as parameters - no named arguments - as in C++. It *also* allows such functions to access their parameters, unlike C++, by relaxing the requirements on va_start so it no longer needs to be passed the name of the last named parameter. My assumption is that such functions should thus use the ABI for variable-argument functions, to the extent that's different from that for other functions. The main implementation issue I see is that GCC's internal representation for function types can't actually distinguish the (...) type from an unprototyped function - C++ functions with (...) arguments are treated by the middle end and back ends as unprototyped. (This probably works sufficiently well in ABI terms when the function can't actually use its arguments. Back ends may well call what they think are unprototyped functions in a way compatible with variadic callees anyway, for compatibility with pre-standard C code that calls e.g. printf without a prototype, even though standard C has never allowed calling variable-argument functions without a prototype.) So there are a few questions here for implementing this C2x feature: 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? 2. Does anyone see any likely ABI or back end issues from allowing single-argument calls to __builtin_va_start to access the arguments to such a function? (I'd propose to redefine va_start in stdarg.h to use a single-argument call, discarding any subsequent arguments, only for C2x.) 3. Should the C++ front end be changed to mark (...) functions in whatever way is chosen for question 1 above, so that they start using the appropriate ABI (and, in particular, calls between C and C++, where a C implementation of such a function might use the arguments, work properly)? Or would there be problems with compatibility with existing callers or callees assuming the unprototyped function ABI? -- Joseph S. Myers joseph@codesourcery.com