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