On Mon, Jun 13, 2016 at 9:21 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> On Mon, Jun 13, 2016 at 4:46 PM, jungle Boogie <jungleboog...@gmail.com> > wrote: > >> Maybe fix these minor warnings? >> >> -g -O2 -DHAVE_AUTOCONFIG_H -D_HAVE_SQLITE_CONFIG_H -O2 -pipe -o >> bld/lookslike.o -c bld/lookslike_.c >> ./src/lookslike.c:162:57: warning: '&&' within '||' >> [-Wlogical-op-parentheses] >> if( ((c&0xc0)!=0x80) || ((c2<0xc2) || (c2>=0xf4)) && >> ~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~^~ >> ./src/lookslike.c:162:57: note: place parentheses around the '&&' >> expression to silence this warning >> if( ((c&0xc0)!=0x80) || ((c2<0xc2) || (c2>=0xf4)) && >> > > That reminds me: i found a workaround for the "strict type punning" > warning[1] in cson reported a few weeks ago, but it will likely be the > weekend before i can patch and test it. It's not important for a release, > in any case, just a "nice to have" with certain gcc versions. > > > [1] = use memcpy() instead of *ptrDeref=foo. > Funny that "lookslike.c" came up since I've been playing in that for a few days. I added an alternative implementation that I like more than the existing one. The edge cases have been shaken out of the current implementation in trunk, but I still prefer mine for two reasons: 1. I just think it's a lot easier to read and reason about what the function does. 2. In my profiling (32 bit exe on Windows 10 x64) it's about 20% faster. Note: This could be completely due to the type of data being fed into the two functions. My testing involved generating every possible byte sequence up to four bytes in length and feeding it through both versions of the function, so it was testing over 16 GiB of data in no more than 4 byte chunks. Both versions of the function currently agree on the validity of all possible byte sequences. I'm not normally one to advocate changing code for the sake of changing code. I just spent enough time on this due to earlier bug reports that it's two benefits seem worth considering. In no way is this a slight on Jan's implementation, which is in no way a "slow" function. The one negative to my function at this point is that it is longer even not counting the liberal comments throughout. If anyone is interesting in seeing the test harness I built around the two versions so I could test them at the same time in the same executable, I'd be happy to share it. The branch my version is in is invalid_utf8_trunk. If anyone would take a look at it and decide if it's worth using I'd really appreciate it. -- Scott Robison
_______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
