This is the mail archive of the
libc-locales@sourceware.org
mailing list for the GNU libc locales project.
[Bug localedata/16067] New: int_curr_symbol processed incorrectly
- From: "van.de.bugger at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: libc-locales at sourceware dot org
- Date: Sun, 20 Oct 2013 21:50:24 +0000
- Subject: [Bug localedata/16067] New: int_curr_symbol processed incorrectly
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16067
Bug ID: 16067
Summary: int_curr_symbol processed incorrectly
Product: glibc
Version: 2.17
Status: NEW
Severity: minor
Priority: P2
Component: localedata
Assignee: unassigned at sourceware dot org
Reporter: van.de.bugger at gmail dot com
CC: libc-locales at sourceware dot org
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html:
> int_curr_symbol
> The international currency symbol. The operand shall be a four-character
> string, with the first three characters containing the alphabetic
> international currency symbol. The international currency symbol should be
> chosen in accordance with those specified in the ISO 4217 standard. The fourth
> character shall be the character used to separate the international currency
> symbol from the monetary quantity.
Note: they require 4-CHARACTER string.
In my custom locale I have a line:
> LC_MONETARY
> int_curr_symbol "RUB<U00A0>"
U00A0 is a non-breaking space. It is one character.
When building such a locale, localedef issues a warning:
> LC_MONETARY: value of field `int_curr_symbol' has wrong length
Being used, it prodices wrong result:
> RUBï10Â999.95
Note the wrong character between currency name and quantity. Looks like
localedef uses only 4 BYTES of int_curr_symbol, while it should use 4
CHARACTERS.
--
You are receiving this mail because:
You are on the CC list for the bug.