アカウント名:
パスワード:
ちなみに、HANDLE_M
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
重い (スコア:3, 興味深い)
そんなに多バイト文字つかいたいんですか?
まあ、メモリ一桁メガバイトの住人のたわごとか。
------------------------- Excess and Obsolete
軽いシェル (スコア:4, 参考になる)
ちなみに、HANDLE_M
stateful なエンコーディング (スコア:2, 興味深い)
>に、mbstate_t が多数使われていることにも気付きました。 おそらく、
>stateful なエンコーディング (ISO-2022-JP など) にも対応しているので
>はないかと思います。 (使う人は、いるのかなあ)
Linux上の話に限定してしまえば、bashがstatefulなエンコーディングをサポートしていようがいまいがglibcがそもそもstatefulなエンコーディングをサポートしていないはずなので関係ないと思います。が、世の中にはLinux以外のOSも数多く存在してますので、使う人もいる
Re:stateful なエンコーディング (スコア:1, 参考になる)
mbrtowc() などの再開始可能な関数を使うなら,別にstatefulなエンコーディングじゃなくても,最初にシフト状態は初期化せねばならないかと。
あと,
kubotaさん> ちなみに、HANDLE_MULTIBYTE を見付けるためにソースを漁っている 最中
kubotaさん> に、mbstate_t が多数使われていることにも気付きました。 おそらく、
kubotaさん> stateful なエンコーディング (ISO-2022-JP など) にも対応しているので
kubotaさん> はないかと思います。 (使う人は、い
Re:stateful なエンコーディング (スコア:1)
あ、すみません。もちろん最初にシフト状態は初期化しないといけません。私の送ったパッチはそこにバグをいれてしまっていたのですが、statelessなエンコーディングを利用している場合、すくすく動作してしまっていたので...。
IBMの作成していた国際化部分では、mbrtowcの戻り値のチェックはそれほど厳密にやっていません。-1の場合も-2の場合も同様のものとして扱っています。
僕が知る範囲では、mbrtowcをまっとうに利用しているアプリケーションは非常に少ないですね。IBMが作成しているパッチでは、全てmbrtowcを利用するようになっていて、企業としてのポリシーを感じます。
> # ほかにも,スレッドセーフにしたいときなどが考えられます。
少なくともglibcの実装では、mbtowcは内部でmbstate_tを利用しているので、mbrtowcを利用しないとスレッドセーフにはならないですね。
Re:stateful なエンコーディング (スコア:0)
input.c とかを覗くとやってるみたいに見える。
Re:stateful なエンコーディング (スコア:0)
Re:stateful なエンコーディング (スコア:0)
2.04 の patch もあったと思うけど、もうないのかな?
Re:stateful なエンコーディング (スコア:0)
再開始可能な関数を使ったほうがいいです。
glibcを例にとりますと,glibcはmbswcs系関数で関数内で処理をする際,
mbstate_tに変換途中の情報を入れてます。
だから,mbtowcは,スレッドセーフになってないわけです。
(コメントから察するにこの辺のことはご存知だと思われますが。)
では,mbtowcでエラーが返ったとき,内部に持っているmbstate_tはどうなるでしょう?
添付のコードを試されると判ります。
といっても ja_JP.SJISロケール向けハードコードですので(すいません),
結果をばここに。
$ ./mb
Re:stateful なエンコーディング (スコア:0)
でも,「手元で状態を把握していたほうがいい。」っていうことを示したいなら,
EUC の Single Shift を例にしたほうがいいかと。
それなら別に glibc に依存しないし。