ruby-trunk-changes r60172 - r60176

今日は標準添付ライブラリ webrickTLS を使っている時に accept がブロックしてしまうことがある不具合の修正などがありました。

normal: r60172 2017-10-13 03:50:07 +0900

標準添付ライブラリ webrickWEBrick::Server で TLS を利用している時にクライアント側が handshake を完了しないと OpenSSL::SSL::SSLSocket を non_blocking に設定しておいても accept が block してしまう不具合を修正しています。 直接 Socket の accept_nonblock を呼んでから OpenSSL::SSL::SSLSocket にくるむようにしています。 [ruby-core:83221] [Bug #14005]

svn: r60173 2017-10-13 03:50:08 +0900

version.h の日付更新。

nobu: r60174 2017-10-13 10:26:51 +0900

r60171 の続きで tool/rbinstall.rb でコマンドのスクリプトの stub ファイル(.cmd ファイル)を生成する時にのコマンドを修正しているそうです。 [ruby-core:83202] [Bug #13997]

nobu: r60175 2017-10-13 10:34:52 +0900

Warning#warn を定義して警告の出力方法をカスタマイズした時に、そのメソッドで super を呼ぶと stack overflow になっていた不具合を修正しています。うーん、なるほど…。 stack overflow を避けること自体は良いけど、そもそも「Warning.warn を定義するとそれが呼ばれる」というセマンティクスなので、Warning#warn の再定義で効くんだっけ、というのと、効くにしても super が使えるとは限らないのではという気もします。 Warning.singleton_class.prepend とかで再定義したら修正前でもできるみたい…というか Warning.warn の再定義で super を呼ぶのも動くから、これって「Warning#warn の定義でも効く」というのが意図的なのかどうかなのかなぁ。と思ったら https://bugs.ruby-lang.org/issues/12299 のコメントではそれについて触れられてるので、どうやら Warning#warn があること自体は意図的(というか Warning に extend Warning することで Warning.warn のデフォルトの実装が用意されてる。そしてそれは Warning.warn の再定義時に super ができるように、などの配慮でそうなってるらしい)で、あと [Bug #14006] のコメントでも触れられているので認識はされてますね。 [ruby-dev:50293] [Bug #14006]

nobu: r60176 2017-10-13 17:29:52 +0900

include/ruby/defines.h の EXTERN マクロの定義に EXTERN は deprecated なので RUBY_EXTERN を使うようにと警告を出すようにしています。