Hello,
while reading the discussion about segfault in
Array#map comes to my
mind that this couldn’t be so rare segfault…
Please look at suspicious peaces of code. To name it
-
look at line 261,
and 1570 (in latest CVS). There are potencial
segfaults.
While 841 is not a segfault, but could give a garbage
like Qundef.
And 1438 could give Qnil…
I think that some king of locking needs to be used
(like ARY_TMPLOCK).
I think that the other classes (not just Array) are
affected like this
as well.
I hope I’m wrong so correct me, please!
Michal
Michal,
I think that in general you are correct. Any
operation where the array alters its own length
midstream, while probably not a good idea in general,
could cause unexpected results.
Using reverse_each() as an example (the method you
metnion with line 841), consider the following code
snippet:
a = [1,2,3,4]
a.reverse_each{ |e| puts e; a.shift }
This results in 4,4,4,4 and returns an empty array
where I think it ought to still return 4,3,2,1 (though
still return an empty array).
I dunno how serious this is in general. I couldn’t
cause the other methods you mention to segfault, and
odds are only people like me who are intentionally
doing screwy things in their spare time on irb would
even notice there was a problem in the first place.
It’s certainly worth reviewing the code for this in
general, though. I should note that my own attempts
to fix this code resulted in segfaults or code that
just didn’t work right. 
Anyway, my .02.
Dan
···
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com