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: 15939.1341005734@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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
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

In response to

Responses

Browse pgsql-hackers by date

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