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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Suspicion of a compiler bug in clang: using ternary operator in ereport()
Дата
Msg-id 3428.1391020767@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Suspicion of a compiler bug in clang: using ternary operator in ereport()  (Christian Kruse <christian@2ndquadrant.com>)
Ответы Re: Suspicion of a compiler bug in clang: using ternary operator in ereport()  (Christian Kruse <christian@2ndquadrant.com>)
Список pgsql-hackers
Christian Kruse <christian@2ndquadrant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: proposal: hide application_name from other users
Следующее
От: David Fetter
Дата:
Сообщение: FOREIGN KEY ... CONCURRENTLY