aboutsummaryrefslogtreecommitdiff
path: root/src/interfaces/libpq/fe-secure-gssapi.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-05-01 17:28:00 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-05-01 17:28:00 -0400
commitc08da32f133b0fea794d7cf346bfa73021366d3a (patch)
treebda7e417141d4822a525959c40e0ea631b58cb21 /src/interfaces/libpq/fe-secure-gssapi.c
parente1477db92105c56fe057855ba13b5b1288edd06d (diff)
downloadpostgresql-c08da32f133b0fea794d7cf346bfa73021366d3a.tar.gz
postgresql-c08da32f133b0fea794d7cf346bfa73021366d3a.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/interfaces/libpq/fe-secure-gssapi.c')
0 files changed, 0 insertions, 0 deletions