アカウント名:
パスワード:
ちなみに、HANDLE_M
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
重い (スコア: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さん> はないかと思います。 (使う人は、いるのかなあ)
mbstate_t があるからといって、stateful encoding 対応というわけではないですね。
mbrtowc() を例にとると以下のような使い方かもしれないからです。
mbrtowc()の戻り値は、
与えられたバイト列がワイド文字に変換するのに何バイトか足りなくて変換できないなら(size_t)-2
与えられたバイト列の後にどんなバイトが来ようがもはやワイド文字に変換できないなら(size_t)-1
mbtowc() の戻り値は
とにかく変換に失敗すれば(size_t)-1
だから、mbrtowc()を使えば、以下のようにどっかから1byteずつ取ってきて、文字に変換するという方法が使えますが，mbtowc()ではできません。
*) get_one_byte()はどこぞから1byteとってくる関数とします。
char *str;
int num;
wchar_t wc;
mbstate_t st;
size_t ret;
str = (char *) malloc (MB_CUR_MAX);
memset (&st, '\0', sizeof(mbstate_t));
for (num = 0; num MB_CUR_MAX; num++) {
str[num] = get_one_byte ();
ret = mbrtowc (&wc, str, MB_CUR_MAX, &st);
if (ret == (size_t)-2) {
memset (&st, '\0', sizeof(mbstate_t));
continue; /* ワイド文字に変換するにはバイトが足んない */
} else if (ret == (size_t)-1) {
エラー処理 /* ワイド文字に変換できなかった */
}
}
.
.
. ワイド文字を使った処理
.
.
# ほかにも，スレッドセーフにしたいときなどが考えられます。
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 に依存しないし。