Re: [sqlite] SQLite as a Windows kernel tool
What about these three warnings do you think is a concern? Have you actually looked at the code in question to see if the possibility of data loss is real and unintentional? What makes you think that these warnings are not just a case of the compiler blowing smoke? -- D. Richard Hipp <[EMAIL PROTECTED]> I may be a bit late in the discussion but... Personally I like to use the compilers highest level of warnings - and use "warnings as errors" where possible. If I'm feeling really enthusiastic then I may run Lint over the code. These tools, lint and compiler warnings, are there to help us. Let's assume one warning is a valid one. It's a new one in code someone wrote just recently. It's a warning that is now lost in the noise of the "blowing smoke" warnings. You'll never know because you have tuned the compilers warnings out as simply "blowing smoke". You won't see it until an obscure bug shows it's face...and even when staring at it you won't see it because you don't consider these warnings as errors. Personally I consider an alarm and "alarm" and work to fix them all. Sometimes with compiler options (pragmas in MS compiler), sometimes with lint comments, but mostly by fixing them **right at the time of writing the code in the first place**. It saddens me when I use someone else's code at warning level 3 and warnings as mere warnings as there is the implication that the code has not had that last few ounces of effort put into it. russ.
RE: [sqlite] SQLite as a Windows kernel tool
I'm certainly not diplomatic material. But, what you have said is exactly what I meant. I get more than a little weary of people who take "free" code and whine about it. My belief is if you don't like it, fix it yourself or shut up after your initial "notification" of the issue. As to calling Bill's little company "Mickeysoft", I bought my first PC the month of the introduction and have used Microsoft's products ever since. I think I have earned and paid enough to call Bill's company anything I want. Unfortunately I have watched more that one superior software technology succumb to the steamroller that has become Microsoft. And, it bothers me to once again see marketing exceed over functionality (Anybody old enough to remember IBM and the seven dwarfs?). So, sorry if you don't like my choice of names. Let's not waste any more bandwidth here. If you wish to respond, my email address is in the header Fred > -Original Message- > From: John Stanton [mailto:[EMAIL PROTECTED] > Sent: Monday, October 31, 2005 8:28 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] SQLite as a Windows kernel tool > > > What is important is the implication of the compile warnings. > I agree > that they should not be ignored, but they should be understood. For > example we always take pains to remove all compiler warnings, > even the > innocuous and gratuitous ones, so that "noise" does not hide a > significant warning. > > It should not be too much trouble for you to go through Sqlite and > remove the gratuitous warnings and then investigate any > remaining. It > would be a useful contribution to the cause and does make a > contribution > to "zero defect" quality. > > We find that just indiscriminately casting can do more harm > than good. > Working on the underlying types to achieve consistency is better, > otherwise you end up with a dog's breakfast like the Win32 API. > JS > > Nuno Lucas wrote: > > On 10/31/05, Fred Williams <[EMAIL PROTECTED]> wrote: > > > >>Look I'm certain you mean well, but the rest of us are > pretty busy using > >>one of the best small footprint databases on the planet. > That means we > >>are way too busy to nit-pic a good product to pieces, just > because it > >>won't compile clean using Mickeysoft's latest and greatest. > > > > > > If you forget about "Mickeysoft's latest and greatest" and only > > consider GNU C compiler will that make you change your mind? > > > > gcc 3.3 and 3.4 compile without warnings, but 4.0 is a lot > more picky > > even without -Wall. > > > > For people like me that always enable all warnings, it > makes it a must > > to compile sqlite as a library, because it's a nightmare to use it > > "embebed". > > > > I still love sqlite, it's just a feature request, nothing > more, nothing less. > > > > As an example, I downloaded the preprocessed code, removed > tclsqlite.c, and: > > > > [EMAIL PROTECTED]:~/src/sqlite$ gcc-4.0 *.c > > alter.c: In function 'renameTableFunc': > > alter.c:50: warning: pointer targets in initialization > differ in signedness > > alter.c:61: warning: pointer targets in assignment differ ...
Re: [sqlite] SQLite as a Windows kernel tool
> Look I'm certain you mean well, but the rest of us are pretty busy using > one of the best small footprint databases on the planet. That means we > are way too busy to nit-pic a good product to pieces, just because it > won't compile clean using Mickeysoft's latest and greatest. It's not a "nit-pic[sic]" when one's compiler (and I saw no mention of the compiler vendor in the original poster's note, but I don't have the start of the thread) issues a warning about potentially unsafe behaviour. There's a reason those warnings are issued. Such issues can cause hard to find problems in programs. Code review is a valuable tool in software development. I believe the original poster's intent was to note that if an implicit conversion is correct for that section of code, then what is the down-side of changing those to explicit casts? I'm aware that the time spent chasing them down and analyzing each one is a major task, but I get the impression that the OP doesn't feel qualified to make those changes, otherwise he would have tackled it. I believe he intended to bring the subject to the attention of DRH, in case these are actual problems, not to "whine" about the code base. > us all, and won't come off as such an irritating whiner. As opposed to...? Brad
Re: [sqlite] SQLite as a Windows kernel tool
What is important is the implication of the compile warnings. I agree that they should not be ignored, but they should be understood. For example we always take pains to remove all compiler warnings, even the innocuous and gratuitous ones, so that "noise" does not hide a significant warning. It should not be too much trouble for you to go through Sqlite and remove the gratuitous warnings and then investigate any remaining. It would be a useful contribution to the cause and does make a contribution to "zero defect" quality. We find that just indiscriminately casting can do more harm than good. Working on the underlying types to achieve consistency is better, otherwise you end up with a dog's breakfast like the Win32 API. JS Nuno Lucas wrote: On 10/31/05, Fred Williams <[EMAIL PROTECTED]> wrote: Look I'm certain you mean well, but the rest of us are pretty busy using one of the best small footprint databases on the planet. That means we are way too busy to nit-pic a good product to pieces, just because it won't compile clean using Mickeysoft's latest and greatest. If you forget about "Mickeysoft's latest and greatest" and only consider GNU C compiler will that make you change your mind? gcc 3.3 and 3.4 compile without warnings, but 4.0 is a lot more picky even without -Wall. For people like me that always enable all warnings, it makes it a must to compile sqlite as a library, because it's a nightmare to use it "embebed". I still love sqlite, it's just a feature request, nothing more, nothing less. As an example, I downloaded the preprocessed code, removed tclsqlite.c, and: [EMAIL PROTECTED]:~/src/sqlite$ gcc-4.0 *.c alter.c: In function 'renameTableFunc': alter.c:50: warning: pointer targets in initialization differ in signedness alter.c:61: warning: pointer targets in assignment differ in signedness alter.c:69: warning: pointer targets in passing argument 1 of 'sqlite3GetToken' differ in signedness alter.c: In function 'renameTriggerFunc': alter.c:99: warning: pointer targets in initialization differ in signedness alter.c:111: warning: pointer targets in assignment differ in signedness alter.c:119: warning: pointer targets in passing argument 1 of 'sqlite3GetToken' differ in signedness alter.c: In function 'sqlite3AlterFinishAddColumn': alter.c:445: warning: pointer targets in passing argument 1 of 'sqlite3StrNDup' differ in signedness btree.c: In function 'unlockBtreeIfUnused': btree.c:1537: warning: pointer targets in assignment differ in signedness build.c: In function 'sqlite3NameFromToken': build.c:509: warning: pointer targets in passing argument 1 of 'sqlite3StrNDup' differ in signedness build.c: In function 'identPut': build.c:1173: warning: pointer targets in passing argument 1 of 'sqlite3KeywordCode' differ in signedness build.c: In function 'sqlite3CreateIndex': build.c:2160: warning: pointer targets in assignment differ in signedness build.c:2161: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness build.c: In function 'sqlite3Reindex': build.c:2913: warning: pointer targets in passing argument 3 of 'sqlite3FindCollSeq' differ in signedness date.c: In function 'isDate': date.c:642: warning: pointer targets in passing argument 1 of 'parseDateOrTime' differ in signedness date.c:645: warning: pointer targets in passing argument 1 of 'parseModifier' differ in signedness date.c: In function 'strftimeFunc': date.c:758: warning: pointer targets in initialization differ in signedness expr.c: In function 'sqlite3RegisterExpr': expr.c:238: warning: pointer targets in passing argument 1 of 'atoi' differ in signedness expr.c: In function 'sqlite3ExprAssignVarNumber': expr.c:330: warning: pointer targets in passing argument 1 of 'atoi' differ in signedness expr.c: In function 'sqlite3ExprDup': expr.c:418: warning: pointer targets in passing argument 1 of 'sqlite3StrNDup' differ in signedness expr.c:418: warning: pointer targets in assignment differ in signedness expr.c: In function 'sqlite3TokenCopy': expr.c:435: warning: pointer targets in passing argument 1 of 'sqlite3StrNDup' differ in signedness expr.c:435: warning: pointer targets in assignment differ in signedness expr.c: In function 'sqlite3ExprIsInteger': expr.c:755: warning: pointer targets in passing argument 1 of 'sqlite3GetInt32' differ in signedness expr.c: In function 'nameResolverStep': expr.c:1154: warning: pointer targets in assignment differ in signedness expr.c: In function 'sqlite3CodeSubselect': expr.c:1401: warning: pointer targets in initialization differ in signedness expr.c: In function 'sqlite3ExprCode': expr.c:1477: warning: pointer targets in passing argument 2 of 'codeInteger' differ in signedness expr.c:1485: warning: pointer targets in passing argument 5 of 'sqlite3VdbeOp3' differ in signedness expr.c:1498: warning: pointer targets in assignment differ in signedness expr.c:1510: warning: pointer targets in passing argument 3 of 'sqlite3VdbeChangeP3' differ in signedness
RE: [sqlite] SQLite as a Windows kernel tool
Fred, They are not nit-picking and they "are" actually contributing to the robustness of the application by doing this research. Your anti-Microsoft bigotry does no service to this list at all and is neither a "contribution" or an offer of help. I for one would be keen to see these warnings addressed and I agree with the point made by the original contributor, I'm not familiar enough with the code to be able to make any sensible changes. I would be happy to help in any way I can - all my clients are Windows or Solaris and warnings appear on both of these platforms. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] rg] On Behalf Of Fred Williams Sent: 31 October 2005 05:19 To: sqlite-users@sqlite.org Subject: RE: [sqlite] SQLite as a Windows kernel tool Look I'm certain you mean well, but the rest of us are pretty busy using one of the best small footprint databases on the planet. That means we are way too busy to nit-pic a good product to pieces, just because it won't compile clean using Mickeysoft's latest and greatest. How' bout you go through this buggy code and fix all your concerns then upload it to CVS. That way you would be making a huge contribution to us all, and won't come off as such an irritating whiner. Fred > -Original Message- > From: Dirk Zabel [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 30, 2005 3:59 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] SQLite as a Windows kernel tool > > > [EMAIL PROTECTED] schrieb: > > >Ken & Deb Allen <[EMAIL PROTECTED]> wrote: > > > > > >>vdbeapi.c > >>e:\SQLITE\327\Source\vdbeapi.c(55) : warning C4244: 'return' : > >>conversion from 'i64' to 'int', possible loss of data > >>e:\SQLITE\327\Source\vdbeapi.c(195) : warning C4244: '=' : > conversion > >>from 'double' to 'i64', possible loss of data > >>e:\SQLITE\327\Source\vdbeapi.c(232) : warning C4244: '=' : > conversion > >>from 'double' to 'u64', possible loss of data > >> > >> > >> > > > >What about these three warnings do you think is a concern? > >Have you actually looked at the code in question to see > >if the possibility of data loss is real and unintentional? > >What makes you think that these warnings are not just a case > >of the compiler blowing smoke? > > > >-- > >D. Richard Hipp <[EMAIL PROTECTED]> > > > > > > > > > These concerns seem to me not unfounded. > Just looking at the three cited positions in vdbeapi.c, i find: > Line 55: the conversion i64->int might be ok, depends on the > runtime-argument pVal. I am not sure. > Line 195: this conversion double->i64 is done by intent; > giving the > number of nanoseconds since midnight. I think a > cast to int64 would be appropriate to express this intent. I comment > might help to see the reason, but on the other hand the code > looks quite > obvious here. > Line 232: same conversion, insofar applies the same remark. > But what if > between the computation of startTime and rNow midnight > occurred? I guess > there would be a wrap-around - an error in my point of view. > > I don't think it's a good idea to assume a compiler warning > about type > conversions are "blowing smoke". At least, they should be > eliminated in > order not to cover messages about real quirks. > > Regards > Dirk >
Re: [sqlite] SQLite as a Windows kernel tool
I have been silently reading the conversation, but I have to reply on this latest message. - Original Message - From: "Fred Williams" <[EMAIL PROTECTED]> Look I'm certain you mean well, but the rest of us are pretty busy using one of the best small footprint databases on the planet. That means we are way too busy to nit-pic a good product to pieces, just because it won't compile clean using Mickeysoft's latest and greatest. This is unfair. As stated it will actually compile. There are just warnings to indicate data loss might occur. Which we all know happens if you convert int64 to a char for example (Which has nothing todo with the fact that it is a Microsoft compiler, or Mickeysoft as you call it). The original poster is (imho) just looking for clarification if these possible problem spots are working as they are supposed to, on all platforms. Isn't this a good discussion to have? To make sure the codebase is at the best quality it can be? I thought we would all benefit from such a thing, guess you don't agree. How' bout you go through this buggy code and fix all your concerns then upload it to CVS. That way you would be making a huge contribution to This would mean the original poster has to know every in and out of the SQLite code. Fixing something that seems obvious might break something else. Since the original question was about whether the mentioned warnings are real I doubt the poster has the knowledge to fix it himself and no if there are any consequences or not. us all, and won't come off as such an irritating whiner. This is just completely rude and uncalled for. If you don't want to "waste your time" discussing a genuine concern, then why bother replying at all? Regards, Rob Lohman p.s. funny how you are using "Mickeysoft" Outlook
Re: [sqlite] SQLite as a Windows kernel tool
On 10/31/05, Fred Williams <[EMAIL PROTECTED]> wrote: > Look I'm certain you mean well, but the rest of us are pretty busy using > one of the best small footprint databases on the planet. That means we > are way too busy to nit-pic a good product to pieces, just because it > won't compile clean using Mickeysoft's latest and greatest. If you forget about "Mickeysoft's latest and greatest" and only consider GNU C compiler will that make you change your mind? gcc 3.3 and 3.4 compile without warnings, but 4.0 is a lot more picky even without -Wall. For people like me that always enable all warnings, it makes it a must to compile sqlite as a library, because it's a nightmare to use it "embebed". I still love sqlite, it's just a feature request, nothing more, nothing less. As an example, I downloaded the preprocessed code, removed tclsqlite.c, and: [EMAIL PROTECTED]:~/src/sqlite$ gcc-4.0 *.c alter.c: In function 'renameTableFunc': alter.c:50: warning: pointer targets in initialization differ in signedness alter.c:61: warning: pointer targets in assignment differ in signedness alter.c:69: warning: pointer targets in passing argument 1 of 'sqlite3GetToken' differ in signedness alter.c: In function 'renameTriggerFunc': alter.c:99: warning: pointer targets in initialization differ in signedness alter.c:111: warning: pointer targets in assignment differ in signedness alter.c:119: warning: pointer targets in passing argument 1 of 'sqlite3GetToken' differ in signedness alter.c: In function 'sqlite3AlterFinishAddColumn': alter.c:445: warning: pointer targets in passing argument 1 of 'sqlite3StrNDup' differ in signedness btree.c: In function 'unlockBtreeIfUnused': btree.c:1537: warning: pointer targets in assignment differ in signedness build.c: In function 'sqlite3NameFromToken': build.c:509: warning: pointer targets in passing argument 1 of 'sqlite3StrNDup' differ in signedness build.c: In function 'identPut': build.c:1173: warning: pointer targets in passing argument 1 of 'sqlite3KeywordCode' differ in signedness build.c: In function 'sqlite3CreateIndex': build.c:2160: warning: pointer targets in assignment differ in signedness build.c:2161: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness build.c: In function 'sqlite3Reindex': build.c:2913: warning: pointer targets in passing argument 3 of 'sqlite3FindCollSeq' differ in signedness date.c: In function 'isDate': date.c:642: warning: pointer targets in passing argument 1 of 'parseDateOrTime' differ in signedness date.c:645: warning: pointer targets in passing argument 1 of 'parseModifier' differ in signedness date.c: In function 'strftimeFunc': date.c:758: warning: pointer targets in initialization differ in signedness expr.c: In function 'sqlite3RegisterExpr': expr.c:238: warning: pointer targets in passing argument 1 of 'atoi' differ in signedness expr.c: In function 'sqlite3ExprAssignVarNumber': expr.c:330: warning: pointer targets in passing argument 1 of 'atoi' differ in signedness expr.c: In function 'sqlite3ExprDup': expr.c:418: warning: pointer targets in passing argument 1 of 'sqlite3StrNDup' differ in signedness expr.c:418: warning: pointer targets in assignment differ in signedness expr.c: In function 'sqlite3TokenCopy': expr.c:435: warning: pointer targets in passing argument 1 of 'sqlite3StrNDup' differ in signedness expr.c:435: warning: pointer targets in assignment differ in signedness expr.c: In function 'sqlite3ExprIsInteger': expr.c:755: warning: pointer targets in passing argument 1 of 'sqlite3GetInt32' differ in signedness expr.c: In function 'nameResolverStep': expr.c:1154: warning: pointer targets in assignment differ in signedness expr.c: In function 'sqlite3CodeSubselect': expr.c:1401: warning: pointer targets in initialization differ in signedness expr.c: In function 'sqlite3ExprCode': expr.c:1477: warning: pointer targets in passing argument 2 of 'codeInteger' differ in signedness expr.c:1485: warning: pointer targets in passing argument 5 of 'sqlite3VdbeOp3' differ in signedness expr.c:1498: warning: pointer targets in assignment differ in signedness expr.c:1510: warning: pointer targets in passing argument 3 of 'sqlite3VdbeChangeP3' differ in signedness expr.c:1632: warning: pointer targets in assignment differ in signedness expr.c:1766: warning: pointer targets in passing argument 5 of 'sqlite3VdbeOp3' differ in signedness expr.c: In function 'sqlite3ExprCompare': expr.c:2059: warning: pointer targets in passing argument 1 of 'sqlite3StrNICmp' differ in signedness expr.c:2059: warning: pointer targets in passing argument 2 of 'sqlite3StrNICmp' differ in signedness expr.c: In function 'analyzeAggregate': expr.c:2191: warning: pointer targets in passing argument 2 of 'sqlite3FindFunction' differ in signedness func.c: In function 'lengthFunc': func.c:104: warning: pointer targets in initialization differ in signedness func.c: In function 'substrFunc': func.c:155: warning: pointer targets in assignment
Re: [sqlite] SQLite as a Windows kernel tool
[EMAIL PROTECTED] schrieb: Ken & Deb Allen <[EMAIL PROTECTED]> wrote: vdbeapi.c e:\SQLITE\327\Source\vdbeapi.c(55) : warning C4244: 'return' : conversion from 'i64' to 'int', possible loss of data e:\SQLITE\327\Source\vdbeapi.c(195) : warning C4244: '=' : conversion from 'double' to 'i64', possible loss of data e:\SQLITE\327\Source\vdbeapi.c(232) : warning C4244: '=' : conversion from 'double' to 'u64', possible loss of data What about these three warnings do you think is a concern? Have you actually looked at the code in question to see if the possibility of data loss is real and unintentional? What makes you think that these warnings are not just a case of the compiler blowing smoke? -- D. Richard Hipp <[EMAIL PROTECTED]> These concerns seem to me not unfounded. Just looking at the three cited positions in vdbeapi.c, i find: Line 55: the conversion i64->int might be ok, depends on the runtime-argument pVal. I am not sure. Line 195: this conversion double->i64 is done by intent; giving the number of nanoseconds since midnight. I think a cast to int64 would be appropriate to express this intent. I comment might help to see the reason, but on the other hand the code looks quite obvious here. Line 232: same conversion, insofar applies the same remark. But what if between the computation of startTime and rNow midnight occurred? I guess there would be a wrap-around - an error in my point of view. I don't think it's a good idea to assume a compiler warning about type conversions are "blowing smoke". At least, they should be eliminated in order not to cover messages about real quirks. Regards Dirk
Re: [sqlite] SQLite as a Windows kernel tool
This has been the whole point of my emails -- I am not sufficiently familiar with the actual code details for me to make that determination. There are no comments to indicate whether the implicit cast is 'safe' or not. I know that some casts are a simple fact of life, especially in UN!X based code, where the runtime or system API returns character data in an integer, but the conversion of a 64-bit to an 32-bit value is a different case. If I could have determined the context to a reasonable degree of certainty, it would be one thing, but not being able to determine the actual intent raises some concerns. -ken On 29-Oct-05, at 12:56 PM, [EMAIL PROTECTED] wrote: Ken & Deb Allen <[EMAIL PROTECTED]> wrote: vdbeapi.c e:\SQLITE\327\Source\vdbeapi.c(55) : warning C4244: 'return' : conversion from 'i64' to 'int', possible loss of data e:\SQLITE\327\Source\vdbeapi.c(195) : warning C4244: '=' : conversion from 'double' to 'i64', possible loss of data e:\SQLITE\327\Source\vdbeapi.c(232) : warning C4244: '=' : conversion from 'double' to 'u64', possible loss of data What about these three warnings do you think is a concern? Have you actually looked at the code in question to see if the possibility of data loss is real and unintentional? What makes you think that these warnings are not just a case of the compiler blowing smoke? -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] SQLite as a Windows kernel tool
Ken & Deb Allen wrote: I had a quick look at some of the code, but I am not certain whether all, or even most, of these warnings can be safely ignored or not. I tried modifying the code to add explicit casts to eliminate all of the warnings, which worked, but I do not know whether or not the resulting code contains runtime errors or not (specifically as a result of data loss at runtime or improper comparison logic). You might want to look at ticket 1255 (http://www.sqlite.org/cvstrac/tktview?tn=1255,2).
[sqlite] SQLite as a Windows kernel tool
I have been toying with the idea of checking whether or not I can use SQLite in a Windows device driver as its database. I am working on an existing product that is implemented as a series of Windows device drivers, filter drivers and even a file system driver. The file system driver manages a dedicated disk partition that contains an NTFS file system and a series of files (some flat files and some Btree files) that serve as the database. The code that manages this database is quite old and has been heavily modified several times, but the code is not well structured and contains a number of architectural features that act as hinderances to modifications and performance enhancements. From the beginning it was clear to me that several issues would be greatly minimized or even eliminated if we could use some form of a relational database management package instead of the home-grown file management code, but there do not seem to be any database packages that are available to kernel code. As part of another effort we looked at using SQLite, and performed a number of tests to that end. When I discovered that all of the source code was available, it seemed that we may be able to 'port' the code for use within out file system driver, either as a kernel DLL or directly compiled into the existing component. A number of features would have to be modified, such as the use of malloc() and free() calls, which would need to be replaced with the appropriate calls to kernel routines (if not the development of an extra set of routines for such dynamic memory usage), but we were hopeful. I had used the Visual C++ 6 compiler (in C mode) to compile the existing SQLite source for use in user space, and that was not much of a problem, but the DDK (kernel) compiler was a modified version of the Visual C++ 7 compiler, and a number of compilation features are quite different when compiling code into the kernel as opposed as into user space. We had a number of problems with compiling the SQLite code as part of our kernel build, and so I decided to attempt to compile the latest source code for user space using the Visual C++ 7 compiler (Visual Studio .Net 2003). I have an HTML file that is the output from this attempt, which lists 193 compiler warnings (the code actually runs) based on the 3.2.7 version of the SQLite source code. This mail list does not permit me to attach the file (message rejected as too large), but if anyone wants to see it I can send it to you. The vast majority of the warnings are related to either unsafe implicit data type conversions or signed and unsigned comparison operations. Some of these are not unreasonable, such as a complaint about conversion from "size_t" to "int", which should be the same size objects, but others definitely appear to be significant, such as an implicit conversion from "i64" or "u64" to int, which is a legitimate concern. Some of the signed/unsigned comparisons are also suspect (is an unsigned integer value of 0x81230001 greater than or less than a signed integer value of 0x0001? -- hint, as a signed value the former is a negative number, but as an unsigned it is not). Some of these warnings are simply the compiler being extremely (and appropriately) cautious, but some of them truly do look like odd coding. Why should the code unconditionally and implicitly assign a 64-bit integer value into a 32-bit integer variable? If the conditions under which this is done are such that there can be no loss of data, then there should be a comment explaining this, and the cast should be explicit to enforce that this is expected. Unfortunately, there are no such comments and not all of the implicit casts have a clear context when simply examining isolated lines of code. I had a quick look at some of the code, but I am not certain whether all, or even most, of these warnings can be safely ignored or not. I tried modifying the code to add explicit casts to eliminate all of the warnings, which worked, but I do not know whether or not the resulting code contains runtime errors or not (specifically as a result of data loss at runtime or improper comparison logic). Could someone have a look at some of these and provide some opinions? I know that the coding style used for SQLite is what I have heard referred to as "minimal C", but should the code not be commented concerning such conversions, and the conversion be made explicit? -ken
