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

On Mon, Oct 31, 2011 at 04:03:38AM +0000, corvid wrote:
> Jorge wrote:
> > On Sun, Oct 23, 2011 at 10:28:43AM +0200, Johannes Hofmann wrote:
> > > On Sun, Oct 23, 2011 at 05:55:30AM +0000, corvid wrote:
> > > > 
> > > > Here's an idea of what we'd get:
> > > > 
> > > > http://www.dillo.org/test/ascii_strcasecmp.diff
> > > > 
> > > > - The naming is clear but kind of ugly.
> > > > - I haven't added explanatory comments yet.
> > > > - For the moment, it just #defines dStr(n)casecmp to the
> > > >   ASCII version because there are a bunch of them, but I'd
> > > >   go through and change the calls.
> > > > 
> > > > Thoughts?
> > > 
> > > I think it's nasty, but the right way to fix this.
> > 
> >   Yeah. Ater all locales/utf-8 is seldom a simple thing to handle right.
> > 
> >   If we'd have to:
> > 
> >       s/dStrcasecmp/dStrASCIIcasecmp/g
> >       s/dStrncasecmp/dStrnASCIIcasecmp/g
> > 
> >   then I'd keep the old function name and explain in the function's
> > comment why it is restricted to, or handled in the new way.
> 
> Calling it 'strcasecmp' when it isn't really strcasecmp seems dangerous.

  Good point...


> >   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).

-- 
  Cheers
  Jorge.-