Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fKnHV-0005gj-M1 for pgsql-hackers@arkaria.postgresql.org; Mon, 21 May 2018 16:03:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fKnHT-0001vH-Q7 for pgsql-hackers@arkaria.postgresql.org; Mon, 21 May 2018 16:03:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fKnHT-0001v8-J0 for pgsql-hackers@lists.postgresql.org; Mon, 21 May 2018 16:03:27 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fKnHQ-00028F-QA for pgsql-hackers@lists.postgresql.org; Mon, 21 May 2018 16:03:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w4LG3K24031056; Mon, 21 May 2018 12:03:20 -0400 From: Tom Lane To: Thomas Munro cc: PostgreSQL Hackers Subject: Re: Allowing printf("%m") only where it actually works In-reply-to: References: <2975.1526862605@sss.pgh.pa.us> <14176.1526874887@sss.pgh.pa.us> <24986.1526877413@sss.pgh.pa.us> Comments: In-reply-to Thomas Munro message dated "Mon, 21 May 2018 18:21:34 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31053.1526918600.1@sss.pgh.pa.us> Date: Mon, 21 May 2018 12:03:20 -0400 Message-ID: <31054.1526918600@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Thomas Munro writes: > On Mon, May 21, 2018 at 4:36 PM, Tom Lane wrote: >> I am wondering whether the elog/ereport macros can locally define some >> version of "errno" that would cause a compile failure if it's referenced >> within the macro args. But I'm too tired to work it out in detail. > Here's an experimental way to do that, if you don't mind depending on > gory details of libc implementations (ie knowledge of what it expands > too). Not sure how to avoid that since it's a macro on all modern > systems, and we don't have a way to temporarily redefine a macro. If > you enable it for just ereport(), it compiles cleanly after 81256cd > (but fails on earlier commits). If you enable it for elog() too then > it finds problems with exec.c. Hmm ... that's pretty duff code in exec.c, isn't it. Aside from the question of errno unsafety, it's using elog where it really ought to be using ereport, it's not taking any thought for the reported SQLSTATE, etc. I'm hesitant to mess with it mere hours before the beta wrap, but we really oughta improve that. I noticed another can of worms here, too: on Windows, doesn't use of GetLastError() in elog/ereport have exactly the same hazard as errno? Or is there some reason to think it can't change value during errstart()? regards, tom lane