>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