[ruby-dev:26597] Re: SystemCallError.new("abc") => #<SystemCallError: unknown error - ab>

山本です。

>それは環境を選びすぎでしょう。どこでもmissing/vsnprintf.cを使う
>ようにするんであれば、出力部分を差し替えられるようにして
>rb_str_cat()を呼ぶようにするという手もあります。

configure で切り分けてどうにかできないかとも思ったのですが、
なんかすっきりしませんね。

実際に計測してみると、vsnprintf(NULL, 0, .. の方法のほうが若干速いようなので、
使えるのなら使いたい気はするのです。ただ、この機能がない環境だと遅くなって
しまうので、やはり受け入れにくいかもしれません。

やはり rb_snprintf(/* 人手でサイズ予測 */, buf, .... あたりが妥協点かなあ・・・
共通化で単純になるメリットは残りますし・・・

# 元々？
E:\ruby-cvs\bcc32_1_8>don miniruby -e '100000.times { SystemCallError.new("abc") }'
Passing Time : 0:01.938

# [ruby-dev:26586]
E:\ruby-cvs\bcc32>don miniruby -e '100000.times { SystemCallError.new("abc") }'
Passing Time : 0:02.388

# vsnprintf(NULL, 0, ...)
E:\ruby-cvs\bcc32>don miniruby -e '100000.times { SystemCallError.new("abc") }'
Passing Time : 0:02.088

>vsnprintf()のことではありませんが、C99に依存したコードを書くと、軒並
>gcc 2.xなコンパイラあたりで通らないといったことが起きます。具体的には、
>Cの関数ブロックの途中で自動変数を気侭に定義してしまうといった場合です。
>
>(最近、多いのです。某pkgsrcをNetBSD 1.6.xな環境(他)でコンパイルすると
>エラーになって、後から修正が入ることが。)

そういえば ruby-core でも Sydney な人がそうしてましたね。私の場合は C99
にコンパイラが対応してないので、*.c だと

R:\>bcc32 x.c
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
x.c:
エラー E2140 x.c 7: ここでは宣言はできない(関数 main )
*** 1 errors in Compile ***

になって間違えようがないのですが、gcc だとそんなことになってるんですか。
なんか、カルチャーショックです。（よく考えると、vsnprintf も「必ず'\0'で
終端する」という C99 の仕様を満たしてないので、C99 に準拠してるとは
いえませんでした。）