> > I suspect this to be a locale issue (e.g. dot vs comma notation for
> > separating the decimal fraction) ??
>
> Quite possibly, although as the column is printed with "%f", I'd expect
> the locale issues to cancel out (i.e., in locales with "." as the
> decimal separator, I'd expect, for example, 1/2 to be g_snprintf'ed as
> ".5" and ".5" to be sscanf'ed or atof'ed into 1/2, and in locales with
> "," as the decimal separator, I'd expect 1/2 to go to ",5" and ",5" to
> become 1/2).
>
> Perhaps "g_snprintf()" isn't obeying the locale settings?
>
> > tests were carried out on
> > Win2000 SP2 (french) - ok
> > Win98SE (german) - failed!
>
> If by "french" and "german" you mean you've selected those locales, I'd
> expect them to succeed or fail in the same way, if it's purely a local
> issue - folks on both sides of the Rhine use ",", n'est ce pas/nicht
> war?
With french and german, i was refering to the language installation.
I dont know how this refers to the set locale. (Dont know much about locales
in general)
Yes, i know that these would have the same decimal dot notation. I just
cited that for completeness.
> This might be a Windows OT vs. Windows NT issue. We appear *not* to
> use our private "snprintf()" on Windows, presumably meaning we use a
> version that comes with MSVC++'s C library, at least when building with
> "nmake"...
> You might want to experiment with having the sort code copy the strings,
> replace the decimal separator that's displayed with the other one, and
> try converting that with "atof()" or "sscanf()", and see if that fixes
> the problem.
Yes.
Another possibility could be to expand the strings with the right number of
leading zeros, then just do a strncmp.
> (Also, is the decimal separator being displayed the right
> one for the locale?)
The displays shows a dot '.' on both environments.
Lars