[#44586] [Ruby 1.9 - Bug #5423][Open] readlineの入力待機中に端末のウィンドウサイズ変更すると入力内容が乱れる — Takuto Matsuu <matsuu@...>

8 messages 2011/10/08

[#44589] [Ruby 1.9 - Bug #5429][Open] 64ビットなFreeBSDのioctlでビット31が1なリクエストの時の不具合 — Makoto Kishimoto <redmine@...>

21 messages 2011/10/09

[#44604] Ruby 2.0 release plan — "NARUSE, Yui" <naruse@...>

ささださんが既にいくつか 2.0 関連のメールを投げていらっしゃいますが、

75 messages 2011/10/18
[#44607] Re: Ruby 2.0 release plan — Yukihiro Matsumoto <matz@...> 2011/10/18

まつもと ゆきひろです

[#44618] Re: Ruby 2.0 release plan — "NARUSE, Yui" <naruse@...> 2011/10/18

(2011/10/18 16:15), Yukihiro Matsumoto wrote:

[#44619] Re: Ruby 2.0 release plan — Yukihiro Matsumoto <matz@...> 2011/10/18

まつもと ゆきひろです

[#44627] Re: Ruby 2.0 release plan — Urabe Shyouhei <shyouhei@...> 2011/10/19

On 10/18/2011 10:16 PM, Yukihiro Matsumoto wrote:

[#44629] Re: Ruby 2.0 release plan — Yukihiro Matsumoto <matz@...> 2011/10/19

まつもと ゆきひろです

[#44631] Re: Ruby 2.0 release plan — Urabe Shyouhei <shyouhei@...> 2011/10/19

たとえば2.0の次のバージョン番号はどうしますか?

[#44633] Re: Ruby 2.0 release plan — "NARUSE, Yui" <naruse@...> 2011/10/20

2011年10月20日3:31 Urabe Shyouhei <shyouhei@ruby-lang.org>:

[#44612] Re: Ruby 2.0 release plan — Yusuke Endoh <mame@...> 2011/10/18

遠藤です。

[#44707] [ruby-trunk - Feature #5512][Open] Integer#/ の改訂 — tadayoshi funaba <redmine@...>

13 messages 2011/10/30

[#44719] [ruby-trunk - Feature #5520][Open] Numeric#exact?、Numeric#inexact? の追加 — tadayoshi funaba <redmine@...>

13 messages 2011/10/31

[ruby-dev:44715] Re: [ruby-changes:21512] akr:r33561 (trunk): * configure.in: check dup3.

From: Tanaka Akira <akr@...>
Date: 2011-10-31 00:30:13 UTC
List: ruby-dev #44715
2011年10月31日5:26 KOSAKI Motohiro <kosaki.motohiro@gmail.com>:
>
> akrさん、このコードなんですが、rb_cloexec_dup2(oldfd, newfd)のoldfdとnewfdが一致する可能性は
> あるでしょうか?あるとしたら、どういう動作をすべきと意図しているAPIでしょうか?

公開APIなので、可能性はあり得るでしょう。

動作は、dup2() + CLOEXECをセット、という名前なので、
一致したら、CLOEXECをセットだけがいいかなぁ。

> といいますのも、さいきんglibcのメーリングリストでdup2とdup3とで oldfd == newfd のときの
> 仕様が異なっており、libcのdup2() が システムコールのdup3() を呼ぶようにしてしまったので、
> regressionしたというバグが報告されています。
>
> http://cygwin.com/ml/libc-alpha/2011-09/msg00061.html

なるほど。

% svn diff --diff-cmd diff -x '-u --ignore-all-space -p'
Index: io.c
===================================================================
--- io.c	(revision 33577)
+++ io.c	(working copy)
@@ -239,6 +239,10 @@ rb_cloexec_dup2(int oldfd, int newfd)
 {
     int ret;

+    if (oldfd == newfd) {
+        ret = newfd;
+    }
+    else {
 #if defined(HAVE_DUP3) && defined(O_CLOEXEC)
     static int try_dup3 = 1;
     if (2 < newfd && try_dup3) {
@@ -258,6 +262,7 @@ rb_cloexec_dup2(int oldfd, int newfd)
     ret = dup2(oldfd, newfd);
 #endif
     if (ret == -1) return -1;
+    }
     fd_set_cloexec(ret);
     return ret;
 }

> btw, めちゃくちゃ余談なんですが、dup3でEINVALにしてるのは本当にいい仕様なんですかねえ?

dup3 だけの仕様としてみれば悪くないように思えます。
oldfd == newfd かどうかで close の回数が変わってきますから、
いずれその判断はアプリケーション側でやらないといけないでしょう。
どうせやるなら dup3 の前にやることを勧めてもいいのでは。

dup2 の drop in replacement として使いにくいという点との比較については、
どの段階の状況を重視するかですかねぇ。
-- 
[田中 哲][たなか あきら][Tanaka Akira]

In This Thread