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
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 |