[ruby-dev:35611] Re: [request]C APIの拡張

ご意見ありがとうございます。

1. 動機

まず，背景となる動機の説明が不十分だったことをお詫びします。

もともと強く欲しいと思ったのはrb_str_catf()で，これはライブラリ側で簡易かつ効率よく実装するのが難しいため，今回の要望を出すに至りました。
もちろん，使用するのが私だけだとしたら独りよがりな要望です。そこでRubyのソースコードで/\bsn?printf/が使われている状況も調べました（以下の記述は2008年7月16日版に基づきます）。

1.1 rb_str_catf()の需要

たとえば，以下のようなコードがiseq.cにあります。

#line 747 iseq.c (ruby_iseq_disasm_insn())
    snprintf(buff, sizeof(buff), "%04d %-16s ", pos, insn_name_buff);
    rb_str_cat2(str, buff);

これはrb_str_catf()があれば以下のように記述できます（実際にはさらにbuffの宣言も削除できます）。

    rb_str_catf(str, "%04d %-16s ", pos, insn_name_buff);

この書き換えの結果，sizeof(buff)の妥当性の検証が不要になり，保守しやすくなると思われます。

同様のコードがiseq.cのruby_iseq_disasm()の843行目付近と885行目付近，process.cのps_message()，file.cのrb_stat_inspec()などにみられます。拡張ライブラリについては詳しく調べていませんが，bigdecimalなどでsprintf()を多用しているようです。

このことから，catf()についてはそれなりの需要があるのではないかと考えました。

1.2 rb_str_newf()の需要

また，この調査の結果，catf()の用途以外でもs(n)printf()が多用されていることに気付きました。たとえば，error.cのrb_name_error()において以下の記述があります。

#line 624 error.c
    char buf[BUFSIZ];

    va_start(args, fmt);
    vsnprintf(buf, BUFSIZ, fmt, args);
    va_end(args);

    argv[0] = rb_str_new2(buf);

これはrb_sprintf()で記述でき，またその方がBUFSIZという妥当性の検証が難しい定数を使わずにすみます。このようなrb_sprintf()で書き換えた方がいいと思われるコードも多数あり，その際に使用されるバッファサイズもBUFSIZだけでなく0x100や1024，32など多彩です。また，snprintf()ではなくsprintf()を使っている箇所も多数あります。

それではなぜrb_sprintf()ではなく，s(n)printf()とrb_str_new2()を使っているのかということになります（ただし，私は今回の件で詳しく調べるまで恥ずかしながらrb_sprintf()の存在を知りませんでしたので，ここから先は完全に推測に基づきます）。その理由を考えてみました。

(1) README.EXT(.ja)に載っていないため
(2) 関数の実体がstring.cではなくsprintf.cにあるため
(3) 最終的な「Stringを作成する」という目的から，rb_str_newファミリを呼び出すこと前提で思考を組み立てるため
(4) 「Cモード」で思考しているときは，rb_sprintf()に対してCのsprintf()のイメージが干渉し，rb_sprintf()が候補に挙がるのを邪魔しているため

今回，catf()に加えてnewf()の要望を出したのは，(3)と(4)を解消するためです。rb_sprintf()の記述をREADME.EXTに加えることで(1)を解消できるからそれで十分ではないかと思われるかもしれませんが，(1)だけではRuby本体のソースコード内にrb_sprintf()に簡単に書き換えられるコードが実際に多数存在する理由としては不十分だと考えました。そこで今回newf()の要望を出すに至りました。なお，繰り返しますがこれは推測でしかなく，これが正しいという強い確信はありません。また，newf()という名前ならば(3)と(4)の解決になるという確信があるわけでもありません。

また，今回の議論は，s(n)printf()はバッファサイズの妥当性を検証することが難しく，使用を避けた方が良いということを前提としていますが，私はこの点を強く感じすぎているかもしれません。

2. 返答

長くなってしまい申し訳ありませんが，ご意見に返答致します。

成瀬さん

> エンコードを意識した文字列処理の C API 名は、rb_enc_str_* かと思います。

おっしゃるとおり，rb_enc_str_*が正しいと思います。認識不足をお詫びします。

> rb_encoding に NULL を渡すのはいかがなものかと。

これについてはnewf()はrb_sprintf()の別名であり，rb_sprintf()の記述をそのまま利用しただけなのでそのようになりました。

その他のご意見については<1. 動機>で返答になったと思います。

なかださん

* version.h

分かりました。1.8では提供されていたので特に疑問を持たず要望してしまいましたが，RUBY_VERSION_*を直接調べるのは非奨励という理解でよろしいでしょうか。

* フォーマット系

> newf系は既存のrb_sprintf, rb_vsprintf, rb_enc_sprintf,
> rb_enc_vsprintfとまったく同じですよね。「不便」を解消することに
> はならないのではと思いますが。

はい，まったく同じです。これについては不便を解消するためではなく，<1.2
rb_str_newf()の需要>に示したように，rb_sprintf()が使われないケースが多数あるという現実をふまえて，rb_str_newファミリの一つとして提供されたほうが使われやすいのではないかという推測に基づきます。ですが，これは単に推測でしかなく，この考えが正しいのかどうかを検証することもできません。よって強い要望ではありません。

>意図はまぁ理解できるのですが、部分的に連結しながらsprintfするこ
>とってどのくらい多いんでしょう。

<1.1 rb_str_catf()の需要>に示したように，いくつかはあるようです。ただ，それが「多い」といえるかどうかは分かりません。

> fだけでprintfを想起しろ、というのはいささか苦しいのでは。

print()とprintf()の違いがfだけなのでそれで十分かと思ってしまいました。名前については特にこだわりはありません。Rubyの慣習に従うならば，rb_str_new6()ということになるでしょうか。



長くなりましたが，以上です。よろしくお願いします。

---
Goro Fuji (藤 吾郎)