Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nicolas Williams wrote: > Oh, I think you meant that the L suffix would break on anything other > than LP64 or ILP64 models. Correct. L means long. On platforms where long is 32 bits, shifting a long value by more than 32 bits will give zero. > I'm not entirely sure of the use of the L > suffix, and perhaps that would be a problem. It would on all platforms in 32 bit mode, and those 64 bit platforms that are P64 such as Windows. There is a LL suffix for 64 bit constants (ie long long) but it isn't universally available. > If you can't find a > constant that works equally well in ILP32 and LP64 then you can use > #ifdefs. But I think that it is possible to have such a constant > without causing compiler warnings And that is exactly what the case was. It is only your compiler that whined! (As a general rule the compilers aren't too good at distinguishing between code that knows what it is doing when mixing different sizes and code that is "broken" when doing so. "broken" means unintentionally losing or retaining portions of the values being used.) > (for one, you can have the literal constant, in decimal). You can't. If a value is too large then the compiler will either error or truncate the most significant part. You can stop the truncation by having the LL (or ULL) suffixes but that isn't standard/portable enough. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrDpFkACgkQmOOfHg372QRwDACfebSMj2NzQNFFJQuC1RnEUWu6 0WYAoMq2qZm3vLMhadlMQhurfMe0J8lP =arsu -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
On Tue, Sep 29, 2009 at 05:28:39PM -0700, Roger Binns wrote: > Nicolas Williams wrote: > > On Tue, Sep 29, 2009 at 11:21:30AM -0700, Roger Binns wrote: > >> Nicolas Williams wrote: > >>> If you move the cast to the left the warning should go away: > >>> ((sqlite3_int64)(1L<<63)) > >> And this is why making warnings go away leads to bugs. The replacement > >> above will only work if sizeof(long)==sizeof(long long) which is not the > >> case on Windows in 64 bit mode or in 32 bit mode in general on any > >> platform. > > > > Where is long long entering the picture here? > > Really? The cast is to a 64 bit quantity. Pretty much every compiler uses > 'long long' to represent a 64 bit quantity (even in 32 bit mode), although > some also have __int64 and others int64_t depending on age and standards > compliance. Oh, I think you meant that the L suffix would break on anything other than LP64 or ILP64 models. I'm not entirely sure of the use of the L suffix, and perhaps that would be a problem. If you can't find a constant that works equally well in ILP32 and LP64 then you can use #ifdefs. But I think that it is possible to have such a constant without causing compiler warnings (for one, you can have the literal constant, in decimal). > Another example of compilers whining is gcc saying that in one part of the > code, a parameter to memset could be zero (which usually indicates a > programming error). Except the compiler is wrong as human inspection > proves. Just because a warning is present does not mean it is right or that > the compiler is perfect. Hiding these warnings is even more dangerous > because it obfuscates the original intention of the code. (This is why a > universal no warnings policy can hurt.) Indeed, and I've expressed agreement on that. > Demonstrate the code is wrong functionality (ie tests are broken) or that it > isn't written in a standards compliant way :-) The compiler warnings could > help point to those locations. In this case, there's no problem with ignoring this warning. Nico -- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nicolas Williams wrote: > On Tue, Sep 29, 2009 at 11:21:30AM -0700, Roger Binns wrote: >> Nicolas Williams wrote: >>> If you move the cast to the left the warning should go away: >>> ((sqlite3_int64)(1L<<63)) >> And this is why making warnings go away leads to bugs. The replacement >> above will only work if sizeof(long)==sizeof(long long) which is not the >> case on Windows in 64 bit mode or in 32 bit mode in general on any platform. > > Where is long long entering the picture here? Really? The cast is to a 64 bit quantity. Pretty much every compiler uses 'long long' to represent a 64 bit quantity (even in 32 bit mode), although some also have __int64 and others int64_t depending on age and standards compliance. Another example of compilers whining is gcc saying that in one part of the code, a parameter to memset could be zero (which usually indicates a programming error). Except the compiler is wrong as human inspection proves. Just because a warning is present does not mean it is right or that the compiler is perfect. Hiding these warnings is even more dangerous because it obfuscates the original intention of the code. (This is why a universal no warnings policy can hurt.) Demonstrate the code is wrong functionality (ie tests are broken) or that it isn't written in a standards compliant way :-) The compiler warnings could help point to those locations. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrCpjYACgkQmOOfHg372QScTgCeNILUcfFPq45ehdgfPQb+HdoI D0kAn1AhMylW5G7+rm73rCbWWknAA+Bl =FmBf -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
On Tue, Sep 29, 2009 at 12:05:21PM -0700, Jim Showalter wrote: > Warnings are never harmless--they clutter the build output and > introduce cognitive dissonance when trying to see if a build is clean > or not. > > I worked on a project where they hadn't enabled warnings during > development because it was "too much trouble". When I enabled > warnings, there were more than 14,000 of them, and of course then the > warnings couldn't be addressed because "there were too many of them". > > Zero tolerance for warnings! I mostly agree. There are warnings that one can safely choose to ignore. For example, the Sun Studio lint has a very large number of static analysis options, a few of which I think should be removed (e.g., complaints about constant while loop conditions -- while (1) ... is just too common and useful to complain about, nor is it clear why constant while loop conditions are a bad thing given that for (;;) elicits no complaints). Others you might quibble about in specific projects (e.g., lint complaining about ignored function return values when you don't cast the function return to void). But ignoring all warnings? That's just asking for trouble. That doesn't appear to be what the SQLite3 community is doing though, so I've no real complaint here. In this case I agree that the warnings are harmless. You do have do wonder: why use constant expressions that result in overflow warnings (0x1f<<28) when there are equivalent constant expressions that don't (0xf<<28)? Compiler variations might be a good reason for not using certain constant expressions (e.g., D. R. Hipp's point about the L suffix). I don't really know about compilers other than GCC and Sun Studio, so I'll shut up now :) Nico -- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
On Tue, Sep 29, 2009 at 11:21:30AM -0700, Roger Binns wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Nicolas Williams wrote: > > If you move the cast to the left the warning should go away: > > ((sqlite3_int64)(1L<<63)) > > And this is why making warnings go away leads to bugs. The replacement > above will only work if sizeof(long)==sizeof(long long) which is not the > case on Windows in 64 bit mode or in 32 bit mode in general on any platform. Where is long long entering the picture here? And what of the alternative I gave where the actual most negative value of sqlite3_int64 is used? In any case, you clearly know how to fix the warning safely. Nico -- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
Warnings are never harmless--they clutter the build output and introduce cognitive dissonance when trying to see if a build is clean or not. I worked on a project where they hadn't enabled warnings during development because it was "too much trouble". When I enabled warnings, there were more than 14,000 of them, and of course then the warnings couldn't be addressed because "there were too many of them". Zero tolerance for warnings! - Original Message - From: "D. Richard Hipp" To: "General Discussion of SQLite Database" Sent: Tuesday, September 29, 2009 3:38 AM Subject: Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10 > > On Sep 27, 2009, at 5:28 PM, Dr. David Kirkby wrote: > >> "sqlite3.c", line 18731: warning: integer overflow detected: op >> "<<" >> "sqlite3.c", line 18748: warning: integer overflow detected: op >> "<<" > > Both cases are complaining about a constant: (0x1f<<28)Both are > harmless. > >> "sqlite3.c", line 32546: warning: statement not reached > > Complains about this code: > > /*NOTREACHED*/ > assert( 0 ); > > Harmless. > >> "sqlite3.c", line 69160: warning: integer overflow detected: op >> "<<" > > Complains about this constant: (((sqlite3_int64)1)<<63) Harmless > > All warnings are harmless and will remain unaddressed for now. > Thanks > for the reports, though! > > D. Richard Hipp > d...@hwaci.com > > > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
On Sep 29, 2009, at 2:21 PM, Roger Binns wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Nicolas Williams wrote: >> If you move the cast to the left the warning should go away: >> ((sqlite3_int64)(1L<<63)) > > And this is why making warnings go away leads to bugs. The > replacement > above will only work if sizeof(long)==sizeof(long long) which is not > the > case on Windows in 64 bit mode or in 32 bit mode in general on any > platform. Further: We have had problems with the L suffix in some compilers. We haven't found a portable way to express a 64-bit integer literal. > > Roger > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkrCUCYACgkQmOOfHg372QTvAQCfQaHiApWb0UNFAgleFUnFQfAu > nXkAnRqqCi4MNIllFSuoW0F9FwIz/8Hi > =gmns > -END PGP SIGNATURE- > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users D. Richard Hipp d...@hwaci.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nicolas Williams wrote: > If you move the cast to the left the warning should go away: > ((sqlite3_int64)(1L<<63)) And this is why making warnings go away leads to bugs. The replacement above will only work if sizeof(long)==sizeof(long long) which is not the case on Windows in 64 bit mode or in 32 bit mode in general on any platform. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrCUCYACgkQmOOfHg372QTvAQCfQaHiApWb0UNFAgleFUnFQfAu nXkAnRqqCi4MNIllFSuoW0F9FwIz/8Hi =gmns -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
On Tue, Sep 29, 2009 at 06:38:44AM -0400, D. Richard Hipp wrote: > > On Sep 27, 2009, at 5:28 PM, Dr. David Kirkby wrote: > > > "sqlite3.c", line 18731: warning: integer overflow detected: op "<<" > > "sqlite3.c", line 18748: warning: integer overflow detected: op "<<" > > Both cases are complaining about a constant: (0x1f<<28)Both are > harmless. They are constants, but 0x1f<<28 is being assigned to an unsigned, 32-bit integer variable, so the constant expression does overflow. The compiler is right to warn about that, even you've taken the overflow into account. I take no position on whether these warnings should be fixed. If you don't fix them though, a comment in the source (and an FAQ) would be nice, as it will head off future questions about this. If you do fix it, the fix could be to change the 1f to f, or to put an explicit cast to the type of the variable. Both are arguably dangerous fixes: what if you later change the type of those variables to be u64? I don't think that's likely in this case (varint encoding isn't going to change, is it?), but it's something to consider. If you're willing to use GNU C extensions then you could use typeof() (which Sun Studio 12 does support) in the cast expression, in which case there'd be no danger. > > "sqlite3.c", line 32546: warning: statement not reached > > Complains about this code: > > /*NOTREACHED*/ > assert( 0 ); > > Harmless. Indeed. I'm not sure why the compiler warned about this one (the NOTREACHED comment is for lint, but the compiler ought honor it). I'll ask here how to make that warning go away. > > "sqlite3.c", line 69160: warning: integer overflow detected: op "<<" > > Complains about this constant: (((sqlite3_int64)1)<<63) Harmless That too is a legitimate warning, even if you've taken the overflow into account (the compiler can't know that you did). If you move the cast to the left the warning should go away: ((sqlite3_int64)(1L<<63)), or you could use a constant for the most negative value that sqlite3_int64 can hold ((- 2^63) - 1). Nico -- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
On Sep 27, 2009, at 5:28 PM, Dr. David Kirkby wrote: > "sqlite3.c", line 18731: warning: integer overflow detected: op "<<" > "sqlite3.c", line 18748: warning: integer overflow detected: op "<<" Both cases are complaining about a constant: (0x1f<<28)Both are harmless. > "sqlite3.c", line 32546: warning: statement not reached Complains about this code: /*NOTREACHED*/ assert( 0 ); Harmless. > "sqlite3.c", line 69160: warning: integer overflow detected: op "<<" Complains about this constant: (((sqlite3_int64)1)<<63) Harmless All warnings are harmless and will remain unaddressed for now. Thanks for the reports, though! D. Richard Hipp d...@hwaci.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
D. Richard Hipp wrote: >> Thank you. >> >> I understand you can't fix these warnings since you don't have >> access to >> such machines. Would you like access? If so, I can give you access >> to a >> 16-core Sun T5240 at the university of Washington, with runs Solaris >> 10 >> update 7 (latest version). It also has the Sun compiler installed (not >> quite the latest I must admit), though I could easily change that. >> > > > We probably don't need your compiler to "fix" the warnings. Either > the warnings actually point to bugs, or they do not. If they do, we > will fix the bug. If the do not (the likely case, based on historical > trends) then we will do nothing because warnings are not errors but > misguided efforts to "fix" warnings often introduce errors. > But as it stands now, we cannot even evaluate the warnings to > determine whether or not they are bugs because you haven't told us > what version of SQLite you are attempting to compile so the line > numbers are meaningless. (In a 100,000-line source file, line numbers > shift drastically from day to day.) sqlite 3.6.17 is being used. The only configure option used is --prefix. > We want to know the value of the > following two C preprocessor macros: > > SQLITE_VERSION > SQLITE_SOURCE_ID Tell me how to get them, and I'll tell you what they are. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
On Sep 28, 2009, at 10:15 AM, Dr. David Kirkby wrote: > Roger Binns wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Dr. David Kirkby wrote: >>> "sqlite3.c", line 18731: warning: integer overflow detected: op "<<" >>> "sqlite3.c", line 18748: warning: integer overflow detected: op "<<" >>> "sqlite3.c", line 32546: warning: statement not reached >>> "sqlite3.c", line 69160: warning: integer overflow detected: op "<<" >> >> http://www.sqlite.org/faq.html#q17 >> >> Roger > > Thank you. > > I understand you can't fix these warnings since you don't have > access to > such machines. Would you like access? If so, I can give you access > to a > 16-core Sun T5240 at the university of Washington, with runs Solaris > 10 > update 7 (latest version). It also has the Sun compiler installed (not > quite the latest I must admit), though I could easily change that. > We probably don't need your compiler to "fix" the warnings. Either the warnings actually point to bugs, or they do not. If they do, we will fix the bug. If the do not (the likely case, based on historical trends) then we will do nothing because warnings are not errors but misguided efforts to "fix" warnings often introduce errors. But as it stands now, we cannot even evaluate the warnings to determine whether or not they are bugs because you haven't told us what version of SQLite you are attempting to compile so the line numbers are meaningless. (In a 100,000-line source file, line numbers shift drastically from day to day.) We want to know the value of the following two C preprocessor macros: SQLITE_VERSION SQLITE_SOURCE_ID D. Richard Hipp d...@hwaci.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
Roger Binns wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Dr. David Kirkby wrote: >> "sqlite3.c", line 18731: warning: integer overflow detected: op "<<" >> "sqlite3.c", line 18748: warning: integer overflow detected: op "<<" >> "sqlite3.c", line 32546: warning: statement not reached >> "sqlite3.c", line 69160: warning: integer overflow detected: op "<<" > > http://www.sqlite.org/faq.html#q17 > > Roger Thank you. I understand you can't fix these warnings since you don't have access to such machines. Would you like access? If so, I can give you access to a 16-core Sun T5240 at the university of Washington, with runs Solaris 10 update 7 (latest version). It also has the Sun compiler installed (not quite the latest I must admit), though I could easily change that. Let me know if it's any help. Reply by private email, with your preferred user name. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Compiler warnings with Sun Studio 12.1 on Solaris 10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. David Kirkby wrote: > "sqlite3.c", line 18731: warning: integer overflow detected: op "<<" > "sqlite3.c", line 18748: warning: integer overflow detected: op "<<" > "sqlite3.c", line 32546: warning: statement not reached > "sqlite3.c", line 69160: warning: integer overflow detected: op "<<" http://www.sqlite.org/faq.html#q17 Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkq/4PUACgkQmOOfHg372QRTqwCgtfRSypFXYICYKwBeeMGJjiWp +kEAoLoJ6cc/uR+AYveWEPQu+/VBCDWr =Ee6q -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users