Question: Whenever I compile [SQLite](http://www.sqlite.org) with Visual C++ 9 I get hundreds of warnings, such as

* potentially uninitialized variables
* conversion from wider integer types to narrower integer types
* signed/unsigned integers mismatches.

I'm not alone - there's an [SQLite FAQ question](http://www.sqlite.org/faq.html#q17) specifically about that. The answer to that question says that

* those warnings don't arise in GCC that SQLite developers use
* warnings are not that of a problem since the team tests code thorougly

Of course I can't argue against those points, but...

* I don't use GCC - I use VC++ and VC++ does show warnings
* they tested the code compiled with GCC and I don't use GCC, so there might be some implementation-defined difference or something like different levels of C standard compliance between GCC and VC++ that will subtly break the code with severe consequences.

That's why I don't like the idea of simply ignoring all warnings.

So how do I deal with warnings VC++ displays when compiling SQLite?

Answer: 
Why not use `#pragmas` to disable these warnings if they're not actually causing any harm? Or switch to a lower warning level (as I assume you have the SQLite source as a separate VC lib project?)
What these warnings basically mean is that:

1. If you port the code to an environment where all the basic types (char, short, int, long, long long) are exactly the same size as what the original developers used and tested with, the code will probably work as tested (although watch out for those possibly uninitialized variables), but
2. If you ever port the code to an environment where some of the basic types are different sizes from what the the original developers used, you have a good chance of the code breaking in mysterious and counter-intuitive ways at some of the places where you are getting these warnings. That can be true even if you use GCC in both environments. See the [C FAQ 3.19](http://c-faq.com/expr/preservingrules.html) for some examples of the kind of behavior that can occur (keeping in mind that both C and C++ standards now mandate the "value-preserving" rules).

It's a sign of sloppy coding. They really should fix most of the issues leading to these warnings (typically, mixing signed and unsigned types across a binary operator is risky, and I bet they are doing that a lot here). I've fixed other people's code that has led to such warnings in the past, making it more robust for porting to future environments. But that said, if they are compiling and testing with the same basic type sizes that you will be using (which they almost certainly are if there's a compatible C-language interface to link to), then you probably can get away without fixing many of these problems.