Thread: Re: pgsql: Clean up warnings from -Wimplicit-fallthrough.
Hi,
On 2018-05-01 23:35:18 +0000, Tom Lane wrote:
> Clean up warnings from -Wimplicit-fallthrough.
>
> Recent gcc can warn about switch-case fall throughs that are not
> explicitly labeled as intentional. This seems like a good thing,
> so clean up the warnings exposed thereby by labeling all such
> cases with comments that gcc will recognize.
>
> In files that already had one or more suitable comments, I generally
> matched the existing style of those. Otherwise I went with
> /* FALLTHROUGH */, which is one of the spellings approved at the
> more-restrictive-than-default level -Wimplicit-fallthrough=4.
> (At the default level you can also spell it /* FALL ?THRU */,
> and it's not picky about case. What you can't do is include
> additional text in the same comment, so some existing comments
> containing versions of this aren't good enough.)
There's also a few cases in the LLVM using code, I'll clean that up momentarily.
> Testing with gcc 8.0.1 (Fedora 28's current version), I found that
> I also had to put explicit "break"s after elog(ERROR) or ereport(ERROR);
> apparently, for this purpose gcc doesn't recognize that those don't
> return. That seems like possibly a gcc bug, but it's fine because
> in most places we did that anyway; so this amounts to a visit from the
> style police.
I found one more oddity with the current committed state:
/home/andres/src/postgresql/src/interfaces/libpq/fe-secure.c: In function ‘pqsecure_raw_write’:
/home/andres/src/postgresql/src/interfaces/libpq/fe-secure.c:91:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
if (cond) \
^
/home/andres/src/postgresql/src/interfaces/libpq/fe-secure.c:362:5: note: in expansion of macro ‘REMEMBER_EPIPE’
REMEMBER_EPIPE(spinfo, true);
^~~~~~~~~~~~~~
/home/andres/src/postgresql/src/interfaces/libpq/fe-secure.c:366:4: note: here
case ECONNRESET:
^~~~
It seems that gcc gets confused by the #ifdef ECONNRESET. Somehow adding
a newline before cures it. But the nicer fix seems to be to move the
FALL THRU into the ifdef, which even seems more correct when nitpicking
in god mode.
Unless you've a better idea I'll fix that together with the LLVM stuff.
Greetings,
Andres Freund
On 2018-05-01 17:32:39 -0700, Andres Freund wrote: > Hi, > > On 2018-05-01 23:35:18 +0000, Tom Lane wrote: > > Clean up warnings from -Wimplicit-fallthrough. > > > > Recent gcc can warn about switch-case fall throughs that are not > > explicitly labeled as intentional. This seems like a good thing, > > so clean up the warnings exposed thereby by labeling all such > > cases with comments that gcc will recognize. > > > > In files that already had one or more suitable comments, I generally > > matched the existing style of those. Otherwise I went with > > /* FALLTHROUGH */, which is one of the spellings approved at the > > more-restrictive-than-default level -Wimplicit-fallthrough=4. > > (At the default level you can also spell it /* FALL ?THRU */, > > and it's not picky about case. What you can't do is include > > additional text in the same comment, so some existing comments > > containing versions of this aren't good enough.) > > There's also a few cases in the LLVM using code, I'll clean that up momentarily. > > > > Testing with gcc 8.0.1 (Fedora 28's current version), I found that > > I also had to put explicit "break"s after elog(ERROR) or ereport(ERROR); > > apparently, for this purpose gcc doesn't recognize that those don't > > return. That seems like possibly a gcc bug, but it's fine because > > in most places we did that anyway; so this amounts to a visit from the > > style police. > > I found one more oddity with the current committed state: > /home/andres/src/postgresql/src/interfaces/libpq/fe-secure.c: In function ‘pqsecure_raw_write’: > /home/andres/src/postgresql/src/interfaces/libpq/fe-secure.c:91:6: warning: this statement may fall through [-Wimplicit-fallthrough=] > if (cond) \ > ^ > /home/andres/src/postgresql/src/interfaces/libpq/fe-secure.c:362:5: note: in expansion of macro ‘REMEMBER_EPIPE’ > REMEMBER_EPIPE(spinfo, true); > ^~~~~~~~~~~~~~ > /home/andres/src/postgresql/src/interfaces/libpq/fe-secure.c:366:4: note: here > case ECONNRESET: > ^~~~ > > It seems that gcc gets confused by the #ifdef ECONNRESET. Somehow adding > a newline before cures it. But the nicer fix seems to be to move the > FALL THRU into the ifdef, which even seems more correct when nitpicking > in god mode. > > Unless you've a better idea I'll fix that together with the LLVM stuff. Pushed that way.
Andres Freund <andres@anarazel.de> writes: > On 2018-05-01 23:35:18 +0000, Tom Lane wrote: >> Clean up warnings from -Wimplicit-fallthrough. > I found one more oddity with the current committed state: ... > It seems that gcc gets confused by the #ifdef ECONNRESET. Yeah, there's a gcc bug or three about that: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817 > ... But the nicer fix seems to be to move the > FALL THRU into the ifdef, which even seems more correct when nitpicking > in god mode. I thought about that, and didn't like it much. I hoped maybe the gcc guys would fix it soon, but after reading their bugzilla entry more closely, it sounds like we shouldn't hold our breath. So if you want to do it like that, OK by me. regards, tom lane
On 5/1/18 23:33, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: >> On 2018-05-01 23:35:18 +0000, Tom Lane wrote: >>> Clean up warnings from -Wimplicit-fallthrough. > >> I found one more oddity with the current committed state: ... >> It seems that gcc gets confused by the #ifdef ECONNRESET. > > Yeah, there's a gcc bug or three about that: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817 > >> ... But the nicer fix seems to be to move the >> FALL THRU into the ifdef, which even seems more correct when nitpicking >> in god mode. > > I thought about that, and didn't like it much. I hoped maybe the gcc guys > would fix it soon, but after reading their bugzilla entry more closely, > it sounds like we shouldn't hold our breath. So if you want to do it > like that, OK by me. It sounds like we have a handle on all the potential issues for now, so I think it would be OK to add this warning to the standard set on master. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services