weechat uses libc's wcswidth #79

Aerdan opened this Issue May 8, 2014 · 14 comments


None yet

7 participants

Aerdan commented May 8, 2014

Weechat uses the libc's wcswidth, which is implemented in terms of the libc's wcwidth, typically. Unfortunately, glibc's wcwidth is rather out of date and therefore untrustworthy. weechat should, instead, import mgk25's wcwidth/wcswidth implementations. I believe this will permit weechat to support Unicode more correctly.


We discussed some hours ago about UTF-8 problems in WeeChat, about this answer: http://stackoverflow.com/questions/23526353/how-to-get-ncurses-to-output-astral-plane-unicode-characters/ (the source code example in this question is from me).
So according to the answer, the problem is not in WeeChat, but in glibc.
What would be the benefit of using your mgk25's wcwidth?

godeater commented May 8, 2014

I can confirm that using the method in the answer for modifying your locale works perfectly too. I've now added a further 1000 or so code points to my locale using it, and weechat is rendering them fine now :


Aerdan commented May 8, 2014

Okay, sure. I'm just commenting about this based on the observation that wee-utf8.c uses glibc's wcswidth, which is dependent on glibc's wcwidth and is therefore broken. mgk25's version is more up to date, and includes documentation on how to keep it up to date as new Unicode standards are released--which is important, because glibc is clearly not keeping up.


If glibc is broken, then why not fixing it?
I know it could be hard, but then all programs using it will be fixed, it's IMHO better than using other implementations.

Aerdan commented May 10, 2014

It is not possible to fix glibc and ensure the fix is available everywhere.
By carrying a solution which does not rely on glibc, weechat can ensure it
is correct everywhere it compiles, without having to trust the libc to be
up to date. Besides, wcwidth does not guarantee that its results are
compliant with any particular standard, so it is technically correct for it
to behave in a manner we would construe to be misbehaviour.

On Sat, May 10, 2014 at 12:32 AM, Sébastien Helleu <notifications@github.com


If glibc is broken, then why not fixing it?
I know it could be hard, but then all programs using it will be fixed,
it's IMHO better than using other implementations.

Reply to this email directly or view it on GitHubhttps://github.com/weechat/weechat/issues/79#issuecomment-42732388

@flashcode flashcode added the bug label May 25, 2014
kyrias commented Sep 17, 2014

A person has started working on updating glibc's locale data (bug report), tho one person has reported that he couldn't apply the patch. But at least it's being worked on.


Definitely a glibc bug, not WeeChat. And it looks like they're working on the problem, so I close this issue.

@flashcode flashcode closed this Oct 15, 2014
@flashcode flashcode self-assigned this Nov 16, 2014
@flashcode flashcode added the won't fix label Nov 16, 2014
Aerdan commented May 22, 2015

Yup, but that's basically just externalizing the workaround I opened this bug to offer.

kaniini commented May 22, 2015

It should be fixed in glibc. Overriding wcswidth (or any other libc symbol) is undefined behaviour and otherwise creates unnecessary maintenance burden.

Mikaela commented May 23, 2015

I believe this is fixed in glibc 2.22, but too recent glibc to be in any distribution yet.

Changed 2.21 to 2.22 based on the following comment.

kyrias commented May 23, 2015

It was committed after the 2.21 release, but should be fixed in the next one.


This is fixed in glibc.

Don't blame glibc versions, blame your distro for using outdated versions. I've been running glibc from git for awhile without issue. Most distributions are just bad and insecure.

As an addendum, weechat did the right thing here. It should never have used its own implementation of wcwidth (/me looks at konsole), this is distinctly the job of the libc and should be fixed there (which it was). Many thanks to Alexandre Oliva and Mike FABIAN for this work.



@Earnestly: not really related, but maybe you have an idea for this problem? #258 (comment)

@Mikaela Mikaela referenced this issue in ircv3/ircv3-specifications May 4, 2016

Allow Unicode in nicknames #259

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment