Re: printf doesn't respect locale

[Rich Felker <dalias@libc.org>]

On Mon, Sep 09, 2019 at 05:31:01PM +0100, Daniel Schoepe wrote:
> Hi,
> 
> I think I found a discrepancy between musl's behavior and the POSIX standard:
> 
> According to the POSIX standard, the decimal separator used when using
> printf to print floating point numbers should come from the locale
> (https://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html):
> 
> "The radix character is defined in the current locale (category
> LC_NUMERIC). In the POSIX locale, or in a locale where the radix
> character is not defined, the radix character shall default to a
> <period> ( '.' )."
> 
> However, it seems that in musl, a period is always used for printing
> floating point numbers. For example, the following program prints
> "12.0" instead of "12,0" (which is printed when using GNU libc):

It's not a discrepancy; the set of locales supported by an
implementation, unless it includes the POSIX localedef utility/option,
is implementation-defined. musl's definition does not include locales
where the radix point is not '.'

I really really really don't like the feature of changing the radix
point, and this implementation choice was intentional, but it's come
up several times with people being upset that it's not in line with
musl's mission of being multilingual-friendly. I think it deserves
some consideration again along with upcoming locale improvements.
There's at least one past thread with design sketches on how it would
need to be done (and what needs to be done anyway for LC_MONETARY
stuff), and sadly it got no feedback from people interested in
improved locale functionality which is why I've kinda let it be for
the time being...

Rich