On Fri, Sep 29, 2017 at 5:12 PM, Richard Damon <rich...@damon-family.org> wrote:
> On 9/29/17 2:58 PM, J Decker wrote: > >> 20 warnings “cast discards __attribute__((noreturn))” like: >>> >>> SQLite3.c:55734:10: warning: cast discards ‘__attribute__((noreturn))’ >>> qualifier from pointer target type [-Wcast-qual] >>> memcpy((void*)&aHdr[1], (const void*)&pWal->hdr, >>> sizeof(WalIndexHdr)); >>> >>> 768 warnings “may change the sign of the result” like: >>> >>> SQLite3.c:19330:11: warning: conversion to ‘unsigned int’ from ‘int’ may >>> change the sign of the result [-Wsign-conversion] >>> >>> 75 warnings “signed overflow” like: >>> SQLite3.c:61116:3: warning: assuming signed overflow does not occur when >>> reducing constant in comparison [-Wstrict-overflow] >>> >>> As a result I would like to recommend to build SQLite with all extra >>> warning options. In total, I have counted unbelievable 2628 warnings of >>> potential errors without any efforts from my side. >>> >>> >>> As for the above... those can be catastrophic; and I'm surprised there >> are >> so many sign conversion warnings generated... >> >> >> Note, the warning doesn't say that an overflow has/will occur, just that > it assumed it won't and optimized based on that. If the program took care > to avoid overflow, all is good. If the program made the (invalid) > assumption that signed arithmetic wrapped on overflow like unsigned, then > the program has a problem. > > My guess is that the code is good enough not to have the overflow issue. > > That sort of warning is aimed at 'sloppy programmers' who think that just > because it seems to work, it must be right and to the standard. I've been trying to remember the case... it worked for a lot of years(a decade+); think it was something like uint16_t w = 100; int32_t o = -1; and the integer was compared as unsigned... and o was greater than w. either that or it was a uin16_t x = 0x8000 that was converted to signed and was sign extended.... but I think it was the former. Sort of, I found that if the comparison can be done wrong MS will pick the way to compile a signed/unsigned comparison so it fails most often. It really could have been defined in the standard such that if unsigned, if (highest bit set in unsigned) set always greater, if highest bit is set in signed, set always lesser... otherwise compare as normal. I had started to try to standardize to signed or unsigned values; but that started to cause other problems. I eventually just implemented a bunch of comparison macros that just do the right thing.... (SUS = signed-unsigned; USS = unsigned-signed) # define SUS_GT(a,at,b,bt) (((a)<0)?0:(((bt)a)>(b))) # define USS_GT(a,at,b,bt) (((b)<0)?1:((a)>((at)b))) # define SUS_LT(a,at,b,bt) (((a)<0)?1:(((bt)a)<(b))) # define USS_LT(a,at,b,bt) (((b)<0)?0:((a)<((at)b))) # define SUS_GTE(a,at,b,bt) (((a)<0)?0:(((bt)a)>=(b))) # define USS_GTE(a,at,b,bt) (((b)<0)?1:((a)>=((at)b))) # define SUS_LTE(a,at,b,bt) (((a)<0)?1:(((bt)a)<=(b))) # define USS_LTE(a,at,b,bt) (((b)<0)?0:((a)<=((at)b))) > > -- > Richard Damon > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
