[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NetBSD failure on nl_langinfo

From: Eric Blake
Subject: Re: NetBSD failure on nl_langinfo
Date: Fri, 22 Oct 2010 09:36:25 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100921 Fedora/3.1.4-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.4

On 10/21/2010 06:06 PM, Bruno Haible wrote:
It is not formally a bug, since glibc also returns the empty string for
nl_langinfo (CRNCYSTR) in some locales (the C locale for example).

But the C locale has no currency string. POSIX is pretty clear about CRNCYSTR:

CRNCYSTR  LC_MONETARY  Local currency symbol, preceded by '-' if the symbol should appear 
before the value, '+' if the symbol should appear after the value, or '.' if the symbol 
should replace the radix character. If the local currency symbol is the empty string, 
implementations may return the empty string ( "" ).

If the locale's values for p_cs_precedes and n_cs_precedes do not match, the 
value of nl_langinfo(CRNCYSTR) and nl_langinfo_l(CRNCYSTR,loc) is unspecified.

So if 'locale -ck currency_symbol' declares the empty string, or if 'locale -ck p_cs_precedes n_cs_precedes' disagree, then an empty CRNCYSTR makes sense; but since on the NetBSD system:

$ LC_ALL=fr_FR.ISO8859-1 locale -ck currency_symbol {p,n}_cs_precedes

I argue that CRNCYSTR for fr_FR.ISO8859-1 MUST result in "+Eu", not the empty string.

It's simply unexpected behaviour. Only the test needs to be fixed. I'm
committing this:

I'm not sure that was right; I think NetBSD actually has a bug, and we can probably work around it by querying the locale database with localeconv.

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]