[#2968] dbm/gdbm/sdbm etc — Dave Thomas <dave@...>
Does ext/dbm supersede gdbm and sdbm?
7 messages
2004/06/07
[#2977] Enumerable#each_with_index in "ri" — Johan Holmberg <holmberg@...>
11 messages
2004/06/12
[#3132] Reporting RI-documentation corrections ?
— Johan Holmberg <holmberg@...>
2004/07/05
[#3133] Re: Reporting RI-documentation corrections ?
— Dave Thomas <dave@...>
2004/07/05
[#3135] Re: Reporting RI-documentation corrections ?
— Austin Ziegler <halostatue@...>
2004/07/05
Speaking of ri documentation, is there anywhere that documents the
[#2978] Date.from_time — Gavin Sinclair <gsinclair@...>
Folks,
5 messages
2004/06/13
[#2982] Array#shift(n) — Michal Rokos <michal@...>
Hello,
15 messages
2004/06/14
[#2985] Re: [Patch] Array#shift(n)
— nobu.nokada@...
2004/06/14
Hi,
[#2987] Re: [Patch] Array#shift(n)
— matz@... (Yukihiro Matsumoto)
2004/06/14
Hi,
[#2988] Re: [Patch] Array#shift(n)
— Michal Rokos <michal@...>
2004/06/14
On Monday 14 of June 2004 16:13, Yukihiro Matsumoto wrote:
[#2989] Re: [Patch] Array#shift(n)
— matz@... (Yukihiro Matsumoto)
2004/06/14
Hi,
[#2991] Re: [Patch] Array#shift(n)
— Michal Rokos <michal@...>
2004/06/14
Hello,
[#2998] Re: [Patch] Array#shift(n)
— nobu.nokada@...
2004/06/15
Hi,
[#2999] Re: [Patch] Array#shift(n)
— Michal Rokos <michal@...>
2004/06/15
Hello,
[#3006] CVS repository — "Eugene Scripnik" <hoaz@...>
Hello.
21 messages
2004/06/16
[#3008] Re: CVS repository
— ts <decoux@...>
2004/06/16
>>>>> "E" == Eugene Scripnik <hoaz@gala.net> writes:
[#3009] Re: CVS repository
— Michal Rokos <michal@...>
2004/06/16
Hi!
[#3010] Re: CVS repository
— Elliott Hughes <ehughes@...>
2004/06/16
On Wed, 2004-06-16 at 09:45, Michal Rokos wrote:
[#3011] Re: CVS repository
— ts <decoux@...>
2004/06/16
>>>>> "M" == Michal Rokos <michal@ruby-lang.org> writes:
[#3012] Re: CVS repository
— "Eugene Scripnik" <hoaz@...>
2004/06/16
Hello.
[#3027] rb_mod_freeze??? — Michal Rokos <michal@...>
Hello!
5 messages
2004/06/17
[#3047] Move all stack info to gc.c — Michal Rokos <michal@...>
Hello,
13 messages
2004/06/23
[#3049] Re: [Patch] Move all stack info to gc.c
— matz@... (Yukihiro Matsumoto)
2004/06/23
Hi,
[#3057] Ruby 1.8.2 to be released. — matz@... (Yukihiro Matsumoto)
Hi,
20 messages
2004/06/23
[#3060] Re: Ruby 1.8.2 to be released.
— Hugh Sasse Staff Elec Eng <hgs@...>
2004/06/23
On Thu, 24 Jun 2004, Yukihiro Matsumoto wrote:
[#3063] Re: Ruby 1.8.2 to be released.
— matz@... (Yukihiro Matsumoto)
2004/06/23
Hi,
[#3090] class= and type checks when casting — "Sean O'Dell" <sean@...>
Matz, I'm not sure if you followed the discussion in ruby-talk about having a
6 messages
2004/06/25
[#3095] 1.8.2: Segfault — Elven <elven@...>
6 messages
2004/06/26
[#3102] gdbm abort - OSX — Dave Thomas <dave@...>
Just before I start another debugging session, has anyone seen this, or
7 messages
2004/06/27
I think I found the recvfrom problem!!
From:
Dave Thomas <dave@...>
Date:
2004-06-22 19:44:58 UTC
List:
ruby-core #3043
I think there's a bug in socket.c's recvfrom implementation.
Some background. Folks on Mac OS X must disable reverse lookups before
using most socket stuff. If we don't, we get the error
in `recvfrom': getnameinfo: Non-recoverable failure in name
resolution (SocketError)
I think I've tracked this down.
The Ruby recvfrom() method returns an assoc containing the data and the
IPAddr of the sender of the data. This code looks something like:
slen = recvfrom(fd, RSTRING(str)->ptr, buflen, flags, (struct
sockaddr*)buf, &alen);
....
switch (from) {
...
case RECV_IP:
return rb_assoc_new(str, ipaddr((struct sockaddr*)buf, fptr->mode &
FMODE_NOREVLOOKUP));
...
}
The 'buf' parameter is the sockaddr returned by the low-level
recvfrom(2) call.
However... the man page for recvfrom on a BSD box says (among other
things)
If from is non-nil, and the socket is not connection-oriented, the
source
address of the message is filled in. Fromlen is a value-result
parame-
ter, initialized to the size of the buffer associated with from,
and mod-
ified on return to indicate the actual size of the address stored
there.
Note: it only fills the data in if the socket is not connection
oriented. TCP sockets are connection oriented, so the alen parameter
was being set to '0' and the buf parameter contained random data. This
was being used in a reverse lookup, and failing.
I propose the following patch: if the recvfrom (2) call does not return
a sockaddr (ie, if alen is zero), then the Ruby recvfrom call returns
[ data, nil ]
otherwise, it returns
[ data, IPAddr... ]
Here's a diff for the change: I've tried it here on some simple
programs and it seems to work OK, but I don't know if there will be
other implications from the nil value. Either way, there's a definite
bug here.
Index: ext/socket/socket.c
===================================================================
RCS file: /var/cvs/src/ruby/ext/socket/socket.c,v
retrieving revision 1.124
diff -u -r1.124 socket.c
--- ext/socket/socket.c 20 May 2004 06:04:39 -0000 1.124
+++ ext/socket/socket.c 22 Jun 2004 19:33:24 -0000
@@ -492,7 +492,11 @@
rb_raise(rb_eTypeError, "sockaddr size differs - should not
happen");
}
#endif
- return rb_assoc_new(str, ipaddr((struct sockaddr*)buf,
fptr->mode & FMODE_NOREVLOOKUP));
+ if (alen)
+ return rb_assoc_new(str, ipaddr((struct sockaddr*)buf,
fptr->mode & FMODE_NOREVLOOKUP));
+ else
+ return rb_assoc_new(str, Qnil);
+
#ifdef HAVE_SYS_UN_H
case RECV_UNIX:
return rb_assoc_new(str, unixaddr((struct sockaddr_un*)buf));
Cheers
Dave