|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Missing errcode() in ereport|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> I think that at least some compilers will complain about side-effect-free
> subexpressions of a comma expression. Could we restructure things so
> that the errcode/errmsg/etc calls form a standalone comma expression
> rather than appearing to be arguments of a varargs function?
Yeah, the attached quick-hack patch seems to work really well for this.
I find that this now works:
where before it gave the weird error you quoted. Also, these both
draw warnings about side-effect-free expressions:
With gcc you just need -Wall to get such warnings, and clang
seems to give them by default.
As a nice side benefit, the backend gets a couple KB smaller from
removal of errfinish's useless dummy argument.
I think that we could now also change all the helper functions
(errmsg et al) to return void instead of a dummy value, but that
would make the patch a lot longer and probably not move the
goalposts much in terms of error detection.
It also looks like we could use the same trick to get plain elog()
to have the behavior of not evaluating its arguments when it's
not going to print anything. I've not poked at that yet either.
regards, tom lane
|Next Message||Justin Pryzby||2020-03-20 01:26:07||Re: improve transparency of bitmap-only heap scans|
|Previous Message||Peter Geoghegan||2020-03-20 00:34:11||Re: nbtree: assertion failure in _bt_killitems() for posting tuple|