From: Rocky Bernstein Date: 2011-02-03T01:21:29+09:00 Subject: [ruby-core:35046] Re: [Ruby 1.9-Bug#4352] [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s) --0015175707f078960d049b4f0a48 Content-Type: text/plain; charset=ISO-8859-1 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 > > --0015175707f078960d049b4f0a48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 2, 2011 at 10:47 AM, Yusuke = ENDOH <mame@tsg.ne.j= p> wrote:
Hi,

2011/2/2 James M. Lawrence <red= mine@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 t= he fact that the location is not what folks expect.

In fact, that's why you yourself used that form to suggest how to re= write the code to do what James M. Lawrence seems to want.=A0
See also http://ola-bini.blogspot.com/2008/01/ruby-anti= pattern-using-eval-without.html. It is called an "anti-pattern&quo= t; 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.


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?

--0015175707f078960d049b4f0a48--