SQLite as a Windows kernel tool

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

SQLite as a Windows kernel tool

Ken & Deb Allen
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 0x00000001? -- 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
Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Windows kernel tool

Joel Lucsy
The default for VC7 projects is to check for 64bit portability issues.
This is an option in the settings for the project. If you know your
system is strictly 32bit, then turn it off and I bet quite a number of
warnings would disappear.

--
Joel Lucsy
"The dinosaurs became extinct because they didn't have a space
program." -- Larry Niven
Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Windows kernel tool

Eric Bohlman
In reply to this post by Ken & Deb Allen
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).
Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Windows kernel tool

Ken & Deb Allen
This is missing the point. I do not want to suppress the warning  
message itself, I am interested in removing potential errors from the  
code. I am well aware that using PRAGMAs can eliminate the display of  
an error or warning message, but they do not correct the code.

It is inherently unsafe to assign the contents of a 64-bit variable  
to the contents of a 'char' (8-bit) variable due to the loss of  
data,  and this is what the warning is about. If this assignment is  
truly intended and considered 'safe' in the context of that line of  
code, then the code should be written to avoid the warning: performa  
an explicit cast, possibly after masking off all but the desired byte.

The same argument holds for the signed/unsigned comparisons.

Leaving this code in place, even with the use of the PRAGMAs to  
suppress the display of the warning messages, leaves the resolution  
of the issue to the whim of the compiler being used and the mode in  
which it is being used. This means that the machine code that is  
generated by various compilers may differ, which may lead to runtime  
problems that are next to impossible to track down. I know, I have  
been down this road before with "pure C" code that compiled  
differently under the SunOS, VMS and HPUX operating systems, and the  
source of the problem turned out to be implicit conversions that were  
treated subtly different by the different compilers and processor  
types. Correcting the code to use explicit conversions permitted the  
runtime code on all three systems to behave in the same manner, and  
eliminated the runtime errors. In at least one case the code was not  
simply converted from implicit to explicit casting, as the code was  
actually found to contain an obscure logic error that had been hidden  
since the main system used for testing dealt with the implicit cast  
in a manner that did not create a problem for most data values. When  
the context of the cast was examined (and it was the assignment of a  
32-bit variable to a char variable), it was determined that we should  
have been doing something different in some cases.

I raised this issue, not because I am concerned with the aesthetics  
of the compilation output, and not because I am too lazy to suppress  
those messages, but because I am concerned over whether the code  
being generated from these implicit casts is always correct and  
intended. As I modified the code to convert the offending lines of  
code into explicit casts to eliminate the warnings, in some cases I  
began to question whether or not the direct cast was 'safe' in the  
context of the logic of the code or not. Just as an example, please  
see the small excerpt below. Given that these are coming from the  
virtual database engine itself, this causes me some concern.

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

It seems appropriate that each of these warnings should be examined  
in turn and a decision made on whether they are safe or intended or  
if the logic needs to be enhanced. If the cast is safe and intended,  
then the code should be modified to avoid the warning, not have the  
warning suppressed universally.

I can provide the entire log file (attaching it to the email, even  
compressed) caused the message to be rejected as it exceeded the 3000  
byte limit for the mail list.

-ken

On 29-Oct-05, at 2:31 AM, Eric Bohlman wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Windows kernel tool

D. Richard Hipp
In reply to this post by Ken & Deb Allen
Ken & Deb Allen <[hidden email]> 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 <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Windows kernel tool

Ken & Deb Allen
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, [hidden email] wrote:

> Ken & Deb Allen <[hidden email]> 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 <[hidden email]>
>

Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Windows kernel tool

Dirk Zabel
In reply to this post by D. Richard Hipp
[hidden email] schrieb:

>Ken & Deb Allen <[hidden email]> 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 <[hidden email]>
>
>
>  
>
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

Reply | Threaded
Open this post in threaded view
|

RE: SQLite as a Windows kernel tool

Fred Williams
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:[hidden email]]
> Sent: Sunday, October 30, 2005 3:59 PM
> To: [hidden email]
> Subject: Re: [sqlite] SQLite as a Windows kernel tool
>
>
> [hidden email] schrieb:
>
> >Ken & Deb Allen <[hidden email]> 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 <[hidden email]>
> >
> >
> >
> >
> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Windows kernel tool

