- Dillo-dev - lists.mailman3.com

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

by corvid＠lavabit.com

Jorge wrote: > On Mon, Nov 07, 2011 at 10:25:39PM +0100, Johannes Hofmann wrote: > > On Sun, Nov 06, 2011 at 08:19:07PM +0000, corvid wrote: > > > Johannes wrote: > > > > I'd just go with the approach in your first patch. > > > > > > All right then. Do you have any thoughts on what function names > > > would be least unwieldy / most descriptive / best fitting in > > > with their surroundings? > > > > > > I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp(). > > > > Let's see what others do: > > > > * KDE: kAsciiToUpper() [1] > > * glib: g_ascii_toupper() [2] > > * ffmpeg: av_toupper() [3] > > * libevent: evutil_ascii_strcasecmp() [4] > > > > So dAsciiToupper() and dStrAsciiCasecmp() look good to me. > > +1 I think I'll go with D_ASCII_TOUPPER because the argument gets evaluated more than once, and we don't want nasty surprises. (I'm tempted to say "Or ASCII_TOUPPER?", but it'd be nice for the whole topic to come to an end, wouldn't it? :)

Nov. 8, 2011

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

by jcid＠dillo.org

On Mon, Nov 07, 2011 at 10:25:39PM +0100, Johannes Hofmann wrote: > On Sun, Nov 06, 2011 at 08:19:07PM +0000, corvid wrote: > > Johannes wrote: > > > I'd just go with the approach in your first patch. > > > > All right then. Do you have any thoughts on what function names > > would be least unwieldy / most descriptive / best fitting in > > with their surroundings? > > > > I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp(). > > Let's see what others do: > > * KDE: kAsciiToUpper() [1] > * glib: g_ascii_toupper() [2] > * ffmpeg: av_toupper() [3] > * libevent: evutil_ascii_strcasecmp() [4] > > So dAsciiToupper() and dStrAsciiCasecmp() look good to me. +1 -- Cheers Jorge.-

Nov. 8, 2011

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

by Johannes.Hofmann＠gmx.de

On Sun, Nov 06, 2011 at 08:19:07PM +0000, corvid wrote: > Johannes wrote: > > I'd just go with the approach in your first patch. > > All right then. Do you have any thoughts on what function names > would be least unwieldy / most descriptive / best fitting in > with their surroundings? > > I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp(). Let's see what others do: * KDE: kAsciiToUpper() [1] * glib: g_ascii_toupper() [2] * ffmpeg: av_toupper() [3] * libevent: evutil_ascii_strcasecmp() [4] So dAsciiToupper() and dStrAsciiCasecmp() look good to me. Cheers, Johannes [1] http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/kascii_8h.html [2] http://developer.gnome.org/glib/2.28/glib-String-Utility-Functions.html [3] http://permalink.gmane.org/gmane.comp.video.ffmpeg.cvs/43420 [4] http://www.wangafu.net/~nickm/libevent-2.0/doxygen/html/util_8h.html

Nov. 7, 2011

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

by corvid＠lavabit.com

Johannes wrote: > I'd just go with the approach in your first patch. All right then. Do you have any thoughts on what function names would be least unwieldy / most descriptive / best fitting in with their surroundings? I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp().

Nov. 6, 2011

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

by Johannes.Hofmann＠gmx.de

On Sun, Nov 06, 2011 at 04:03:47AM +0000, corvid wrote: > I wrote: > > Johannes wrote: > > > Or maybe > > > test for strncasecmp_l() in configure and provide a custom solution > > > if it doesn't exist? > > > > I'm willing to give that a look as well. At first I was reluctant to > > have extra locale calls when the string functions are so cheap to > > begin with, but... > > I thought the extra argument to the *_l functions was a string like "C", > but it's a locale_t, which also appears to be something new. This makes > it not very nice to simulate. Hmph. I'd just go with the approach in your first patch.

Nov. 6, 2011

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

by corvid＠lavabit.com

I wrote: > Johannes wrote: > > Or maybe > > test for strncasecmp_l() in configure and provide a custom solution > > if it doesn't exist? > > I'm willing to give that a look as well. At first I was reluctant to > have extra locale calls when the string functions are so cheap to > begin with, but... I thought the extra argument to the *_l functions was a string like "C", but it's a locale_t, which also appears to be something new. This makes it not very nice to simulate. Hmph.

Nov. 6, 2011

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

by jcid＠dillo.org

On Sat, Nov 05, 2011 at 06:45:19PM +0000, corvid wrote: > Johannes wrote: > > 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? > > I was curious whether something closer to what Jorge was talking about > would turn out to be more pleasing in some way, and maybe a tad quicker, > for that matter, with their optimized functions, but...yeah, it didn't > really look nicer to me, either. My idea was to have a custom function for the turkish locale (eventually extendable to a bigger set if the need arises), and to use the defaults for all the other cases. With the custom function handling the special case(s), and not handling all characters as special. > > Or maybe > > test for strncasecmp_l() in configure and provide a custom solution > > if it doesn't exist? Yes, this would also add to the solution. > I'm willing to give that a look as well. At first I was reluctant to > have extra locale calls when the string functions are so cheap to > begin with, but... -- Cheers Jorge.-

Nov. 5, 2011

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

by corvid＠lavabit.com

Johannes wrote: > 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? I was curious whether something closer to what Jorge was talking about would turn out to be more pleasing in some way, and maybe a tad quicker, for that matter, with their optimized functions, but...yeah, it didn't really look nicer to me, either. > Or maybe > test for strncasecmp_l() in configure and provide a custom solution > if it doesn't exist? I'm willing to give that a look as well. At first I was reluctant to have extra locale calls when the string functions are so cheap to begin with, but...

Nov. 5, 2011

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

by Johannes.Hofmann＠gmx.de

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

Nov. 5, 2011

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

by corvid＠lavabit.com

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

Nov. 4, 2011