AIDA Shinra
aida-****@jcom*****
2002年 12月 28日 (土) 15:22:19 JST
相田です。 kinput2,canuum,emacsの他に、Q's Nicolatterしか出て来ないようなので、いっ たん調査は打ち切ります。実質wc系は16ビット版しか使われていないとなれば、 対応は割と気楽にできそうです。 まず、wchar_tの問題点を整理すると、 1. wchar_tは本来ASCII互換部分以外は実装依存であり、サイズも16ビットの 場合と32ビットの場合がある。最近のシステムでは32ビットが主流だが、 cygwinでは16ビットである。 2. にも関わらず、libcanna16ではOS側の定義を無理矢理奪って、16ビットの wchar_tを定義している。このためコンパイルエラーが生じたり、定義の変更 に失敗したりする。 3. また、libcannaではwchar_tの大きさが分からない。 4. WCHAR16でない場合に、widedef.hにある replace this with #include or typedef appropriate for your system の部分はどう定義されるか分からない。従って、誰がコンパイルしたかによっ てABIの違うlibcannaが出来ることになる。 5. cannaのwchar_tはOSのワイドキャラクタのAPIで扱うことは出来ず、自前で 変換ルーチンを用意しなければならないが、これは紛らわしい。 という状況です。現在既にlibcannaのABIが不確定になっているため、バイナ リ互換を完全に確保することは出来ない状況に陥っています。 これを踏まえた上で、私の出した結論は、2.が起こっているOSではどうせ cannaをコンパイル出来ないので、新しいワイドキャラクタのみをサポートし、 cannaのコンパイルが出来ているシステムでは、古いワイドキャラクタを同時 にサポートする、というものです。ワイドキャラクタを変えれば、バイナリレ ベルだけでなくソースレベルでも互換性が無くなるので、マクロで明示的に 切替える形がいいと思います。そうなると新しいAPIが気付かれず、古いAPIが 使われ続ける可能性があるので、GNU ldのwarningの機能を使って乗り換えを 促します。 これが私の考えですが、変にマクロでAPIを切替えたりすると複雑なincludeで 困らないかとか、jrKanji*に統一すればいいだろうとか、色々異論もあると思 います。別の方向を推すなら、今のうちに反対してください。
