[ruby-dev:26829] cannot check EOF of pipe on windows

こんにちは、なかむら(う)です。

現在、Windows版のrubyでは、以下のスクリプト(ささださん作成)を
実行すると、実際にEOFになるべき時点でErrno::EINVAL例外が発生
してしまいます(bccwin32版ではErrno::ENOENT)。

  IO.popen('ruby', 'r+'){|io|
    io.write %q{
      p 1
      print 'xy'
    }
    io.close_write
  
    while c = io.read(1)
      p c
      p io.eof?
    end
  }

IO.popenで作成されるパイプの正体はソケットなのですが、この問
題は、Cランタイムのread()が相手側がソケットであることを考慮し
ていないために発生しています。
と、ここまでが前提。


さて、実際には何が起きているかというと、read()の中でエラーが
発生しているのですが、このエラーは ERROR_NETNAME_DELETED とい
うものです(なんでこのエラーになるのかは聞かないで下さい)。
そこで、以下のようなパッチを作成するとこの問題は回避できるは
ずです。
実際、mswin32版ではこれで問題がなくなります。

Index: win32/win32.c
===================================================================
RCS file: /home/cvs/ruby/win32/win32.c,v
retrieving revision 1.164
diff -u -1 -p -r1.164 win32.c
--- win32/win32.c	18 Aug 2005 02:07:28 -0000	1.164
+++ win32/win32.c	19 Aug 2005 01:42:20 -0000
@@ -3746 +3746,13 @@ rb_w32_fsopen(const char *path, const ch
 #endif
+
+size_t
+rb_w32_read(int fd, void *buf, size_t size)
+{
+    int oerr = errno;
+    int ret = _read(fd, buf, size);
+    if (ret < 0 && GetLastError() == ERROR_NETNAME_DELETED) {
+	errno = oerr;
+	ret = 0;
+    }
+    return ret;
+}
Index: win32/win32.h
===================================================================
RCS file: /home/cvs/ruby/win32/win32.h,v
retrieving revision 1.70
diff -u -1 -p -r1.70 win32.h
--- win32/win32.h	3 Aug 2005 01:21:20 -0000	1.70
+++ win32/win32.h	19 Aug 2005 01:42:20 -0000
@@ -105,3 +105,2 @@ extern "C++" {
 #define tell(h)			_tell(h)
-#define unlink(p)		_unlink(p)
 #define write(h, b, l)		_write(h, b, l)
@@ -135,2 +134,4 @@ extern "C++" {
 #define unlink(p)		rb_w32_unlink(p)
+#undef read
+#define read(fd, buf, size)	rb_w32_read(fd, buf, size)
 
@@ -202,2 +203,3 @@ extern int rb_w32_rmdir(const char *);
 extern int rb_w32_unlink(const char*);
+extern size_t rb_w32_read(int, void *, size_t);
 

で、これでめでたしめでたしということでcommitしようかと思った
のですが、bccwin32版にこのパッチを適用すると、mkexports.rbが
Errno::EPIPE例外を発生してしまうようになりました。
bccのCランタイムのソースを持ってないのでこれ以上追うのは困難
なのですが、どなたか確認できる方はいらっしゃいませんか?


それでは。
-- 
U.Nakamura <[e-mail]>