[#7809] uninit bug in yaml/emitter.c — "Pat Eyler" <rubypate@...>
During our hacking night, we also looked at an UNINIT bug in yaml/emitter.c
[#7813] :!~ not a symbol — noreply@...
Bugs item #4344, was opened at 2006-05-03 17:41
[#7818] (security-related) patch to ALLOC macros to prevent integer overflow bugs — "Dominique Brezinski" <dominique.brezinski@...>
While fixing the integer overflow in rb_ary_fill(), it occurred to me
[#7833] segfault on Proc#call after setting a trace_func — Mauricio Fernandez <mfp@...>
$ cat bug2.rb
[#7843] Possible YAMl bug in 1.8.4 — Damphyr <damphyr@...>
OK, while parsing the td2 data from the ruby-lang website we stumbled on
Its probably a bug. I'm not familiar with the specifics, but Ruby
[#7858] Ruby threads working with native threads — "Francis Cianfrocca" <garbagecat10@...>
I recently wrote a network-event extension for Ruby ("eventmachine" in
[#7865] Strange interactions between Struct and 'pp' — noreply@...
Bugs item #4457, was opened at 2006-05-12 17:13
[#7872] Nonblocking socket-connect — "Francis Cianfrocca" <garbagecat10@...>
All, I needed a nonblocking socket connect for my asynchronous-event
In article <3a94cf510605140559l7baa0205le341dac4f47d424b@mail.gmail.com>,
How about introducing the method Socket#set_nonblocking, or alternatively
Hi,
Well, it's ok then. I'm comfortable adding in the nonblocking
Hi,
How about Socket#nbconnect and Socket#nbaccept?
On 5/15/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
In article <1147709691.180288.28647.nullmailer@x31.priv.netlab.jp>,
[#7881] Segfault on x86_64 when built with -O0 in CFLAGS — noreply@...
Bugs item #4491, was opened at 2006-05-16 12:46
[#7882] reproducible bug in DRb on OSX — cremes.devlist@...
I've been tearing my hair out the last few days trying to track down
[#7909] SCRIPT_LINES__ issue when loading a file more than once — Mauricio Fernandez <mfp@...>
SCRIPT_LINES__ is an obscure feature very few people care about, but I happen
On Fri, May 19, 2006 at 06:46:05PM +0900, Mauricio Fernandez wrote:
Hi,
[#7923] Nonblocking accept — "Francis Cianfrocca" <garbagecat10@...>
Thanks to the Matz and colleagues for adding the *_nonblock functions. They
[#7928] set_trace_func: binding has wrong self value for return events — =?ISO-8859-15?Q?Florian_Gro=DF?= <florgro@...>
Moin.
Florian Growrote:
[ ruby-Bugs-4361 ] StringScanner#scan() fails on zero-length matches at eos
Bugs item #4361, was opened at 2006-05-04 21:52
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=1698&aid=4361&group_id=426
Category: Core
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Mitchell Charity (mcharity)
Assigned to: Nobody (None)
Summary: StringScanner#scan() fails on zero-length matches at eos
Initial Comment:
ruby 1.8.4 (2005-12-24) [x86_64-linux]
ruby 1.9.0 (2006-04-08) [x86_64-linux]
ruby 1.9.0 (2006-05-01) [x86_64-linux]
StringScanner's scan() incorrectly returns nil for successful zero-length matches at eos.
StringScanner.new("").scan(//)
=> nil
Only at eos. This
StringScanner.new("x").scan(//)
=> ""
works correctly.
The documentation says scan() "Tries to match with pattern at the current position. If there’s a match, the scanner advances the "scan pointer" and returns the matched string. Otherwise, the scanner returns nil.". Instead, if there's a (necessarily zero-length) match at eos, you get nil. Oops.
To get the documented and desirable behavior, one currently needs to write
ss.scan(re) || (ss.eos? && "" =~ re && "")
instead of simply
ss.scan(re)
whenever there is a chance the re might do a zero-length match.
Which is unfortunate, and a source of bugs.
Example test:
% ruby -r strscan -e 'p StringScanner.new("").scan(//)'
----------------------------------------------------------------------
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=1698&aid=4361&group_id=426