bitcoin/secp256k1 — pull request #33 by theuni (2014-06-20 17:11:32+00:00)
Title: RFC: Enable and fix paranoid warnings

This is _not_ meant for merge as-is, but rather to discuss whether it's worth doing, and if so, how it might be done correctly.

Abstract: If a baseline can be established where compilers (with all paranoid checks enabled) produce zero warnings, bugs in new code become much easier to spot.

This PR adds 2 configure switches: enable all paranoid warnings (and filter out the few that we don't care about), and turn warnings into errors. When combined, the pull-tester will fail when a new warning is introduced. It also adds clang to the build matrix in order to add a new batch of warnings (-Weverything)

The results are here: https://travis-ci.org/theuni/secp256k1/builds/28015905

Obviously most of these warnings are completely harmless and have no consequences, but a few legitimate bugs turn up as well. In a heavy math/crypto lib, type narrowing and implicit sign changes can be especially dangerous, so I would argue that these warnings are actually quite valuable.

Also, obviously the warnings that compilers enable with "-Wall -Wextra -Weverything" are entirely arbitrary, so the list of filtered warnings will likely evolve a bit.

Assuming this work is wanted, I see 2 possible ways to go about it:
1. as done in this pr. Quell all warnings so that the pull tester is happy, then begin fixing them up correctly. Please read the commit message from https://github.com/theuni/secp256k1/commit/30fba32ddab28d034afdd530d8dbd8d524832619 before pointing out the stupid changes in that commit.
2. don't flip the 'all warnings are errors' switch, and fix up each case properly. then flip the switch.