From: Rocky Bernstein Date: 2011-02-03T01:49:09+09:00 Subject: [ruby-core:35047] Re: [Ruby 1.9-Bug#4352] [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s) --000e0cd59d264eec1f049b4f5e01 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > > > On Wed, Feb 2, 2011 at 10:47 AM, Yusuke ENDOH wrote: > >> Hi, >> >> 2011/2/2 James M. Lawrence : >> > 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 >> >> > --000e0cd59d264eec1f049b4f5e01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd like to make more=A0succinct=A0the 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.=A0
<= br>
On Wed, Feb 2, 2011 at 11:21 AM, Rocky Bernstein= <rockyb@rubyf= orge.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:

=A0eval <<-END, nil, "/etc/passwd", 1
=A0 =A0def foo
=A0 =A0end
=A0END
=A0p method(:foo).source_location =A0#=3D> ["/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.=A0
<= br>
See also http://ola-bini.blogspot.com= /2008/01/ruby-antipattern-using-eval-without.html. It is called an &quo= t;anti-pattern" there which I guess is used in a derogatory fashion.

A place where setting the file and line is used is in t= emplate systems like merb or erb =A0where the file the user works on is not= a Ruby file but a template file that expands to a Ruby file. In that situa= tion, disregarding the expanded Ruby file is convenient since there can onl= y be one location attached in the Ruby implementation.

However I don't see why a templating system couldn&= #39;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-trepan= ning and http://github.com/rbx-trepanning) I allow similar types of filename re= mapping 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 l= ocation.

But shouldn't we try to address the location proble= m head on in the Ruby implementation? I suspect it too late to try to chang= e Ruby MRI 1.x, but perhaps in Ruby 2.x some thought could be given to how = to address.=A0

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 eva= l() is disallowed totally.=A0


=A0
Why do you think only a binding location as a problem?

--
Yusuke Endoh <mame@t= sg.ne.jp>



--000e0cd59d264eec1f049b4f5e01--