This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug localedata/16067] localedef: int_curr_symbol: non-ASCII data processed incorrectly
- From: "vapier at gentoo dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 19 Apr 2016 15:39:58 +0000
- Subject: [Bug localedata/16067] localedef: int_curr_symbol: non-ASCII data processed incorrectly
- Auto-submitted: auto-generated
- References: <bug-16067-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16067
Mike Frysinger <vapier at gentoo dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|int_curr_symbol processed |localedef: int_curr_symbol:
|incorrectly |non-ASCII data processed
| |incorrectly
--- Comment #4 from Mike Frysinger <vapier at gentoo dot org> ---
the code uses strlen which counts bytes rather than characters. when you use
chars higher than 0x7e, then it takes two bytes to represent it, and then it
pushes from 4 to >4.
locales/programs/ld-monetary.c:
if (strlen (monetary->int_curr_symbol) != 4)
probably should be using mbstowcs, but then it'd mean we'd dependent upon the
current locale in order to process the inputs correctly. which we need to sort
out anyways though in order to convert the inputs to UTF-8.
i don't know why it's rendering incorrectly for you though ... that looks like
it's also chopping at 4 bytes, but i'm not seeing code that does that. it
should be loaded as an arbitrary string of arbitrary length.
--
You are receiving this mail because:
You are on the CC list for the bug.