Re: ascii string comparison [Re: use C locale for LC_CTYPE]

On Fri, Nov 04, 2011 at 02:41:28AM +0000, corvid wrote:
> Jorge wrote:
> > On Mon, Oct 31, 2011 at 04:03:38AM +0000, corvid wrote:
> > > Jorge wrote:
> > > >   From a distance this global change looks to me like exposing ourselves
> > > > to more troubles. In other words, why not:
> > > > 
> > > >      int dStrcasecmp(...)
> > > >      {
> > > >         if (locale has special rules)
> > > >            special treatment
> > > >         else
> > > >            strcasecmp(...)
> > > >      }
> > > > 
> > > >   Disclaimer: I haven't studied the problem in detail.
> > > 
> > > Having to know about the locales would be trouble.
> > > Judging by the wikipedia page, we'd have to look for 'tr' and 'az'
> > > for sure, and they've been considering switching back to Latin
> > > script in Kazakhstan, and probably not Tatar because they're mostly
> > > Cyrillic, but probably yes to Crimean Tatar because it looks like
> > > they're a bit more Latin than Cyrillic at the moment.
> > > 
> > > So it's a touchy enough situation that different libc's may have
> > > different ideas of it all, and individual ones will change as
> > > circumstances change,
> > 
> >   If libc has not nailed it already, it must be hard to solve
> > the problem in a generic way.
> > 
> > > and it would make more sense to have a
> > > test like checking whether toupper('i') == 'I'.
> > >
> > > And better than that would be to go through the whole ASCII alphabet
> > > at initialization time and see whether everything is as we wish, and
> > > then set some ptrs to functions accordingly.
> > 
> >  +1
> > 
> >   (or just test the subset we know we can handle).
> 
> Here's what I ended up with when I added in some initialization on the
> dlib side: http://www.dillo.org/test/ascii_strcasecmp2.diff
> 

Hm, what's the point of the dynamic check? We don't
want our case insensitive compare function to depend on the user locale, 
so I would say using strcasecmp(3) and tolower(3) is just wrong in our
case - even if it happens to return the right values in some setups.
Why not just use a custom function as in the first patch? Or maybe
test for strncasecmp_l() in configure and provide a custom solution
if it doesn't exist?

Cheers,
Johannes