On Thu, Sep 17, 2015 at 1:24 PM, Ralf Junker <ralfjunker at gmx.de> wrote:
> On 17.09.2015 20:14, Scott Hess wrote: > >> The problem is that there are LOCALE settings where tolower() does things >> C >> programmers don't expect. I think tr_TR was one case, the handling of 'I' >> (Google "tr_tr locale bug" and you'll see lots of people hitting the same >> general problem). It isn't a problem of type safety, it's a problem that >> the same inputs might have different outputs for certain library functions >> when you change environment variables. I don't remember whether there >> were >> specific problems with other ctype functions, or if I just thought it was >> a >> good idea to be careful, once I realized the class of problem. >> > > And this check-in therefore misses the point as it does not address this > LOCALE problem IMHO: > > http://www.sqlite.org/src/info/6713e35b8a8c997a Hmm. Well, it might miss _a_ point, while solidly landing some other point :-). Current fts3 seems to spread this code differently, under fts2.c it was like: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/sqlite/src/ext/fts2/fts2.c&l=336 where it's not a wrapper around the library, instead it was a direct implementation of the functions which only acted on 7-bit values in the ASCII set. I think these should really be in terms of sqlite3UpperToLower and sqlite3CtypeMap. That might be an issue to expose to an extension sensibly. -scott
