Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oa2b7-0003PI-0E for pgsql-hackers@arkaria.postgresql.org; Sun, 18 Sep 2022 22:17:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oa2b4-0004F9-UY for pgsql-hackers@arkaria.postgresql.org; Sun, 18 Sep 2022 22:17:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oa2b4-0004F0-Jk for pgsql-hackers@lists.postgresql.org; Sun, 18 Sep 2022 22:17:06 +0000 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oa2b1-0006HG-Ou for pgsql-hackers@postgresql.org; Sun, 18 Sep 2022 22:17:05 +0000 Received: by mail-ej1-x62b.google.com with SMTP id bj12so60502861ejb.13 for ; Sun, 18 Sep 2022 15:17:03 -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; bh=dNazIZAgRa17rdvgr6nl/eVOXgERwA+n02imxCUzQk4=; b=hx5v3DO/CX/xlZVrzvwtr6orcRodit4+ld8wCoVKFe45VzG8ZNFJks42ImXJqoVEHV EiUFQClo6gahlLNyNpDCbjkKishHrLcI39wpAMuKuGxaj3TiMkG4tdaZap54cxv2ZVzl j3R/F+tlT8dUG7XsaGaNoRdJQLq67gulJ66Gendw+LMddhbyr77DrUuRYT4eQu5C2F2P 8ouJqvJBjVp/RFrHS6NchF/DB9genrOm8JldzrmAAlx/aaIXh4aPsMbNxQiaKAAnaTCx XLboGXzAbg9T47Y7ROqU/GfNp466ShzvEpTtNYyZ91/8OUSsnnKK959Kh+24UihsVsTt f7+w== 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; bh=dNazIZAgRa17rdvgr6nl/eVOXgERwA+n02imxCUzQk4=; b=WVluWNKkBxdTj0WmaVPWx/mdmyb4+poFkSqCWMsdwgBJaurkH7VFJlK3EFkcOl56I2 8w2Rp0C7PpQKty0AJpxWv+bhw2MKwvvhCVFInfjCmE2GP1BCoesH882aZz9gLpAwZw1i 9FOYH++4jWgU6ZYcUx7OfWaDFE1XCMUCTkV2bQvGFXqEx8Bqov4vAzsOZeijIxI/8Qoo jHb0yLEJgb6uXaBGZVAkHZH6+C3Zyoa6bLGW94a8sgrQiaDU03pBE1WRFN4+pVogwz3r lovB7yM5AKmZOSCY6dTQaS2FPeCKqFrc81bB1yqTgGtT0Tmv0yWqJxVxiWlAOA6G2+Ki Bsug== X-Gm-Message-State: ACrzQf3/pwScvD54H1lAg8b5Ag5TjMqrBar84aMMmgr6soc6hWUV78sn TxVauWeFXHD7e6Jr+7hYeo33450sEdejKqyWJ9c= X-Google-Smtp-Source: AMsMyM6u3OzeY3YLTLbSDKZP5q2yoHzn/ubHfsH2Nl+o2CiewSOyJh730T16WsLoTwqeaTUsnBClUe1qs2iaiByUHLQ= X-Received: by 2002:a17:907:2bcf:b0:772:4b8e:6b29 with SMTP id gv15-20020a1709072bcf00b007724b8e6b29mr10653015ejc.412.1663539421576; Sun, 18 Sep 2022 15:17:01 -0700 (PDT) MIME-Version: 1.0 References: <1725174.1651449765@sss.pgh.pa.us> <3953550.1663376882@sss.pgh.pa.us> <208054.1663534665@sss.pgh.pa.us> In-Reply-To: <208054.1663534665@sss.pgh.pa.us> From: Thomas Munro Date: Mon, 19 Sep 2022 10:16:24 +1200 Message-ID: Subject: Re: Tree-walker callbacks vs -Wdeprecated-non-prototype To: Tom Lane Cc: pgsql-hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Sep 19, 2022 at 8:57 AM Tom Lane wrote: > I think we ought to seriously consider the alternative of changing > nodeFuncs.c about like I have here, but not touching the walkers/mutators, > and silencing the resulting complaints about function type casting by > doing the equivalent of > > - return expression_tree_walker(node, cost_qual_eval_walker, > - (void *) context); > + return expression_tree_walker(node, > + (tree_walker_callback) cost_qual_eval_walker, > + (void *) context); > > We could avoid touching all the call sites by turning > expression_tree_walker and friends into macro wrappers that incorporate > these casts. This is fairly annoying, in that it gives up the function > type safety the C committee wants to impose on us; but I really think > the data type safety that we're giving up in this version of the patch > is a worse hazard. But is it defined behaviour? https://stackoverflow.com/questions/559581/casting-a-function-pointer-to-another-type > BTW, I was distressed to discover that someone decided they could > use ExecShutdownNode as a planstate_tree_walker() walker even though > its argument list is not even the right length. I'm a bit flabbergasted > that we seem to have gotten away with that so far, because I'd have > thought for sure that it'd break some platform's convention for which > argument gets passed where. I think we need to fix that, independently > of what we do about the larger scope of these problems. To avoid an > API break, I propose making ExecShutdownNode just be a one-liner that > calls an internal ExecShutdownNode_walker() function. (I've not done > it that way in the attached, though.) Huh... wouldn't systems that pass arguments right-to-left on the stack receive NULL for node? That'd include the SysV i386 convention used on Linux, *BSD etc. But that can't be right or we'd know about it... But certainly +1 for fixing that regardless.