Bug#820803: xterm: X resources parsed with locale settings

[Philipp Marek <philipp.marek@linbit.com>]

> > > > Configuration files should be parsed via the "C" locale, IMO - having to 
> > > > think about "," vs. "." in there is awkward.
> > 
> > faceSize is affected, too, BTW.
> > 
> > 
> > > As far as I can tell the conversion is done in
> > > https://cgit.freedesktop.org/xorg/lib/libXt/tree/src/Converters.c#n822
> > > which indeed depends on the locale.
> > > 
> > > But since there's no way to tell how many people depend on the current
> > > behaviour, and changing it would break their configuration...
> > Well, it can't be *that* many people - because it's not that likely that
> >  a) different locale settings apply, AND
> >  b) user wants to change one of the few configuration settings that
> >     are affected, AND
> >  c) user figures out that "," (or whatever else) would be the answer.
> > 
> > So, IMO changing that would be safe enough.
> > 
> > 
> > If you disagree with me, then how about just keeping the current behaviour, 
> > but try to parse with the "C" locale too!?
> It's a little late for that (existing configurations would break if xterm
> switched to "C" locale for evaluating resources).
It's never too late.
And I guess the number of users that figured out "," is *really* small 
- put it in Changelog, and they'll figure out to use "." too.


> And unlike the workaround used for "menuLocale", it's too early in the
> initialization for it to be a good solution for xterm (because that
> would break other parts of the initialization).
> 
> Besides this, there's the scaleHeight resource with the same potential issue.
Yeah, right.
Same reasoning as above applies, though.


Well, just use strtof() instead of sscanf(), and it's "." for comma only.
The current behaviour is unusable if people come in with (potentially) 
differing locales.