On 8 Dec 2012, at 03:17, corvid wrote:
<...lots of useful analysis of fltk's use of strcasecmp...>
So, that's good stuff, and suggests that *probably* most of our usage is
"ASCII", or perhaps C locale based, and so therefore is fine "as is" for a
"normal" locale?
Does that sound about right?
I guess if we do enable a Turkic locale we maybe have to ensure that these
usages all ignore the selected locale and always use the C locale instead, then.
Exceptions might be:
> fluid/factory.cxx:1262: if (!strcasecmp(name,table[i].name)) {v =
> table[i].value; return 1;}
>
> So these are all about ASCII English as well. (I notice, though, that
> lookup_symbol is called in places where the surrounding tests looked at
> least superficially similar, and those were using strcmp(). That might
> be right to be case-sensitive and not in others, and maybe not.)
Where maybe being sensitive to the host locale may make sense? At least in some
case...
And...
> src/fl_utf8.cxx:186: UTF-8 aware strncasecmp - converts to lower case Unicode
> and tests.
> src/fl_utf8.cxx:194:int fl_utf_strncasecmp(const char *s1, const char *s2,
> int n)
> src/fl_utf8.cxx:215: UTF-8 aware strcasecmp - converts to Unicode and tests.
> src/fl_utf8.cxx:221:int fl_utf_strcasecmp(const char *s1, const char *s2)
> src/fl_utf8.cxx:223: return fl_utf_strncasecmp(s1, s2, 0x7fffffff);
>
> It looks like ucs_table_0041 does ASCII mappings.
> (I note that U+0130, capital i with dot, doesn't have a lowercase entry.)
Hmm, I guess ideally we'd want this to be self-consistent, so that converting a
char to upper and then to lower is an identity operation?
E.g. if an english or C locale was active, then i -> I -> i
But if Turkic was active then i -> I(dotted) -> i and also i(non-dot) -> I ->
i(non-dot)... ?
Thoughts, anyone?
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
