[#35027] [Ruby 1.9-Bug#4352][Open] [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s) — "James M. Lawrence" <redmine@...>

Bug #4352: [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s)

16 messages 2011/02/01

[#35114] [Ruby 1.9-Bug#4373][Open] http.rb:677: [BUG] Segmentation fault — Christian Fazzini <redmine@...>

Bug #4373: http.rb:677: [BUG] Segmentation fault

59 messages 2011/02/06

[#35171] [Ruby 1.9-Bug#4386][Open] encoding: directive does not affect regex expressions — mathew murphy <redmine@...>

Bug #4386: encoding: directive does not affect regex expressions

9 messages 2011/02/09

[#35237] [Ruby 1.9-Bug#4400][Open] nested at_exit hooks run in strange order — Suraj Kurapati <redmine@...>

Bug #4400: nested at_exit hooks run in strange order

12 messages 2011/02/15

[ruby-core:35047] Re: [Ruby 1.9-Bug#4352] [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s)

From: Rocky Bernstein <rockyb@...>
Date: 2011-02-02 16:49:09 UTC
List: ruby-core #35047
I'd like to make more succinct the important point of what I wrote below:
address handling source locations correctly in Ruby implementations, and you
should not ever need the file and line parameters on eval.

On Wed, Feb 2, 2011 at 11:21 AM, Rocky Bernstein <rockyb@rubyforge.org>wrote:

>
>
> On Wed, Feb 2, 2011 at 10:47 AM, Yusuke ENDOH <mame@tsg.ne.jp> wrote:
>
>> Hi,
>>
>> 2011/2/2 James M. Lawrence <redmine@ruby-lang.org>:
>> > Thank you for that detailed explanation. The problem for me is the
>> > connection to source_location, which should be usable by tools.
>>
>> What kind of tools are you talking about?
>> Even if a binding location is discarded, we can still fake __FILE__
>> and __LINE__ without using a binding:
>>
>>  eval <<-END, nil, "/etc/passwd", 1
>>    def foo
>>    end
>>  END
>>  p method(:foo).source_location  #=> ["/etc/passwd", 1]
>>
>> So, source_location user should know and accept the fact that the
>> information is not trustable.
>>
>
> Sigh. The main use of setting the file and line in an eval() call is to get
> around the fact that the location is not what folks expect.
>
> In fact, that's why you yourself used that form to suggest how to rewrite
> the code to do what James M. Lawrence seems to want.
>
> See also
> http://ola-bini.blogspot.com/2008/01/ruby-antipattern-using-eval-without.html.
> It is called an "anti-pattern" there which I guess is used in a derogatory
> fashion.
>
> A place where setting the file and line is used is in template systems like
> merb or erb  where the file the user works on is not a Ruby file but a
> template file that expands to a Ruby file. In that situation, disregarding
> the expanded Ruby file is convenient since there can only be one location
> attached in the Ruby implementation.
>
> However I don't see why a templating system couldn't also provide an
> expanded Ruby file for debugging problems much as one can get the
> C-preprocessed output for a C program when one wants.
>
> In the trepanning debuggers (http://github.com/rocky/rb-trepanning and
> http://github.com/rbx-trepanning) I allow similar types of filename
> remapping to go on in the debugger. But in reporting a location I always try
> to report both locations; and it is done automatically in showing an eval
> location.
>
> But shouldn't we try to address the location problem head on in the Ruby
> implementation? I suspect it too late to try to change Ruby MRI 1.x, but
> perhaps in Ruby 2.x some thought could be given to how to address.
>
> If the fact that source_location is not trustable is a a concern, then
> perhaps setting the file and line parameters on eval can be disallowed at
> some level greater than 0 and less than 4 which is where eval() is
> disallowed totally.
>
>
>
>
>> Why do you think only a binding location as a problem?
>>
>>
>> --
>> Yusuke Endoh <mame@tsg.ne.jp>
>>
>>
>

In This Thread