[ruby-core:108922] [Ruby master Bug#18780] Incorrect binding receiver for C API rb_eval_string()

Issue #18780 has been updated by alanwu (Alan Wu).


The issue with #18487 was that `Kernel#binding` used to find the
first Ruby frame on the stack and that this iterating behavior
is brittle as it basically acts as an assertion that the frames
that it skips over remain as non-Ruby frames in future versions. We
changed it so that it doesn't iterate anymore and only checks
the direct caller. It's easier to reason about since it's a
weaker assertion and there is only one frame involved.

So now binding related APIs should only consider the direct
caller. The weird `rb_eval_string()` scenario somewhat betrays
this new semantics because when the frame for `Kernel#binding`
is active the stack looks like this:

```
   Type Name
   C    Kernel#binding
   Ruby <eval code frame>
   C    my_eval
   Ruby Foo#foo
```

It returns the local from `Foo#foo`, so not only does it skip
over a C frame, it also skips over a Ruby frame! Now, maybe
we could understand `Kernel#binding`'s behavior here as not
skipping frames but rather returning a binding previously
created at the time when we call `rb_eval_string()`, when the
stack looked like:

```
   C    my_eval
   Ruby Foo#foo
```

But the way it idiosyncratic creates a binding by mixing
contexts is still surprising. The behavior doesn't match
what the docs for `rb_eval_string()` would suggest either
since it's not an isolated binding.

Calling `rb_binding_new()` from a C method doesn't create
a new frame, and it's distinct from calling `Kernel#binding`
from a C method because of that. Using `rb_binding_new()` is
somewhat like assuming the role of `Kernel#binding`. One can only call
`rb_binding_new()` from a C method so making it raise in that
 context would render it completely useless -- not desirable!

----------------------------------------
Bug #18780: Incorrect binding receiver for C API rb_eval_string()
https://bugs.ruby-lang.org/issues/18780#change-98007

* Author: daveola (David Stellar)
* Status: Open
* Priority: Normal
* ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN
----------------------------------------

% ruby -v
ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux]

(Though looking at the source code this problem still exists in ruby 3.0)


The rb_eval_string() is seemingly capable of everything that eval is capable of, with one slight deviation.  The binding is oddly setup to be correct except for the receiver/self.

This means that while these both act the same:

  ruby:    eval("puts someLocalVariable")
  C API:   rb_eval_string("puts someLocalVariable")

These do not:

  ruby:   eval("puts @someInstanceVar")
  C API:  rb_eval_string("puts @someInstanceVar")    # nil

And this is because these do not work:

  ruby:   eval("puts self")                          # self of calling context
  ruby:   eval("puts binding().receiver")            # self of calling context
  C API:  rb_eval_string("puts self")                # main
  C API:  rb_eval_string("puts binding().receiver")  # main

We can see the problem in the MRI source in ruby_eval_string_from_file() which has:

    return eval_string_with_cref(rb_vm_top_self(), rb_str_new2(str), NULL, file, 1);

We've passed in rb_vm_top_self instead of the correct 'self'

Although possibly the issue is in the API itself with the fact that there's no way to plumb through the receiver that you are given in the C extension method function call, i.e.:

        // My C extension that calls eval and knows what it's 'self' is.
        VALUE method_myCMethod(int argc, VALUE *argv, VALUE self) {
                rb_eval_string("...");  // <- no way to be given self?
        }

Having said that, rb_eval_string is able to determine the vast majority of the binding context, since it correctly builds the binding() object *except* that the receiver is set to main, so perhaps this is something that *can* be determined.  It is something that the builtin eval is able to do, after all.  So possibly this is just a failure with MRI.  I don't have other rubies to test.  (I'm on ruby 2.7.0 but the source relevant to this hasn't changed.)

I would argue this is a bug, because we are essentially given a corrupted result from binding() - one where we may have access to the local variables of an instance method, but one where the self itself is not properly set.  That's not an actual legit binding state in the ruby code.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>