[Bug locale/33741] New: In UTF-8 locales, wcwidth on U+FE0F VARIATION SELECTOR-16 (VS16) returns 0 instead of -1

[vincent-srcware at vinc17 dot net]

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

            Bug ID: 33741
           Summary: In UTF-8 locales, wcwidth on U+FE0F VARIATION
                    SELECTOR-16 (VS16) returns 0 instead of -1
           Product: glibc
           Version: 2.42
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: locale
          Assignee: unassigned at sourceware dot org
          Reporter: vincent-srcware at vinc17 dot net
  Target Milestone: ---

In UTF-8 locales, wcwidth on U+FE0F VARIATION SELECTOR-16 (VS16) returns 0
instead of -1:

#define _XOPEN_SOURCE
#include <locale.h>
#include <stdio.h>
#include <wchar.h>
int main (void)
{
  setlocale (LC_ALL, "C.UTF-8");
  printf ("%d\n", wcwidth (0xfe0f));
  return 0;
}

The issue is that the VS16 character may change the width of the previous
character if this character is an emoji. So, depending on the context, the
cursor position may change. This means that the actual width cannot be
determined unambiguously.

In short, such a character needs to be handled specifically by the software
that is based on wcwidth, by using the context (whether the previous character
is an emoji or not) and the terminal settings, since the actual behavior
depends on the terminal. A value -1 should ensure that nothing wrong is done
(e.g. this character will not be printed if not supported).

Currently the value 0 yields output issues with "xterm -emoji_width" (option
added in xterm 406; versions 404 and 405 had it set by default), in particular
with the curses application Mutt.

See also the related bug 32322 about wcswidth.

About xterm and the VS16 character:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1123509

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