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 1oBGZw-0005fW-Rd for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Jul 2022 14:09:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oBGZu-0001bJ-FF for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Jul 2022 14:09:30 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oBGZu-0001b9-1m for pgsql-hackers@lists.postgresql.org; Tue, 12 Jul 2022 14:09:30 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oBGZo-0002D4-6h for pgsql-hackers@postgresql.org; Tue, 12 Jul 2022 14:09:29 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 26CE9M5u1522408; Tue, 12 Jul 2022 10:09:22 -0400 From: Tom Lane To: Robert Haas cc: Thomas Munro , pgsql-hackers Subject: Re: Cleaning up historical portability baggage In-reply-to: References: Comments: In-reply-to Robert Haas message dated "Tue, 12 Jul 2022 08:01:40 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1522406.1657634962.1@sss.pgh.pa.us> Date: Tue, 12 Jul 2022 10:09:22 -0400 Message-ID: <1522407.1657634962@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > On Mon, Jul 11, 2022 at 9:11 PM Thomas Munro wrote: >> Hmm, but that's not what we're doing in general. For example, on >> Windows we're redirecting open() to a replacement function of our own, >> we're not using "pg_open()" in our code. That's not an example based >> on AC_REPLACE_FUNCS, but there are plenty of those too. Isn't this >> quite well established? > Yes. I just don't care for it. > Sounds like I'm in the minority, though. I concur with your point that it's not great to use the standard name for a function that doesn't have exactly the standard semantics. But if it does, using a nonstandard name is not better. It's just one more thing that readers of our code have to learn about. Note that "exactly" only needs to mean "satisfies all the promises made by POSIX". If some caller is depending on behavior details not specified in the standard, that's the caller's bug not the wrapper function's. Otherwise, yeah, we couldn't ever be sure whether a wrapper function is close enough. regards, tom lane