On Wed, Nov 16, 2016 at 10:52:13PM +0700, Dan Kennedy wrote: > On 11/16/2016 05:53 AM, Nico Williams wrote: > > [...] > > > > Anyways, the analysis from here is non-trivial, and I can't convince > > myself that sNC.pNext will not be dereferenced. > > Thanks for taking the time to look into these. > > Some kind of assert() could be helpful there I think. The reason sNC.pNext > will not be accessed is that generateColumnNames() is only called (a) on a > top-level SELECT statement and (b) after all references have already > resolved successfully. Implying that this: > > http://www.sqlite.org/src/artifact/672b1af237ad2?ln=1406 > > is always true.
That's... a bit too convoluted to for my liking. I'd rather have sNC.pNext initialized than an assertion that might get compiled out. This is a function invoked on statement preparation, so I think initializing sNC.pNext can't negatively affect performance in any terribly meaningful way. > > Another one that I find difficult to analyze is a possible > > out-of-bounds read in vdbeSorterCompareInt(): > > > > [...] > > > > At 85715 we know that (s1 <= 7 || s2 <= 7) && s1 == s2, and we also > > know that either s1 or s2 can be 8 or 9, so aLen[s1] at 85715 could > > very well have s1 > 6, which would read past the bounds of aLen[]. > > I think ( ( s1<=7 || s2<=7) && s1==s2 ) implies that s1<=7. And we assume > s1!=7 because there is an assert() that says so. Oh, I see it now. Yeah, OK. This is definitely a false positive. Thanks for the response, Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
