From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 02D13385E02B for ; Thu, 20 Oct 2022 06:00:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 02D13385E02B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x634.google.com with SMTP id k2so44907715ejr.2 for ; Wed, 19 Oct 2022 23:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kQF9q+uCnVjRYzGv9rFcZS1OUzjuyV6Yzyd++OFPCrM=; b=nrGmO3t+SljHqDWrNAioC8eZjnYW1glXP0ICiqCHv/uxDSO1Db52D9gUVBF1PjxXaR yVP+2nS5I3b14yxf2VnDWAyIQGrWndi8wyhqqddwiSWZ+8BqHAd3dnm/7sqp9trkRUxP jBXcN8ySxABMy9hJJTdAu2sCDnclw8FOQeqSRM7omWluEIcCM7Syqu2FeA6MmaFFFkQZ U3rkeR9CLHLYnfQGpY+aBOHC7Q+3TAFz+o4fQRAletBqWtrIorTC2PQ1FpeGECLs8KK3 i/ggBjZitt8zR6+IWY4QR66WpEwx2b++V4/klWlS14QXBMsmA6/4+JYnL/7Be4WpnFtm V1ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=kQF9q+uCnVjRYzGv9rFcZS1OUzjuyV6Yzyd++OFPCrM=; b=i0XvKM2Sms6qMFPvf0C8cmx+W08LXkdWpVi16O43QEvEMtvkfWiW3Y9VSITRZ/vdQE k+SGoKjhkF8fKSJkCcbPRyoTf+DuoANaq8dij6BcPUsIYbv44Rx0iglVeHw3HeQ9zi08 vIv79d1nuQKWULoajpafnfboNtAhh2D+H554ELo3d5poN3w/xfbaVWY1+A8S3icbuz6f L0oGu9XPVCcPhGzJypQsbiNy4T32y52AcvaRn6gTs2QLWRO/3GgL/5Cb2QZj+ts/WN4t RRETOxtoXdSp6qrgNqg7e+MlDH/oyKoFY9NsKaLx++5mBsXOrMk8I0ZIsWzEvIb4yzED k4yQ== X-Gm-Message-State: ACrzQf05xeWyzbmCKBUxkTdqGvL8lqnpfLhm5ajcLNZHZ5ckT31YIHZp 4OmjKEZGiXjM9LXan6l8TxUe9doPZmnlEZBhYFE= X-Google-Smtp-Source: AMsMyM4jd3WdM8XO/4A/7mHfjXqBDOPVFcZ3DSsivjyzDsy2iq1VpzpU2wpgCA4w3AVhqJtrQi9i8o5dbp6ftRf0CMU= X-Received: by 2002:a17:907:7208:b0:78e:176e:e0c6 with SMTP id dr8-20020a170907720800b0078e176ee0c6mr9660086ejc.594.1666245624431; Wed, 19 Oct 2022 23:00:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 20 Oct 2022 08:00:12 +0200 Message-ID: Subject: Re: No-named-argument variadic functions To: Joseph Myers Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: On Thu, Oct 20, 2022 at 1:54 AM Joseph Myers wrote: > > 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? 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? > 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