アカウント名:
パスワード:
ちなみに、HANDLE_MULTIBYTE を見付けるためにソースを漁っている 最中に、mbstate_t が多数使われていることにも気付きました。 おそらく、stateful なエンコーディング (ISO-2022-JP など) にも対応しているのではないかと思います。 (使う人は、いるのかなあ)
ちなみに、ぼくはメモリ 12MB のマシンを持っていますが、 bash が重いと思ったことはありませんが、 さすがに emacs は重いと思いました。
軽いシェルですが、NetBSD の sh (Debian では ash という名前でパッケージングされています) は、 POSIX シェルです (#!/bin/sh として使える) が、 非常に軽いですよ。そのかわり、機能がかなり制限されますが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
重い (スコア:3, 興味深い)
そんなに多バイト文字つかいたいんですか？
まあ、メモリ一桁メガバイトの住人のたわごとか。
------------------------- Excess and Obsolete
軽いシェル (スコア:4, 参考になる)
ちなみに、HANDLE_MULTIBYTE を見付けるためにソースを漁っている 最中に、mbstate_t が多数使われていることにも気付きました。 おそらく、stateful なエンコーディング (ISO-2022-JP など) にも対応しているのではないかと思います。 (使う人は、いるのかなあ)
ちなみに、ぼくはメモリ 12MB のマシンを持っていますが、 bash が重いと思ったことはありませんが、 さすがに emacs は重いと思いました。
軽いシェルですが、NetBSD の sh (Debian では ash という名前でパッケージングされています) は、 POSIX シェルです (#!/bin/sh として使える) が、 非常に軽いですよ。そのかわり、機能がかなり制限されますが。
Re:軽いシェル (スコア:2, 参考になる)
ash は POSIX/SUSv3 には準拠していないが、 FreeBSD の /bin/sh は FreeBSD C99 & POSIX Conformance Project [freebsd.org] で準拠のための作業が進行中。NetBSD とFreeBSD では変更を相互にマージしている。
POSIX には不備やほとんど無意味な規定もあるから完全準拠の是非は微妙だが、可能な範囲で擦り寄ることは大事、かな。
stateful なエンコーディング (スコア:2, 興味深い)
>に、mbstate_t が多数使われていることにも気付きました。 おそらく、
>stateful なエンコーディング (ISO-2022-JP など) にも対応しているので
>はないかと思います。 (使う人は、いるのかなあ)
Linux上の話に限定してしまえば、bashがstatefulなエンコーディングをサポートしていようがいまいがglibcがそもそもstatefulなエンコーディングをサポートしていないはずなので関係ないと思います。が、世の中にはLinux以外のOSも数多く存在してますので、使う人もいると思います。
今は亡きKondaraにおいてこのパッチを採用した際に、パフォーマンスが劇的に悪くなった、と文句しこたまいわれたりしたので、1バイトで事足りるようなロカールの場合にはマルチバイト文字ワイド文字の変換をスキップするようにした(他にword wrapやいくつかのバグつぶし)パッチをIBMの方に送付したのですが、この時に「mbstate_tを初期化してないためにstatefulなエンコーディングで正常に動作しません。」と注意された記憶があります。
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 に依存しないし。