Re: Suspicion of a compiler bug in clang: using ternary operator in ereport()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christian Kruse <christian(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Suspicion of a compiler bug in clang: using ternary operator in ereport()
Date: 2014-01-29 18:39:27
Message-ID: 3428.1391020767@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Christian Kruse <christian(at)2ndquadrant(dot)com> writes:
> Ok, so I propose the attached patch as a fix.

No, what I meant is that the ereport caller needs to save errno, rather
than assuming that (some subset of) ereport-related subroutines will
preserve it.

In general, it's unsafe to assume that any nontrivial subroutine preserves
errno, and I don't particularly want to promise that the ereport functions
are an exception. Even if we did that, this type of coding would still
be risky. Here are some examples:

ereport(...,
foo() ? errdetail(...) : 0,
(errno == something) ? errhint(...) : 0);

If foo() clobbers errno and returns false, there is nothing that elog.c
can do to make this coding work.

ereport(...,
errmsg("%s belongs to %s",
foo(), (errno == something) ? "this" : "that"));

Again, even if every single elog.c entry point saved and restored errno,
this coding wouldn't be safe.

I don't think we should try to make the world safe for some uses of errno
within ereport logic, when there are other very similar-looking uses that
we cannot make safe. What we need is a coding rule that you don't do
that.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2014-01-29 18:54:31 FOREIGN KEY ... CONCURRENTLY
Previous Message Simon Riggs 2014-01-29 18:19:32 Re: proposal: hide application_name from other users