2 ms·
The entire wchar_t API is hopelessly broken. It isn't guaranteed to represent Unicode nor is it guaranteed to be UTF-32. Unicode has a large number of codepoint
by kevin_thibedeau 2y ago
The entire wchar_t API is hopelessly broken. It isn't guaranteed to represent Unicode nor is it guaranteed to be UTF-32. Unicode has a large number of codepoints designated as ambiguous width. This is largely due to existing narrow text presentation symbols being gifted a wide emoji representation. Which width is the default is heavily dependent on the font(s) in use and your rendering engine. Gnome VTE has a configuration option to set the default width for ambiguous codepoints.
Any program has to expect wide, narrow, or an inconsistent mixture of both if font substitutions are invoked. With no actual API to reliably discover a codepoint display width, your best option is to print some candidates and check the cursor position as a heuristic.
- int_19h 2y agoFWIW, wchar_t is guaranteed to be Unicode if __STDC_ISO_10646__ is defined, which is the case on Linux/glibc. It's too bad that other platforms are lagging behind on this - there's really no good reason to not guarantee this in 2024. Windows at least has the excuse of having wchar_t be 16-bit which they can't change for legacy compat reasons, but that doesn't explain why e.g. FreeBSD isn't there yet.