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