On 2014-01-06 09:54:15 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> >> On Mon, Jan 6, 2014 at 11:38 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> >>> Hmm, I thought we gave enough hints in the elog macro to tell the compiler
> >>> that elog(ERROR) does no return, since commit b853eb97182079dcd30b4f52576bd5d6c275ee71.
>
> > But afair the declaration for elog() works in several other places, so
> > that doesn't sufficiently explain this. I'd very much expect that that
> > variable is complitely elided by any halfway competent compiler - it's
> > just there to prevent multiple evaluation should elevel not be a
> > constant.
>
> At -O0 (or local equivalent), it would not surprise me at all that
> compilers wouldn't recognize elog(ERROR) as not returning.
You have a point, but I don't think that any of the compilers we try to
keep clean have such behaviour in the common case - at least most
versions of gcc certainly recognize such on -O0, and I am pretty sure that
52906f175a05a4e7e5e4a0e6021c32b1bfb221cf fixed some warnings for mvcc,
at least in some versions and some configurations.
So I am wondering if there's a special reason it doesn't recognize this
individual case as it does seem to work in others - defining
pg_unreachable() to be empty generates about a dozen warnings here.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services