diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-05-01 17:28:01 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-05-01 17:28:01 -0400 |
commit | ad80d3ea27b1aef424d48ae937797ac3196b5e5f (patch) | |
tree | 3862150e6279ff798e2d63bd9e17467bdc343aa0 /src/backend/access/gist/gistproc.c | |
parent | b3824ca221223afedc2976f0577cf58dfa8a9804 (diff) | |
download | postgresql-ad80d3ea27b1aef424d48ae937797ac3196b5e5f.tar.gz postgresql-ad80d3ea27b1aef424d48ae937797ac3196b5e5f.zip |
Get rid of trailing semicolons in C macro definitions.
Writing a trailing semicolon in a macro is almost never the right thing,
because you almost always want to write a semicolon after each macro
call instead. (Even if there was some reason to prefer not to, pgindent
would probably make a hash of code formatted that way; so within PG the
rule should basically be "don't do it".) Thus, if we have a semi inside
the macro, the compiler sees "something;;". Much of the time the extra
empty statement is harmless, but it could lead to mysterious syntax
errors at call sites. In perhaps an overabundance of neatnik-ism, let's
run around and get rid of the excess semicolons whereever possible.
The only thing worse than a mysterious syntax error is a mysterious
syntax error that only happens in the back branches; therefore,
backpatch these changes where relevant, which is most of them because
most of these mistakes are old. (The lack of reported problems shows
that this is largely a hypothetical issue, but still, it could bite
us in some future patch.)
John Naylor and Tom Lane
Discussion: https://postgr.es/m/CACPNZCs0qWTqJ2QUSGJ07B7uvAvzMb-KbG2q+oo+J3tsWN5cqw@mail.gmail.com
Diffstat (limited to 'src/backend/access/gist/gistproc.c')
0 files changed, 0 insertions, 0 deletions