Re: localization in (s)printf

[Andreas Jaeger]

Gilles Duvert <address@hidden> writes:

> Sirs,
>
> I would like to let you know of an annoying, possibly fatal, side effect of 
> the new standards followed by the (s)printf() family of functions.
>

> After an upgrade to Mandrake 8.2, I have found to my great dismay
> that the family of sprint() C functions would now format floats
> according to the current locale. This is simply crazy. We
> (astronomers) have tons of programs that exchange, sometimes
> internally, formatted data between C and Fortran. With the new GLIBC
> [glib-config --version says that my version is 1.2.10], a genuine

glib != glibc!

> %6.2f format will be written with a comma (under locale fr_FR) as
> separator for the fractional part, and the fortran compiled with g77
> at the same time will look for a dot as separator when trying to
> read the value . Nothing will work anymore (in fact, nothing works
> anymore!).

Set one of the LC_* environment variables that change this, they're
explained in the glibc manual.

>

> I know pretty well that the glibc adhere to new standards and that
> our problem can be solved readily if we enforce the en_EN locale on
> our machines (the supposedlly "portable" POSIX locale does not work
> according to the documentation---a bug??). I find this not desirable
> at all since it goes backwards in terms of internationalization!

POSIX works, check your settings with locale.


>
> Of course I have already solved my problem with an adequate call to 
> setlocale(), but I am sure that this new localization feature will break many 
> an old trusty code.

glibc follows the existing standards.  If you do not want
localization, you should not set LC_* or LANG in your environment.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs address@hidden
   private address@hidden
    http://www.suse.de/~aj