Bug #11718: Constant access on `nil`

• Status: Closed
• Assignee: ko1 (Koichi Sasada)
• Target version: -
• ruby -v: ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-linux]
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN

[vais (Vais Salikhov)]

It is possible to access top-level constants by doing nil::CONSTANT, which looks like a bug according to Matz. Here are a couple of examples:

$ ruby -ve "Foo = 123; p nil::Foo"
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-linux]
123

$ ruby -ve "class A; Foo = 456; end; p nil::A::Foo"
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-linux]
456

Thanks!

[Hanmac (Hans Mackowiak)]

hm it might be that nil::Foo is parsed as ::Foo which is doing the top-level access.

but i am not deep enough in the parser to fix that.

[Eregon (Benoit Daloze)]

I think this should really raise an error like:

$ ruby -e 'p nil::String'
-e:1:in `<main>': nil is not a class/module (TypeError)

[Hanmac (Hans Mackowiak)]

yeah that should raise an error. A little test shows that this exist a while way back:

p nil::String

for 1.9.3:

String

for 1.8.7:

# is not a class/module (TypeError)

[elia (Elia Schito)]

looks like it's somehow intended behavior

https://github.com/ruby/ruby/blob/trunk/insns.def#L179-L190

  /**
    @c variable
    @e
     Get constant variable id. If klass is Qnil, constants
     are searched in the current scope. If klass is Qfalse, constants
     are searched as top level constants. Otherwise, get constant under klass
     class or module.
    @j 定数 id の値を得る。
     klass が Qnil なら、そのスコープで得られる定数の値を得る。
     Qfalse なら、トップレベルスコープを得る。
     それ以外なら、klass クラスの下の定数を得る。
   */

apparently introduced here: https://github.com/ruby/ruby/commit/d84f9b16946bca06ce0557ebe99152d7d445c9ec to resolve bug #10943

[Eregon (Benoit Daloze)]

I don't think it's intended, that commit should not introduce new behavior except on singleton class constants.
@ko1 (Koichi Sasada): Could you confirm this is a bug?

[ko1 (Koichi Sasada)]

This is a (intentional) bug. Because I expect nobody reveal such code :p

[ko1 (Koichi Sasada)]

• Assignee set to ko1 (Koichi Sasada)

[ko1 (Koichi Sasada)]

• This is a bug, so that anyone should not rely on this behavior.
• This is a bug, so that this bug should be fixed
• But not critical, so 2.3 can remain this behavior. It should be fix in a future.

[Hanmac (Hans Mackowiak)]

@Koichi: good that you classify it, for a moment i thought that might be an feature ;P

[jeremyevans0 (Jeremy Evans)]

• File nil-const-access-11718.patch nil-const-access-11718.patch added

This bug is still present in the master branch. Attached is a patch that fixes it. It adds a second argument to the getconstant instruction. It would probably be better for performance to add a separate instruction for the case where this is needed, but I'm not sure it is worth it. With the patch:

nil::Object
# TypeError (nil is not a class/module)

[ko1 (Koichi Sasada)]

:+1: great patch! could you commit it?

[nobu (Nobuyoshi Nakada)]

I think it can be an operand of getconst than an argument on the stack, while it is always a constant.

[jeremyevans0 (Jeremy Evans)]

nobu: I agree, making it an operand instead of a stack argument makes more sense. I'm currently testing a patch for that and will commit if it passes.

• Status changed from Open to Closed

Applied in changeset git|fbcd0652944568c43a6ae427960d909d62ce6a8d.

---

Remove support for nil::Constant

This was an intentional bug added in 1.9.

The approach taken here is to add a second operand to the
getconstant instruction for whether nil should be allowed and
treated as current scope.

Fixes [Bug #11718]

[ko1 (Koichi Sasada)]

I think it can be an operand of getconst than an argument on the stack, while it is always a constant.

No. It should not be an new operand because we need to change tools which depends on current bytecode.