[#11073] segfault printing instruction sequence for iterator — <noreply@...>

Bugs item #10527, was opened at 2007-05-02 14:42

14 messages 2007/05/02
[#11142] Re: [ ruby-Bugs-10527 ] segfault printing instruction sequence for iterator — Nobuyoshi Nakada <nobu@...> 2007/05/10

Hi,

[#11188] Re: [ ruby-Bugs-10527 ] segfault printing instruction sequence for iterator — Paul Brannan <pbrannan@...> 2007/05/16

On Thu, May 10, 2007 at 04:51:18PM +0900, Nobuyoshi Nakada wrote:

[#11234] Planning to release 1.8.6 errata — Urabe Shyouhei <shyouhei@...>

Hi all.

17 messages 2007/05/25

Re: [ ruby-Bugs-10598 ] return from block inside a lambda does not work as expected

From: Gary Wright <gwtmp01@...>
Date: 2007-05-05 19:39:46 UTC
List: ruby-core #11096
On May 4, 2007, at 11:00 PM, noreply@rubyforge.org wrote:

> As an example, please consider the following trivial and highly  
> contrived example.  A call to foo returns out of the defined lambda  
> block m, assigning the variable q and returning from foo properly,  
> when v is negative.  However, if v is positive and the iteration  
> over the range is executed, the return returns from both m and foo,  
> skipping the assignment to q and the further processing that foo  
> does to that result, and instead returns n straight out of foo.  (I  
> bet that was hard to follow)  :)
>
>
> def foo(value)
>   m = lambda do |v|
>     return "v is negative" if v < 0
>       (5...100).each do |n|
>         #This line returns from the whole method, not just from the  
> block!
>         return n if v.modulo(n).zero?
>       end
>     return false
>   end
>
>   q = m.call(value)
>   return "ANSWER: #{q.inspect}"
> end


In your example, the block associated with #each is *not* a lambda  
and so
the return is associated with the method.  A block within a lambda  
has its
own behavior with respect to 'return'--it doesn't inherit that  
behavior from
an enclosing block.

Gary Wright




In This Thread

Prev Next