On 11 July 2010 11:44, Asher Haig <redmine / ruby-lang.org> wrote:
> Bug #3558: Passing args with rb_block_call
> http://redmine.ruby-lang.org/issues/show/3558
>
> Author: Asher Haig
> Status: Open, Priority: High
> Category: core
> ruby -v: 1.9.2rc1
>
> I've posted in two places about this over the past 2 days, and today I've=
 taken a look through the internals and I am fairly sure that I am looking =
at a bug.
>
> Last post here: http://www.ruby-forum.com/topic/212893#new
> And originally I posted here: http://stackoverflow.com/questions/3217624/=
ruby-1-9-1-p378-c-extension-rb-block-call-weirdness
>
> The short of the problem is that when I call rb_block_call, the called bl=
ock
> function receives the yield value and data2 appropriately, but argc is
> always set at 1 (no matter what I pass) while argv[ 0 ] and argv[ 2 ] =3D=
=3D
> yield value, and argv[ 1 ] =3D=3D Qfalse.
>
> So far as I can tell from looking at the internals (primarily invoke_bloc=
k_from_c and vm_yield_with_cfunc), no handling is being done for the args t=
hat were passed to rb_block_call. Instead, the specified function gets argc=
/argv from rb_yield, which is always 1 and the value from rb_yield.
>
> There are only three examples that I see in the Ruby source that use rb_b=
lock_call while passing args: one in Enumerator, and two in Range. The meth=
od signatures there provided me additional confusion (VALUE i, void* args),=
 as it does not match the description of expected functions. Presumably it =
still works since it ends with the void pointer, which is being used for va=
riable args.
>
> Asher
>

I just answered on Stack Overflow.

(Why at that moment Nobu posted?)

Benoit Daloze