Ikumi Keita
ikumi****@rever*****
2004年 3月 4日 (木) 01:14:27 JST
井汲です。Canna ML の過去ログで報告されていた問題点のうち、ML 内で解決
に至っていないものを一通り調べてみました。
中には、sourceforge に移ってから解決済みのものも交じっているかもしれま
せんが、私にはちょっと判断がつかないので、そのまま含めておきます。
■ ソケットをおさめるディレクトリのパーミッション
[Canna 5376] より。
>> % cd /tmp/.iroha
>> % mv IROHA IROHA.old
>> % ln -s /etc/passwd IROHA
>>
>> とかされると、以降はcanna serverを使えなくなる。一種のDoS(Denial of
>> Service)? と見ることもできます。
> やはりディレクトリのモードが 0777 なのは問題がありそうですね。
> 01777 にした方が良いですね。ソースを修正しようと思います。
> しかし、いずれにせよすでに
> % cd /tmp ; ln -s /etc/passwd .iroha_unix
> だけでアウトって気もします。まあ、cannaserver が UNIX の起動
> 時に起動してあればこちらは防げるわけですが。
>> また、このまま/tmpの内容が残ったままでcanna serverを再起動すると恐いかな
>> とも思ったのですが、きっと何かファイルが存在してればUNIXドメインのソケッ
>> トは作成できないでしょうから(未確認)、問題ないでしょう。
>>
>> % ln -s /dev/log IROHA
>>
>> とかされると嫌かもしれません。;-(
> たしかにそうですね。この場合は神戸さんがおっしゃる通り UNIX
> ドメインでは接続できなくなると思います。
■ バッファサイズが足りない？
[Canna 5449] と [Canna 5450] のやりとりを再録します。
[Canna 5449]
> lib/parse.c で
> #define BUF_LEN 1024
> static char CANNA_rcfilename[BUF_LEN] = "";
> と確保していますが、たとえば parse() には次のコード片があります。
> if (initFileSpecified) {
> strcpy(CANNA_rcfilename, initFileSpecified);
> if (YYparse_by_rcfilename(CANNA_rcfilename)) {
> make_initfilename();
> goto quitparse;
> }
> else {
> char buf[256];
> if (ckverbose) {
> printf("カスタマイズファイルは読み込みません。\n");
> }
> sprintf(buf, "指定されたカスタマイズファイル %s が存在しません。",
> CANNA_rcfilename);
> addWarningMesg(buf);
> goto quitparse;
> }
> }
> initFileSpecified が 210 文字くらいあると buf[256] はかんたんにあふ
> れるような気がするのですが、256 で確保している事に何か意図があるので
> しょうか? いろいろな場所で 256 という数字が使われているようですが、
> 2048 程度であるべきなような気がするのですが……。
[Canna 5450]
>> initFileSpecified が 210 文字くらいあると buf[256] はかんたんにあふ
>> れるような気がするのですが、256 で確保している事に何か意図があるので
>> しょうか? いろいろな場所で 256 という数字が使われているようですが、
> コードを書いた方の単なる気持ち、それ以上でも以下でもないでしょう。
> ただの256という魔法の数字を使う時点でそうです。
>> 2048 程度であるべきなような気がするのですが……。
> UNIXのパス名については1024バイトを用意しておけば十分だった気がしますが、
> いずれにしろバッファの溢れを警戒するならstrcpy()とかsprintf(3)とかを止め
> て、strncpy(3)やsnprintf(3)を使用する様に変更していく必要があります。
> (snprintf(3)は持ってないOSも多いでしょうけど。)
■ SunOS 4.1 の cc によるコンパイルエラー
[Canna 4732] に以下のような報告があります。ここで名前の挙がっている
empty.c 以下のファイルは、現在でも指摘されているような形式で文字列定数が
使われているようです。
今さら SunOS 4.1 のような古い OS でかんなを使うことはないでしょうし、
わざわざ直すほどのことはないかもしれません。
> [Canna 4489] で私が、
>> 例えば lib/canna/bushu.c 等で、次のようなエラーが出ています。
>> "bushu.c", line 610: syntax error at or near string "\274\272\307\324\244...
> と報告し、それに対し今さんが [Canna 4490] で、
>> こちらは a = "foo" "baa"; のような文字列定数の使い方をしてい
>> るのが原因かと思われます。a = "foobar"; のように書き直します。
> と言われているのですが、私が報告の中で具体例として "bushu.c" しか
> 上げなかった為に、"bushu.c" しか修正されていませんでした。
> 実際には、"bushu.c" 以外に "chikuji.c","empty.c","henkan.c",
> "ichiran.c","kctrl.c","kigo.c","mode.c","parse.c","romaji.c",
> "uiutil.c","uldefine.c","uldelete.c","ulmount.c","util.c" で同じ問
> 題が起きています。
> [Canna 4490] で今さんが言われている方法で、これらを修正したところ、
> 無事コンパイルする事が出来ました。
■ バージョン表示
[Canna 4844] で、今さんが次のように述べています。
>> 一つは、Muleから canna-extend-modeでサーバのバージョン表示をさせ
>> ると、最初につないだものしかでません。途中で、前のバージョン
>> (3.2)のかんなにつないでも、バージョン表示は 3.5 beta2 と出てしま
>> います。
> あれれ〜。これはバグだねえ(それもずーっと前からの(^^;))。対
> 処します。
これがバグだとすると、現在も同じ状態のままのようです。（ただ、本当にバ
グかどうかちょっと疑問が残ります。環境設定→バージョン表示で表示されるべ
きものは、cannaserver のバージョンと libcanna のバージョンのどちらでしょ
うか。もし後者が意図されているのだとすれば、これこそが正しい動作というこ
とになりますが…）
■ 付属語辞書が、バイナリ形式からテキスト形式へ変更できない
[Canna 4881] より。
> 今さん> また、岩波辞書を一度 3.2 でテキストに戻して 3.5 でバイナリに
> 今さん> 変換するということでも利用できるかと思われます。(※岩波辞書
> 今さん> の版権/著作権にご注意下さい)
> ご忠告ありがとうございます．もし，その方法を使うときには注意します．
> この方法を用いるとき，suffixのような付属語辞書のバイナリ辞書をうまく
> テキスト辞書に戻すことができません．何か方法はありますでしょうか？
■ 学習の問題
[Canna 5001] には以下のように述べられています。学習については相田さん
がだいぶ手を入れられたようなので、現状ではこの問題はないのかもしれません。
>> ※文節伸ばしで変換候補が尽きたところでカタカナになりますが、そこで、
>> C-nで平仮名に直して確定しても、カタカナの状態で学習される。
>>
>> (例文は適当なのが思い付きませんでした。)
>>
>> 変換の候補一覧で最後に出て来る、文節全部がカタカナの候補と文節全部が平仮
>> 名の候補は、内部的な扱いが異なるように思うので、何かあるんだと思います。
> いや、ひらがなとカタカナの候補の違いはないです。文節区切り学習は、ど
> ういう読みで文節を切ったかだけを覚えていて、どの候補で確定したかは覚
> えてないんです。
> 文節を伸ばして変換候補が尽きたときに、一番最初に出るのがカタカナの候
> 補なので、文節区切り学習が効いて、変換候補がない位置で文節が切れると、
> やっぱりカタカナの候補が出てしまいます。
> これはどうしたものかな。
■ temporary の効果が quit で消えない
[Canna 5284]より。これがどれくらい重要なものなのか（そして、そもそも本
当にバグなのか）、私には判断がつきませんが、一応。
> 英語を入力しやすくするのならtemporaryを駆使して、
> (set-key 'empty-mode "/" '(temporary base-eisu base-hankaku))
> なんてのはどうでしょう。/を押すと半角英数になり、一度確定すると
> 元のモードに戻ります。ただし、'quitしたときに元に戻らないバグが
> あるのが難点。
> ＃ 10年前に直すといっていた気がするけど… ＞ 今さん
■ プロトコルについて
[Canna 5525] より。これも私にはチンプンカンプンです。
> RemoveYomi は INT8 で文節数を返すようになっていますが
> (もし WIDE_PROTO が undefined な場合。server/wconvert.c の
> irw_remove_bun() -> lib/RK/bun.c の RkwRemoveBun() と呼ばれてるっぽい？)
> まず
> 1) doc/intern/protocol.tex の記述と違う
> ここでは 0/-1 を返すと、かかれている
> 2) そもそも INT8 (Type2) で文節数を返すことに違和感を覚える。
> 他では文節数は INT16 を使っていますよね。
> という二点が気になっています。protocol.tex に従って 0/-1 を返す
> かんなサーバー(某esecannaserverですが)では RemoveYomi が呼ばれると
> 呼んだクライアントの変換バッファの表示がとち狂います。
■ 文法辞書を作るコマンドのリクエスト
[Canna 2736] より。
> ・mkgramdic が欲しい
> 自立語辞書と比べて、文法辞書は作りにくいので、mkgramdic という
> コマンドを作って、
> ../../../cmd/forcpp/forcpp -7 < gram.code | /usr/bin/cpp -USX | ../../../cmd/forcpp/forcpp -8 > cpp.gram
> ../../../cmd/crxgram/crxgram -f cpp.gram
> Undefined row vectors: BM
> rows 499 cols 348
> ../../../cmd/forsort/forsort -7 < cnj.swd | sort | ../../../cmd/forsort/forsort -8 | ../../../cmd/mergewd/mergeword > fuzokugo.swd
> ../../../cmd/crxdic/crxdic -s -o fuzokugo.d -D cnj.bits -n fuzokugo fuzokugo.swd
> fuzokugo.swd [ Mon Jun 20 09:34:41 1994 ] = 305 + 182
> cat cnj.bits >> fuzokugo.d
> ../../../cmd/crfreq/crfreq fuzokugo.d fuzokugo.swd
> FQ size 886 bits 111 bytes
> の部分を一つの操作で簡便に作れるようにして頂ければ、一般の
> ユーザにとって、文法辞書作りがいっそう簡単になると思います。
■ 機能のリクエスト
[Canna 4302] より。話を簡単にするため、canna.el に対するリクエストは除
いてあります。
> ・どうせ変換しないんだから、ユーティリティメニューで「連文節」「逐次」
> の他に「無変換」を入れたい。
> ・長い文字列を canna-henkan-region で変換すると、途中から先が捨て
> られてしまう。仮名にして 320 文字から先は、消えてしまう。320 文字
> より長い文字列を変換できる必要はないが、320 文字目から先を捨てないで
> ほしい。ついでに言うと、連文節変換で入力できる仮名は 200 文字強
> （文字列によって違うが）だが、もう少し長いと（320文字までいけると）
> 嬉しい。
井汲 景太