[Bug localedata/19852] New: [2.22 Regression] Incorrect wcwidth for U+3099 and U+309A

["egmont at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19852

            Bug ID: 19852
           Summary: [2.22 Regression] Incorrect wcwidth for U+3099 and
                    U+309A
           Product: glibc
           Version: 2.23
            Status: NEW
          Severity: normal
          Priority: P2
         Component: localedata
          Assignee: unassigned at sourceware dot org
          Reporter: egmont at gmail dot com
                CC: libc-locales at sourceware dot org
  Target Milestone: ---

(After running setlocale() with en_US.UTF-8 or something similar)

wcwidth() for U+3099 and U+309A (and presumably a few others) returns:

 0 in glibc up to 2.21,
 2 in glibc 2.22 & 2.23.

Quoting from Unicode 8.0:

http://unicode.org/reports/tr11/

"ED4. East Asian Wide (W): All other characters that are always wide."

"6.2 Combining Marks [...] nonspacing marks used only with wide characters are
given a W."

http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt

"3099..309A;W     # Mn     [2] COMBINING [...]"

According to these, I believe the correct return value would be 0 (it's a
non-spacing mark).

Markus Kuhn's wcwidth (https://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c) also
returns 0.

We found this originally being reported against VTE (the terminal emulation
widget behind gnome-terminal and others) causing incorrect look there:
https://bugzilla.gnome.org/show_bug.cgi?id=762052. The conclusion there
(beginning at comment:22) was also the same: it should return 0.

-- 
You are receiving this mail because:
You are on the CC list for the bug.