On 2014-01-06 09:54:15 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > >> On Mon, Jan 6, 2014 at 11:38 PM, Heikki Linnakangas > >> <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
