Re: A few warnings on Windows - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: A few warnings on Windows
Date
Msg-id e634cd5a-6869-f270-4d72-09ce7494730d@2ndquadrant.com
Whole thread Raw
In response to Re: A few warnings on Windows  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: A few warnings on Windows  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 5/1/18 16:48, Tom Lane wrote:
> On more or less the same topic, I just scraped all the compiler warnings
> for HEAD from the buildfarm database, and there seem to be a few other
> things worth cleaning up.  One that I'm looking at is that recent gcc
> has a -Wimplicit-fallthrough warning for switch branches not separated
> by a "break" or similar.  It can be silenced with a comment similar to
> /* FALLTHROUGH */, but we have not been entirely consistent about
> providing such comments.  I'm inclined to run around and fix those
> omissions.  Perhaps at some point we should have configure turn that
> warning on if available?

I think it's useful, but I have found it a bit fickle at times.

One issue is <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79750>, which
requires this additional patch

diff --git a/src/interfaces/libpq/fe-secure.c
b/src/interfaces/libpq/fe-secure.c
index cfb77f6d85..a39d50ddcf 100644
--- a/src/interfaces/libpq/fe-secure.c
+++ b/src/interfaces/libpq/fe-secure.c
@@ -363,6 +363,7 @@ pqsecure_raw_write(PGconn *conn, const void *ptr,
size_t len)
                /* FALL THRU */

 #ifdef ECONNRESET
+               /* FALL THRU */
            case ECONNRESET:
 #endif
                printfPQExpBuffer(&conn->errorMessage,

to build warning-free on some systems.

Another issue that has prevented me in the past from taking this too
seriously is requiring breaks after elog(ERROR) calls.  I see you bit
the bullet and added those breaks, which is fair enough.  But if gcc
ever fixes this bug
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79959), then as new code
gets added without it, users of older compilers will start getting
warnings.  So we might have to craft that configure test to detect that
issue when that time comes.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: doc fixes: vacuum_cleanup_index_scale_factor
Next
From: Andres Freund
Date:
Subject: Re: pgsql: Clean up warnings from -Wimplicit-fallthrough.