public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dreibh at simula dot no" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug locale/31542] New: printf integer formatting bug for nb_NO and nn_NO locales Date: Sun, 24 Mar 2024 09:42:26 +0000 [thread overview] Message-ID: <bug-31542-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=31542 Bug ID: 31542 Summary: printf integer formatting bug for nb_NO and nn_NO locales Product: glibc Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: locale Assignee: unassigned at sourceware dot org Reporter: dreibh at simula dot no Target Milestone: --- There is a formatting bug for integers in printf() when using locale settings and formatting with thousands separator. Test program printfbug.c: #include <stdio.h> #include <stdlib.h> #include <locale.h> int main(int argc, char** argv) { setlocale (LC_ALL, ""); struct lconv* loc = localeconv(); printf("Thousands Separator: <%s>\n", loc->thousands_sep); for(int i = 1; i <argc; i++) { int n = atoi(argv[i]); double f = atof(argv[i]); printf("double <%'10.0f>\tint <%'10d>\n", f, n); } return 0; } Test run: for l in en_US de_DE nb_NO nn_NO ; do echo "$l:" ; LC_ALL=$l.UTF-8 ./printfbug 1 10 100 1000 10000 100000 1000000 10000000 done Output: en_US: Thousands Separator: <,> double < 1> int < 1> double < 10> int < 10> double < 100> int < 100> double < 1,000> int < 1,000> double < 10,000> int < 10,000> double < 100,000> int < 100,000> double < 1,000,000> int < 1,000,000> double <10,000,000> int <10,000,000> de_DE: Thousands Separator: <.> double < 1> int < 1> double < 10> int < 10> double < 100> int < 100> double < 1.000> int < 1.000> double < 10.000> int < 10.000> double < 100.000> int < 100.000> double < 1.000.000> int < 1.000.000> double <10.000.000> int <10.000.000> nb_NO: Thousands Separator: < > double < 1> int < 1> double < 10> int < 10> double < 100> int < 100> double < 1 000> int < 1 000> double < 10 000> int < 10 000> double < 100 000> int < 100 000> double < 1 000 000> int <1 000 000> double <10 000 000> int <10 000 000> nn_NO: Thousands Separator: < > double < 1> int < 1> double < 10> int < 10> double < 100> int < 100> double < 1 000> int < 1 000> double < 10 000> int < 10 000> double < 100 000> int < 100 000> double < 1 000 000> int <1 000 000> double <10 000 000> int <10 000 000> That is, en_US and de_DE are fine (they use ',' and '.' as thousands separator). But nb_NO and nn_NO produce the wrong output when using integers (%'10d). However, float is fine as well (%'10.0f). For nb_NO and nn_NO, the separator is a 3-byte UTF-8 character 0xe2 0x80 0xaf, which is UTF-8 NARROW NO-BREAK SPACE -> https://www.fileformat.info/info/unicode/char/202f/index.htm . It seems that for integer formatting, the number of bytes is processed, instead of counting the actual characters. For float formatting, the number of characters is counted correctly. That is: $ LC_ALL=nb_NO.UTF-8 ./printfbug 1000 | hexdump -C 00000000 54 68 6f 75 73 61 6e 64 73 20 53 65 70 61 72 61 |Thousands Separa| 00000010 74 6f 72 3a 20 3c e2 80 af 3e 0a 64 6f 75 62 6c |tor: <...>.doubl| 00000020 65 20 3c 20 20 20 20 20 31 e2 80 af 30 30 30 3e |e < 1...000>| 00000030 09 69 6e 74 20 3c 20 20 20 31 e2 80 af 30 30 30 |.int < 1...000| 00000040 3e 0a |>.| 00000042 I can reproduce the issue under Ubuntu 22.04, Ubuntu 24.04 (development version), and Fedora 39. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2024-03-24 9:42 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-24 9:42 dreibh at simula dot no [this message] 2024-03-25 14:34 ` [Bug locale/31542] " schwab@linux-m68k.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-31542-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).