使用VC ++编译SQLite时如何解决警告？

Question

Whenever I compile SQLite 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 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 1

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?)

Answer 2

How does any developer working with C++ deal with warnings? Investigate the code about which you're receiving the warning, determine if the warning is telling you something you need to know, and then change the code if needed. I'm not sure I really understand your question.

Maybe if you posted a specific warning (with code) we might be able to advise you about what you need to do about it.

Answer 3

I would say that compiling something as complicated as SQLite, using a compiler and libraries the developers themselves say they never use, is doomed to failure, or at the least will be very, very painful. GCC is easy to install and use on Windows (get it from http://tdragon.net/recentgcc ), so why not use it?

Answer 4

First, remember that warnings are not error indicators. They're there to draw the developers' attention to things that could indicate errors, and nothing else.

If the code works, the number of warnings emitted is pretty much irrelevant.

If you want to play it safe, look at the warnings: Are any of them related to implementation-defined behavior which is handled differently by VS and GCC? If so, you might have a problem. But as long as the warnings are about things that are handled identically by both compilers (such as integer/double conversions), it can be ignored.

As I recall (been a while since I compiled SQLite on VS without silencing warnings), virtually all the warnings are about implicit conversions between built-in types, all of which are perfectly safe, as long as the developer is aware they're taking place.

SQLite works just fine on VS though. The library is widely used by a lot of big projects. It is tested fairly extensively.

Answer 5

Select the files in the VC9 solution explorer, right-click, choose "properties". Then go to the C++ -> General tab and set the Warning level to Off . That will turn off all warnings for those files only.

I do that with most of the external lib files I use: there's no gain to 'fix' those (if they're not really bugs), and turning off the warnings helps to keep the build output window clean so I don't miss warnings in my own code.

Answer 6

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 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.