Re: Allowing printf("%m") only where it actually works

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Allowing printf("%m") only where it actually works
Date: 2018-05-21 06:21:34
Message-ID: CAEepm=2-7qBw6U-vy2OgL=Z=J6VeOzPS5jsK2PwmG0PWTDv1cg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 21, 2018 at 4:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> ... and, while we're thinking about this, how can we prevent the reverse
> problem of using strerror(errno) where you should have used %m? That
> is evidently not academic either, cf 81256cd.
>
> 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.

Another idea: if there are any systems in the build farm where it
isn't a macro as permitted by the standard (#ifndef errno), you could
perhaps define it as something uncompilable and then undefined it at
the end of the scope, so we'd at least have a post-commit canary.

--
Thomas Munro
http://www.enterprisedb.com

Attachment Content-Type Size
prevent-errno.patch application/octet-stream 1.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2018-05-21 07:03:57 Re: [HACKERS] kqueue
Previous Message Ashutosh Bapat 2018-05-21 06:01:47 Re: [HACKERS] Transactions involving multiple postgres foreign servers