Nuno Lucas-2
On 10/31/05, Fred Williams <[hidden email]> 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:

lucas@ubu:~/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 differ in signedness
func.c: In function 'upperFunc':
func.c:213: warning: pointer targets in passing argument 1 of 'strcpy'
differ in signedness
func.c:213: warning: pointer targets in passing argument 2 of 'strcpy'
differ in signedness
func.c:217: warning: pointer targets in passing argument 2 of
'sqlite3_result_text' differ in signedness
func.c: In function 'lowerFunc':
func.c:226: warning: pointer targets in passing argument 1 of 'strcpy'
differ in signedness
func.c:226: warning: pointer targets in passing argument 2 of 'strcpy'
differ in signedness
func.c:230: warning: pointer targets in passing argument 2 of
'sqlite3_result_text' differ in signedness
func.c: In function 'likeFunc':
func.c:498: warning: pointer targets in passing argument 1 of
'sqlite3utf8CharLen' differ in signedness
func.c: In function 'quoteFunc':
func.c:595: warning: pointer targets in initialization differ in signedness
func.c: In function 'sqlite3IsLikeFunction':
func.c:1103: warning: pointer targets in passing argument 2 of
'sqlite3FindFunction' differ in signedness
main.c: In function 'sqlite3_errmsg':
main.c:644: warning: pointer targets in assignment differ in signedness
pager.c: In function 'pager_playback_one_page':
pager.c:1012: warning: pointer targets in passing argument 3 of
'pager_cksum' differ in signedness
parse.y: In function 'yy_reduce':
parse.y:241: warning: pointer targets in passing argument 1 of 'atoi'
differ in signedness
parse.y:242: warning: pointer targets in passing argument 1 of 'atoi'
differ in signedness
parse.y:275: warning: pointer targets in passing argument 2 of
'sqlite3AddCollateType' differ in signedness
parse.y:885: warning: pointer targets in passing argument 2 of
'sqlite3LocateCollSeq' differ in signedness
parse.y:893: warning: pointer targets in passing argument 2 of
'sqlite3LocateCollSeq' differ in signedness
pragma.c: In function 'getSafetyLevel':
pragma.c:47: warning: pointer targets in passing argument 1 of 'atoi'
differ in signedness
pragma.c:49: warning: pointer targets in passing argument 1 of
'strlen' differ in signedness
pragma.c:51: warning: pointer targets in passing argument 2 of
'sqlite3StrNICmp' differ in signedness
pragma.c: In function 'flagPragma':
pragma.c:169: warning: pointer targets in passing argument 1 of
'getBoolean' differ in signedness
pragma.c: In function 'sqlite3Pragma':
pragma.c:322: warning: pointer targets in passing argument 1 of
'getBoolean' differ in signedness
pragma.c:430: warning: pointer targets in passing argument 1 of
'getSafetyLevel' differ in signedness
pragma.c:621: warning: pointer targets in passing argument 1 of
'getBoolean' differ in signedness
printf.c: In function 'vxprintf':
printf.c:628: warning: pointer targets in passing argument 2 of 'func'
differ in signedness
select.c: In function 'sqlite3JoinType':
select.c:112: warning: pointer targets in passing argument 1 of
'sqlite3StrNICmp' differ in signedness
select.c: In function 'setToken':
select.c:157: warning: pointer targets in assignment differ in signedness
select.c: In function 'keyInfoFromExprList':
select.c:625: warning: pointer targets in assignment differ in signedness
select.c: In function 'generateColumnNames':
select.c:869: warning: pointer targets in passing argument 3 of
'sqlite3VdbeSetColName' differ in signedness
select.c:882: warning: pointer targets in passing argument 3 of
'sqlite3VdbeSetColName' differ in signedness
select.c: In function 'flattenSubquery':
select.c:2088: warning: pointer targets in passing argument 1 of
'sqlite3StrNDup' differ in signedness
select.c: In function 'simpleMinMaxQuery':
select.c:2187: warning: pointer targets in passing argument 1 of
'sqlite3StrNICmp' differ in signedness
select.c:2189: warning: pointer targets in passing argument 1 of
'sqlite3StrNICmp' differ in signedness
shell.c: In function 'output_csv':
shell.c:355: warning: pointer targets in passing argument 1 of
'isNumber' differ in signedness
shell.c: In function 'callback':
shell.c:523: warning: pointer targets in passing argument 1 of
'isNumber' differ in signedness
shell.c: In function 'dump_callback':
shell.c:694: warning: pointer targets in passing argument 2 of
'appendText' differ in signedness
tokenize.c: In function 'sqlite3RunParser':
tokenize.c:360: warning: pointer targets in assignment differ in signedness
trigger.c: In function 'sqlite3FinishTrigger':
trigger.c:240: warning: pointer targets in passing argument 3 of
'sqlite3VdbeChangeP3' differ in signedness
trigger.c: In function 'sqlitePersistTriggerStep':
trigger.c:281: warning: pointer targets in passing argument 1 of
'sqlite3StrNDup' differ in signedness
trigger.c:281: warning: pointer targets in assignment differ in signedness
trigger.c: In function 'targetSrcList':
trigger.c:623: warning: pointer targets in assignment differ in signedness
trigger.c:624: warning: pointer targets in passing argument 1 of
'strlen' differ in signedness
utf.c: In function 'sqlite3VdbeMemTranslate':
utf.c:275: warning: pointer targets in assignment differ in signedness
utf.c:311: warning: pointer targets in assignment differ in signedness
utf.c:363: warning: pointer targets in assignment differ in signedness
utf.c:368: warning: pointer targets in assignment differ in signedness
vacuum.c: In function 'execExecSql':
vacuum.c:61: warning: pointer targets in passing argument 2 of
'execSql' differ in signedness
vdbeapi.c: In function 'sqlite3_value_text':
vdbeapi.c:61: warning: pointer targets in return differ in signedness
vdbeaux.c: In function 'sqlite3VdbeIdxRowid':
vdbeaux.c:1735: warning: pointer targets in passing argument 1 of
'sqlite3GetVarint32' differ in signedness
vdbeaux.c:1736: warning: pointer targets in passing argument 1 of
'sqlite3GetVarint32' differ in signedness
vdbeaux.c:1738: warning: pointer targets in passing argument 1 of
'sqlite3VdbeSerialGet' differ in signedness
vdbeaux.c: In function 'sqlite3VdbeIdxKeyCompare':
vdbeaux.c:1774: warning: pointer targets in passing argument 2 of
'sqlite3VdbeIdxRowidLen' differ in signedness
vdbe.c: In function 'sqlite3VdbeExec':
vdbe.c:1873: warning: pointer targets in assignment differ in signedness
vdbe.c:1940: warning: pointer targets in assignment differ in signedness
vdbe.c:1940: warning: pointer targets in assignment differ in signedness
vdbe.c:1945: warning: pointer targets in passing argument 1 of
'sqlite3GetVarint32' differ in signedness
vdbe.c:1972: warning: pointer targets in passing argument 1 of
'sqlite3GetVarint32' differ in signedness
vdbe.c:2026: warning: pointer targets in passing argument 1 of
'sqlite3VdbeSerialGet' differ in signedness
vdbe.c:2189: warning: pointer targets in assignment differ in signedness
vdbe.c:2223: warning: pointer targets in assignment differ in signedness
vdbe.c:2920: warning: pointer targets in passing argument 2 of
'sqlite3VdbeIdxRowidLen' differ in signedness
vdbe.c:2937: warning: pointer targets in passing argument 3 of
'sqlite3VdbeIdxKeyCompare' differ in signedness
vdbe.c:3710: warning: pointer targets in passing argument 3 of
'sqlite3VdbeIdxKeyCompare' differ in signedness
vdbe.c:3748: warning: pointer targets in passing argument 1 of
'sqlite3GetVarint32' differ in signedness
vdbe.c:3750: warning: pointer targets in passing argument 1 of
'sqlite3GetVarint32' differ in signedness
vdbemem.c: In function 'sqlite3VdbeMemDynamicify':
vdbemem.c:76: warning: pointer targets in assignment differ in signedness
vdbemem.c: In function 'sqlite3VdbeMemMakeWriteable':
vdbemem.c:96: warning: pointer targets in assignment differ in signedness
vdbemem.c:109: warning: pointer targets in assignment differ in signedness
vdbemem.c: In function 'sqlite3VdbeMemStringify':
vdbemem.c:165: warning: pointer targets in initialization differ in signedness
vdbemem.c:177: warning: pointer targets in passing argument 2 of
'sqlite3_snprintf' differ in signedness
vdbemem.c:180: warning: pointer targets in passing argument 2 of
'sqlite3_snprintf' differ in signedness
vdbemem.c:182: warning: pointer targets in passing argument 1 of
'strlen' differ in signedness
vdbemem.c:183: warning: pointer targets in assignment differ in signedness
vdbemem.c: In function 'sqlite3ValueFromExpr':
vdbemem.c:769: warning: pointer targets in passing argument 1 of
'sqlite3StrNDup' differ in signedness
vdbemem.c:789: warning: pointer targets in passing argument 1 of
'sqlite3StrNDup' differ in signedness
where.c: In function 'isLikeOrGlob':
where.c:514: warning: pointer targets in assignment differ in signedness
Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Windows kernel tool

