Ian wrote: > Yup, OK, I see where you are with this. Hmm... > > Basically, if you set the locale to Turkish (or I suppose potentially > some other Turkic language, Crimea or whatever...) then any time we (in > the fltk core lib) try to string compare against a word that has a > "lower-case-small-i" in it, then the comparison will fail, since we > *expect* "i" to become "I" but with those locales selected it instead > gets promoted to a "upper-case-dotted-I" instead... > > Well, that's a bit tricky. > > Observations:=20 > > The use of strncasecmp() in fl_set_fonts_xft.cxx to extract face styles > is mostly my fault, and is really not very nice at all; there's (at > least) one STR open on it already describing cases where it fails on > some combination of host and fonts... We might be able to do something > more robust (though I don't quite know what.) > > We could make it so that the scheme has to be explicitly lowercase > "plastic", thereby ducking that specific failure. > > Other uses (e.g. in the file_chooser or pathname code, possibly even in > arg parsing...) we would probably *want* the locale-specific behaviour > though? > > And yes, tolower and toupper might well be problematic in the same way. > > I can't imagine we are the only people hitting this - do we have any > idea what other platforms do?
The first couple of things I find in web searching ( https://github.com/bagder/curl/blob/bab5183820dbd2e0ea9ee4f0442844291d05c90e/lib/strequal.c http://svn.xiph.org/trunk/vorbis-tools/share/charset.c ) make their own ascii strcasecmp()s. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
