diary/Kojima

・a2ps のマージン

a2ps の再ビルドのついでに、用紙のマージンを調整してみた。 手元で使っている HP OfficeJet ProK550 だと、デフォルトで登録されている A4dj だと上のマージンが広く、 下のマージンが狭いので、これくらいで丁度いいみたい。

# Desk Jet users: bigger margins
#Medium: A4dj           595     842     24      50      571     818
Medium: A4dj            595     842     24      40      571     770

・file-roller のデバッグ(その3)

先日の修正ではオプションのパースが終った後、UTF-8になっている remaining_args[] を filename にコピーする際に locale に合わせるように変更していたけど、メンテナ ML で本多さんに「オプション・パース時の設定では?」という指摘をいただいて、 改めて調べてみたらこっちがビンゴだった。

具体的には、main.c で、引数の解析方法を設定している GOPtionEntry options[] は、

static const GOptionEntry options[] = {
        { "add-to", 'a', 0, G_OPTION_ARG_STRING, &add_to,
           N_("Add files to the specified archive and quit the program"),
          N_("ARCHIVE") },
....
       { G_OPTION_REMAINING, 0, 0, G_OPTION_ARG_STRING_ARRAY, &remaining_args,
         NULL,
         NULL },

       { NULL }
};

となっていて、&remainig_args は G_OPTION_ARGS_STRING_ARRAY の指定で文字列であると解釈され、 UTF-8 に変換されて返ることになる。一方、この部分を G_OPTION_ARGS_FILENAME_ARRAY としてやると、 &remainig_args はファイル名であると解釈され、locale に応じたファイル名として返ることになる。

確かに、先に引用したマニュアルもきちんと読むと、「string は UTF-8 で返るけど、ファイル名は Glib filename encoding で返る」と書いてあるので、 これが正しい動作だろう。

結論的には、Glib では文字列の扱い(UTF-8)とファイル名の扱い(Glib filename encoding)は異なっているのだけど、 file-roller の作者は、与えられた引数のうちオプション部分のパースが終った残りについて、本来はファイル名とすべきところを、 文字列と考えてしまった、ということなんだろうな。

まぁ、ASCII な世界とか UTF-8 な世界だと、ファイル名と文字列のエンコーディングは一致するから両者を混同しても問題にはならないので、 露呈しにくい類いのバグとは言えそうだ。

今回は久しぶりに C のソースコードのデバッグをしてみたけど、あちこちにバラまいた printf 文の出力を手がかりに、いくつもの仮説を作っては壊し、 転びまろびつしながら問題箇所を絞り込んでいって、最終的に今までの断片的な情報がそれぞれの場所に収まって、ジグソーパズルの図柄が表われる、 というのは問題解決の醍醐味だなぁ。この "eureka!!" 的な快感が癖になってしまって、この世界から抜けられなくなってしまっている気がする(苦笑



トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2021-12-17 (金) 16:35:41