From: Sean Middleditch <elanthis@...>
Date: 2002-04-05T11:06:41+09:00
Subject: Re: Is eval a code/design smell?

On Thu, 2002-04-04 at 20:33, Harry Ohlsen wrote:
> > I know I would.  To me, that is indeed a language flaw.  There should be
> > methods that don't open up the security holes of eval() for
> > finding/setting attributes of an object.
> 
> I'm not quite sure what security holes you imagine can be opened up
> by a piece of code like ...
> 
>    obj.instance_eval "@{name} = value"

Depends.  Where does name and value come from?  Like mentioned in other
threads, clever programmers can pull some clever tricks.

It would be much cleaner to have something like:

obj.set_member(name, value)

Because then, name can only be evaluated one way (i.e., a string that is
converted to an ID that is only search for in the class members), and
value is simply assigned to it.  There is no room for various string
expansions to take place, and thus odd names or values given that can
execute arbitrary code.

It's similar to letting a user in a C program enter in a memory address
for storing user input - they could write it into the code execution
area, and then run arbitrary code.  For a simple console or GUI program
that is executed by the user giving the input, that's not *too* bad,
because what is the user going to do, hack their own account?

For anything where untrusted input (i.e., downloading files from the
internet/e-mail, or accepting input from remote hosts or other users,
like a server) is possible, you don't want to open yourself up.

> 
> > Your specific need for no
> > initialize() still seems weird to me
> 
> The point is that, since you're going to overwrite every single
> attribute with its value from the XML then what does calling
> initialize achieve?  On top of that, there's a major issue to
> do with working out what values to pass to initialize. They
> may not simply be the attributes of the class.

OK, I'm not following - what is then the difference with just not
defining an initializor?  

> 
> > but if it is necessary, and the
> > language restricts you from doing it, then either the language is flawed
> > or you are using the wrong langauge for the task.
> 
> Agreed (on the *ahem* "language is flawed" suggestion).  I haven't read
> about the allocate() method that's been added in 1.7 yet, but I have a
> feeling it will be precisely what is required.

Haven't looked at that yet.. probably should do so.  ^,^

> 
> > People have built applications that do everything Ruby can do in C, and
> > done it faster than the Ruby interpreter could do it (although with a
> > lot more work than Ruby would require) without ever having an eval() for
> > C code.  ~,^
> 
> Agreed.  Of course, the nice thing about Ruby is that even though this
> issue doesn't seem to have been handled cleanly (yet), at least I can
> get around it, so I'm happy ... and I think Chris is almost happy,
> too :-).

Ya.  I would think a simple C extension could be written to add the
functionality discussed.  Why one isn't standard is beyond me; I'm
assuming there's some gotcha with the Ruby runtime I don't know about.

> 
> Harry O.