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: ExceptionalCondition() return type |
Date: | 2012-04-26 19:01:42 |
Message-ID: | 11903.1335466902@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 came across this comment:
> /*
> * ExceptionalCondition - Handles the failure of an Assert()
> *
> * Note: this can't actually return, but we declare it as returning int
> * because the TrapMacro() macro might get wonky otherwise.
> */
> But it seems to me that this can easily be fixed like shown below, which
> compiles without warnings. Is there any problem with that?
Um ... you did not fix the comment.
> I noticed that the comment at TrapMacro suggests this usage pattern
> #define foo(x) (AssertMacro(x != 0) && bar(x))
> but all actual uses of AssertMacro() chain it using the comma operator.
Should probably adjust that comment to suggest commas, too.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2012-04-26 19:08:54 | Re: Request to add options to tools/git_changelog |
Previous Message | Jameison Martin | 2012-04-26 18:59:01 | Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap |