Thanks, that is very helpful and reassuring as well. Will see if I can figure out then what is causing this one: warning C4028, as you say that could be a typo.
RBS -----Original Message----- From: Martin Jenkins [mailto:[EMAIL PROTECTED] Sent: 24 February 2007 18:11 To: sqlite-users@sqlite.org Subject: Re: [sqlite] compiling with VC++ RB Smissaert wrote: > When compiling this source code I get 265 warning, which doesn't really > worry me that much as it all seems to be working fine, but in general what > kind of warning should be taken seriously? This has come up the list before. Dr Hipp assigns a lot more weight to his tests passing than the complete absence of compiler warnings. This may sound cavalier but many of these warnings are in fact pretty benign. If you have a comprehensive test suite (as SQLite does) you can assume that these warnings *are* benign. One widely accepted reason for not "fixing" them is that most of the fixes (usually casts to similar type) just clutter up your source code and mask the intentions of the author. > I only have 8 different types of warnings: I won't go through them in huge detail because it's hard to say what the problem is without seeing the specific source lines, but generally compilers play safe and it's up to the author to know what he's doing. It can be a bit scary when you compile someone else's code for the first time - you see a load of warnings and think what a load of [EMAIL PROTECTED] but most of the time it's just the compiler being picky. As I said above, if you have a decent test suite you can relax a lot. > warning C4018: '!=' : signed/unsigned mismatch This is usually benign. Say you have an variable in which you store the unsigned return value from a library function. You know the value is always +ve so you make the variable unsigned. The compiler doesn't know the number will always be +ve but it knows signed/unsigned mismatch is a common source of bugs so it reports a warning. A cast would fix the warning but might suggest to the reader that the author wanted to force some kind of conversion. Or it might not. > warning C4028: formal parameter 1 different from declaration Without seeing the code, it's hard to say, but I'd expect this to be an error or a typo. Whether it matters is something else - it could be the signed/unsigned issue above. > warning C4047: 'initializing' : '__int64 (__cdecl *)(struct Mem *)' differs > in levels of indirection from 'char *(__cdecl *)(const char *,char *)' Hard to say without seeing the code. Indirection in C can be quite tricky and is a common source of bugs, but I'd be surprised to see anything like that in SQLite. > warning C4090: 'function' : different 'const' qualifiers This is common when using string library functions. They're declared const because, say, strlen won't alter your data and your pointers are not declared const because they do. Sometimes an error but usually ok. > warning C4113: '__int64 (__cdecl *)(struct Mem *)' differs in parameter > lists from 'void *(__cdecl *)(struct sqlite3 *,void (__cdecl *)(void *,int > ,const char *,const char *,__int64 ),void *)' > warning C4133: 'initializing' : incompatible types - from '__int64 (__cdecl > *)(struct sqlite3_stmt *,int )' to 'double (__cdecl *)(struct sqlite3_stmt > *,int )' Hard to say without seeing the code, but it looks related to the indirection warning above. > warning C4244: '+=' : conversion from '__int64 ' to 'int ', possible loss of > data > warning C4761: integral size mismatch in argument; conversion supplied Common warnings where the compiler has converted between say 16/32 bit ints and 32/64 bit longs. It's OK in one direction but it may not be OK in the other, so the compiler warns and it's up to you to check. If the int/long variable only holds small numbers it's not significant but the compiler can't tell what numbers will be stored and so it's back to you. This explanation is brief and fairly rushed so may it not be completely rigorous in places but I hope it helps a bit. Martin ---------------------------------------------------------------------------- - To unsubscribe, send email to [EMAIL PROTECTED] ---------------------------------------------------------------------------- - ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
