Skip site navigation (1) Skip section navigation (2)

Re: elog/ereport noreturn decoration

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: elog/ereport noreturn decoration
Date: 2012-06-29 21:35:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I think the issue here was that if we support two separate code paths,
> we still need to do the actually unreachable /* keep compiler happy */
> bits, and that compilers that know about elog not returning would
> complain about unreachable code.

Yes.  The problem with trying to change that is that it's damned if you
do and damned if you don't: compilers that are aware that abort()
doesn't return will complain about unreachable code if we keep those
extra variable initializations, while those that are not so aware will
complain about uninitialized variables if we don't.  I don't think
that's going to be a step forward.  IOW I am not on board with reducing
the number of warnings in clang by increasing the number everywhere

Perhaps we could do something like

            elog(ERROR, "unrecognized drop object type: %d",
                 (int) drop->removeType);
-           relkind = 0;                     /* keep compiler quiet */
+           UNREACHABLE(relkind = 0);        /* keep compiler quiet */

where UNREACHABLE(stuff) expands to the given statements (possibly
empty) or to abort() depending on the compiler's properties.  If we
did something like that we'd not need to monkey with the definition
of either elog or ereport, but instead we'd have to run around and
fix everyplace that was emitting warnings of this sort.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2012-06-29 21:38:15
Subject: Re: Event Triggers reduced, v1
Previous:From: Dimitri FontaineDate: 2012-06-29 21:34:37
Subject: Re: Event Triggers reduced, v1

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group