[bug #42233] wcwidth(3) used on UCS4/UTF-32 codepoints

[anonymous]

Follow-up Comment #1, bug #42233 (project groff):

Hm.  After updating my ArchLinux the test program `uniwidth.c' shows two
errors which i haven't seen a month ago.

For one wcwidth(3) now returns `2' for 64 HEXAGRAM's (U+4DC0-U+4DFF; HEXAGRAM
FOR THE CREATIVE HEAVEN - HEXAGRAM FOR BEFORE COMPLETION).  This i claim wrong
again, because the Unicode `EastAsianWidth.txt' clearly classifies them with
the East_Asian_Width property `N' (<http://www.unicode.org/reports/tr11/>).

Second, when compiled with `-DLIBUNISTRING -lunistring' the program crashes
because the GNULib function uc_width() doesn't seem to allow NULL now; when
changing the NULL to "utf-8" i know get 107 inequalities.  What i yet have
looked at i am right: e.g., U+2EF4 is not currently assigned in Unicode and
therefore must be treated as `N'; it is very likely that it will be fullwidth
once it is assigned, since it is in the CJK range, however.  Ditto U+3040
(HIRAGANA), U+A48D (YI SYLLABLE) ... and most likely etc.

P.S.: oops, i have no account!  this is sdaoden AT yandex DOT com.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?42233>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/