wcwidth と East Asian Ambiguous Character Width 問題

ことの発端@Cygwin-ML

こりーな「CJK Ambiguous Width は無視するぜ!!」
おれ「冗談ぢゃねぇ、LC_CTYPE=ja, ko, vi, zhなら2を返せ*1
こりーな「おk」
とます「かくかくしかじかという問題があるし、そもそもそんなworkaroundは許せん」
おれ「そういう実装もあるらしい(*1のこと)ぞ。それに、おまいの言ってることは実用上問題にはならん」←いまココ

次の反論説得対策にakrさんの言ってるような実装を探してみる

が、見付からない……。

#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
#include <wchar.h>
int main(void) {
  wchar_t w[] = L"α■";
  wchar_t *wp;
  int i;
  setlocale(LC_ALL, "ja_JP.UTF-8");
  for (wp = w; *wp; wp++)
    printf("%06X[%lc]: %d\n", *wp, *wp, wcwidth(*wp));
  return 0;
}
Debian lenny (glibc) 0003B1[α]: 1 / 0025A0[■]: 1
CentOS-5.3 (glibc) 0003B1[α]: 1 / 0025A0[■]: 1
FreeBSD-7.2 0003B1[α]: 1 / 0025A0[■]: 1
NetBSD-5.0 0003B1[α]: 1 / 0025A0[■]: 1
Solaris 10 0003B1[α]: 1 / 0025A0[■]: 2

うーん。特にSolaris 10はわけわからん……。どなたか、上のコードのどちらも2になる処理系をご存知でしたら教えてください。

East Asian Ambiguous Character Width に対する wcwidth はどうあるべきか

俺はCJK(Vも?)の場合は2になるべきだと思うんだけど、glibcにも*BSDにも入ってないのは何で? kubotaさん(debianとこのホームが消えてる……)とか、Citrusな人とかが活動してたはずなんだけど、そこらへんの状況が今一つわからん。

調べてみると個別パッチだらけなので、いい加減なんとかならんもんか……。

*1:[mule-ja-2009:09582]より、akrさん曰く「wcwidth と wcswidth がそうなんじゃないでしょうか。LC_CTYPE に依存して決まります」とのこと。なんかMLのアーカイブ変換が止まってるようでリンク張れない。