Rob Lohman
In reply to this post by Fred Williams
I have been silently reading the conversation, but I have
to reply on this latest message.

> ----- Original Message -----
> From: "Fred Williams" <[hidden email]>
> 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....

Reply | Threaded
Open this post in threaded view
|

RE: SQLite as a Windows kernel tool

Steve O'Hara
In reply to this post by Ken & Deb Allen
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: sqlite-users-return-8644-sohara=[hidden email]
[mailto:sqlite-users-return-8644-sohara=[hidden email]
rg] On Behalf Of Fred Williams
Sent: 31 October 2005 05:19
To: [hidden email]
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:[hidden email]]
> Sent: Sunday, October 30, 2005 3:59 PM
> To: [hidden email]
> Subject: Re: [sqlite] SQLite as a Windows kernel tool
>
>
> [hidden email] schrieb:
>
> >Ken & Deb Allen <[hidden email]> 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 <[hidden email]>
> >
> >
> >
> >
> 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
>



Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Windows kernel tool

John Stanton-3
In reply to this post by Nuno Lucas-2
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 <[hidden email]> 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:
>
> lucas@ubu:~/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 differ in signedness
> func.c: In function 'upperFunc':
> func.c:213: warning: pointer targets in passing argument 1 of 'strcpy'
> differ in signedness
> func.c:213: warning: pointer targets in passing argument 2 of 'strcpy'
> differ in signedness
> func.c:217: warning: pointer targets in passing argument 2 of
> 'sqlite3_result_text' differ in signedness
> func.c: In function 'lowerFunc':
> func.c:226: warning: pointer targets in passing argument 1 of 'strcpy'
> differ in signedness
> func.c:226: warning: pointer targets in passing argument 2 of 'strcpy'
> differ in signedness
> func.c:230: warning: pointer targets in passing argument 2 of
> 'sqlite3_result_text' differ in signedness
> func.c: In function 'likeFunc':
> func.c:498: warning: pointer targets in passing argument 1 of
> 'sqlite3utf8CharLen' differ in signedness
> func.c: In function 'quoteFunc':
> func.c:595: warning: pointer targets in initialization differ in signedness
> func.c: In function 'sqlite3IsLikeFunction':
> func.c:1103: warning: pointer targets in passing argument 2 of
> 'sqlite3FindFunction' differ in signedness
> main.c: In function 'sqlite3_errmsg':
> main.c:644: warning: pointer targets in assignment differ in signedness
> pager.c: In function 'pager_playback_one_page':
> pager.c:1012: warning: pointer targets in passing argument 3 of
> 'pager_cksum' differ in signedness
> parse.y: In function 'yy_reduce':
> parse.y:241: warning: pointer targets in passing argument 1 of 'atoi'
> differ in signedness
> parse.y:242: warning: pointer targets in passing argument 1 of 'atoi'
> differ in signedness
> parse.y:275: warning: pointer targets in passing argument 2 of
> 'sqlite3AddCollateType' differ in signedness
> parse.y:885: warning: pointer targets in passing argument 2 of
> 'sqlite3LocateCollSeq' differ in signedness
> parse.y:893: warning: pointer targets in passing argument 2 of
> 'sqlite3LocateCollSeq' differ in signedness
> pragma.c: In function 'getSafetyLevel':
> pragma.c:47: warning: pointer targets in passing argument 1 of 'atoi'
> differ in signedness
> pragma.c:49: warning: pointer targets in passing argument 1 of
> 'strlen' differ in signedness
> pragma.c:51: warning: pointer targets in passing argument 2 of
> 'sqlite3StrNICmp' differ in signedness
> pragma.c: In function 'flagPragma':
> pragma.c:169: warning: pointer targets in passing argument 1 of
> 'getBoolean' differ in signedness
> pragma.c: In function 'sqlite3Pragma':
> pragma.c:322: warning: pointer targets in passing argument 1 of
> 'getBoolean' differ in signedness
> pragma.c:430: warning: pointer targets in passing argument 1 of
> 'getSafetyLevel' differ in signedness
> pragma.c:621: warning: pointer targets in passing argument 1 of
> 'getBoolean' differ in signedness
> printf.c: In function 'vxprintf':
> printf.c:628: warning: pointer targets in passing argument 2 of 'func'
> differ in signedness
> select.c: In function 'sqlite3JoinType':
> select.c:112: warning: pointer targets in passing argument 1 of
> 'sqlite3StrNICmp' differ in signedness
> select.c: In function 'setToken':
> select.c:157: warning: pointer targets in assignment differ in signedness
> select.c: In function 'keyInfoFromExprList':
> select.c:625: warning: pointer targets in assignment differ in signedness
> select.c: In function 'generateColumnNames':
> select.c:869: warning: pointer targets in passing argument 3 of
> 'sqlite3VdbeSetColName' differ in signedness
> select.c:882: warning: pointer targets in passing argument 3 of
> 'sqlite3VdbeSetColName' differ in signedness
> select.c: In function 'flattenSubquery':
> select.c:2088: warning: pointer targets in passing argument 1 of
> 'sqlite3StrNDup' differ in signedness
> select.c: In function 'simpleMinMaxQuery':
> select.c:2187: warning: pointer targets in passing argument 1 of
> 'sqlite3StrNICmp' differ in signedness
> select.c:2189: warning: pointer targets in passing argument 1 of
> 'sqlite3StrNICmp' differ in signedness
> shell.c: In function 'output_csv':
> shell.c:355: warning: pointer targets in passing argument 1 of
> 'isNumber' differ in signedness
> shell.c: In function 'callback':
> shell.c:523: warning: pointer targets in passing argument 1 of
> 'isNumber' differ in signedness
> shell.c: In function 'dump_callback':
> shell.c:694: warning: pointer targets in passing argument 2 of
> 'appendText' differ in signedness
> tokenize.c: In function 'sqlite3RunParser':
> tokenize.c:360: warning: pointer targets in assignment differ in signedness
> trigger.c: In function 'sqlite3FinishTrigger':
> trigger.c:240: warning: pointer targets in passing argument 3 of
> 'sqlite3VdbeChangeP3' differ in signedness
> trigger.c: In function 'sqlitePersistTriggerStep':
> trigger.c:281: warning: pointer targets in passing argument 1 of
> 'sqlite3StrNDup' differ in signedness
> trigger.c:281: warning: pointer targets in assignment differ in signedness
> trigger.c: In function 'targetSrcList':
> trigger.c:623: warning: pointer targets in assignment differ in signedness
> trigger.c:624: warning: pointer targets in passing argument 1 of
> 'strlen' differ in signedness
> utf.c: In function 'sqlite3VdbeMemTranslate':
> utf.c:275: warning: pointer targets in assignment differ in signedness
> utf.c:311: warning: pointer targets in assignment differ in signedness
> utf.c:363: warning: pointer targets in assignment differ in signedness
> utf.c:368: warning: pointer targets in assignment differ in signedness
> vacuum.c: In function 'execExecSql':
> vacuum.c:61: warning: pointer targets in passing argument 2 of
> 'execSql' differ in signedness
> vdbeapi.c: In function 'sqlite3_value_text':
> vdbeapi.c:61: warning: pointer targets in return differ in signedness
> vdbeaux.c: In function 'sqlite3VdbeIdxRowid':
> vdbeaux.c:1735: warning: pointer targets in passing argument 1 of
> 'sqlite3GetVarint32' differ in signedness
> vdbeaux.c:1736: warning: pointer targets in passing argument 1 of
> 'sqlite3GetVarint32' differ in signedness
> vdbeaux.c:1738: warning: pointer targets in passing argument 1 of
> 'sqlite3VdbeSerialGet' differ in signedness
> vdbeaux.c: In function 'sqlite3VdbeIdxKeyCompare':
> vdbeaux.c:1774: warning: pointer targets in passing argument 2 of
> 'sqlite3VdbeIdxRowidLen' differ in signedness
> vdbe.c: In function 'sqlite3VdbeExec':
> vdbe.c:1873: warning: pointer targets in assignment differ in signedness
> vdbe.c:1940: warning: pointer targets in assignment differ in signedness
> vdbe.c:1940: warning: pointer targets in assignment differ in signedness
> vdbe.c:1945: warning: pointer targets in passing argument 1 of
> 'sqlite3GetVarint32' differ in signedness
> vdbe.c:1972: warning: pointer targets in passing argument 1 of
> 'sqlite3GetVarint32' differ in signedness
> vdbe.c:2026: warning: pointer targets in passing argument 1 of
> 'sqlite3VdbeSerialGet' differ in signedness
> vdbe.c:2189: warning: pointer targets in assignment differ in signedness
> vdbe.c:2223: warning: pointer targets in assignment differ in signedness
> vdbe.c:2920: warning: pointer targets in passing argument 2 of
> 'sqlite3VdbeIdxRowidLen' differ in signedness
> vdbe.c:2937: warning: pointer targets in passing argument 3 of
> 'sqlite3VdbeIdxKeyCompare' differ in signedness
> vdbe.c:3710: warning: pointer targets in passing argument 3 of
> 'sqlite3VdbeIdxKeyCompare' differ in signedness
> vdbe.c:3748: warning: pointer targets in passing argument 1 of
> 'sqlite3GetVarint32' differ in signedness
> vdbe.c:3750: warning: pointer targets in passing argument 1 of
> 'sqlite3GetVarint32' differ in signedness
> vdbemem.c: In function 'sqlite3VdbeMemDynamicify':
> vdbemem.c:76: warning: pointer targets in assignment differ in signedness
> vdbemem.c: In function 'sqlite3VdbeMemMakeWriteable':
> vdbemem.c:96: warning: pointer targets in assignment differ in signedness
> vdbemem.c:109: warning: pointer targets in assignment differ in signedness
> vdbemem.c: In function 'sqlite3VdbeMemStringify':
> vdbemem.c:165: warning: pointer targets in initialization differ in signedness
> vdbemem.c:177: warning: pointer targets in passing argument 2 of
> 'sqlite3_snprintf' differ in signedness
> vdbemem.c:180: warning: pointer targets in passing argument 2 of
> 'sqlite3_snprintf' differ in signedness
> vdbemem.c:182: warning: pointer targets in passing argument 1 of
> 'strlen' differ in signedness
> vdbemem.c:183: warning: pointer targets in assignment differ in signedness
> vdbemem.c: In function 'sqlite3ValueFromExpr':
> vdbemem.c:769: warning: pointer targets in passing argument 1 of
> 'sqlite3StrNDup' differ in signedness
> vdbemem.c:789: warning: pointer targets in passing argument 1 of
> 'sqlite3StrNDup' differ in signedness
> where.c: In function 'isLikeOrGlob':
> where.c:514: warning: pointer targets in assignment differ in signedness

Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Windows kernel tool

Brad-19
In reply to this post by Fred Williams
> 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

Reply | Threaded
Open this post in threaded view
|

RE: SQLite as a Windows kernel tool

Fred Williams
In reply to this post by John Stanton-3
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:[hidden email]]
> Sent: Monday, October 31, 2005 8:28 AM
> To: [hidden email]
> 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 <[hidden email]> 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:
> >
> > lucas@ubu:~/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
...

Reply | Threaded
Open this post in threaded view
|

Re: SQLite as a Windows kernel tool

Russ Freeman
In reply to this post by D. Richard Hipp

> 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 <[hidden email]>
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.