Re: cleanup in code

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cleanup in code
Date: 2014-01-07 15:20:23
Message-ID: 13123.1389108023@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> I think it will be like Andres said up thread, to stop multiple evaluations
> of the expression passed to the macro.

Exactly. We are not going to risk multiple evals in a macro as commonly
used as elog/ereport; the risk/benefit ratio is just too high.

I don't see anything wrong with suppressing this warning by inserting
an additional return statement. The code is already plastered with such
things, from the days before we had any unreachability hints in
elog/ereport. And as I said upthread, there is no good reason to suppose
that the unreachability hints are always recognized by every compiler.
I take this behavior of MSVC as proof of that statement.

It is mildly curious that MSVC fails to understand the unreachability hint
here when it does so elsewhere, but for our purposes, that's a purely
academic question.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-01-07 15:21:04 Re: generic pseudotype IO functions?
Previous Message Christoph Berg 2014-01-07 15:09:44 extra_float_digits and casting from real to numeric