On Fri, Sep 29, 2017 at 1:20 PM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > On Fri, 29 Sep 2017, Scott Robison wrote: >> >> >> The problem is that there is no one best practice for resolving all >> such warnings in a way that makes all compilers happy. It is possible >> to fix all the warnings for one platform, then move on to the next >> platform and fix all its warnings, and return to the original platform >> and discover that new warnings have been introduced. > > > My own experience has been that it is possible to write valid C code which > does not produce warnings at high warning levels on just about any standard > C compiler. It is not necessarily a case of "whack a mole". The most > annoying exception is the Microsoft Visual C Compiler, which produces > deprecation warnings for standard functions. > > One does need to be very careful when fixing compiler warnings so as to not > introduce new bugs. The most dangerous warnings to work on are those > involving signed vs unsigned types.
Except for the fact that the OP called for maximum pedantic warnings. In that case, you can't reliably fix all the warnings, because different compilers have different ideas of what maximum means. In this very thread there is a warning from GCC about #if SQLITE_4_BYTE_ALIGNED_MALLOC not being defined. But the standard requires that undefined symbols being replaced with 0 during preprocessing. How is that warning useful? It is by definition standard compliant and well defined. The problem is not just with MSVC. It is not that warning free code is impossible to create, it just depends on the details, which sometimes make it very difficult. -- Scott Robison _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
