Re: elog/ereport noreturn decoration - Mailing list pgsql-hackers

From Tom Lane
Subject Re: elog/ereport noreturn decoration
Date
Msg-id 15939.1341005734@sss.pgh.pa.us
Whole thread Raw
In response to elog/ereport noreturn decoration  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: elog/ereport noreturn decoration
Re: elog/ereport noreturn decoration
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.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
else.

Perhaps we could do something like
       default:           elog(ERROR, "unrecognized drop object type: %d",                (int) drop->removeType);
-           relkind = 0;                     /* keep compiler quiet */
+           UNREACHABLE(relkind = 0);        /* keep compiler quiet */           break;

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


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Event Triggers reduced, v1
Next
From: Dimitri Fontaine
Date:
Subject: Re: Event Triggers reduced, v1