On Sunday 27 June 2004 16:53, Patrick May wrote:
> On Sunday, June 27, 2004, at 07:08  PM, Sean O'Dell wrote:
> > Well, in C extensions you have typing, period; you can't get around
> > that.  In
> > C you quite often have no choice but to check your type.  In fact, the
> > vast
> > majority of security hacks arise out of C programmers not checking
> > variables
> > for type and/or size.  It's results in buffer overflow-style hacks
> > that not
> > only result in software de-stabilization, attackers can sometimes gain
> > permissions through them.
>
> Classes defined in safe old 'script.rb' files will have to deal with
> the same lifecycle issues as classes defined in C.  You might not see
> core dumps, but same issue remains.  Any class which depends on its
> initialize method will have guard against #become.
>
> For example -- the very useful class Tempfile is defined in
> tempfile.rb.  It depends on these variables:
>
>    @tmpname: the name of the tempfile
>    @tmpfile: the File object of the tempfile
>    @@cleanlist: the list of files to be cleaned on exit, @tmpname gets
> appended to it.
>
> If these variables are out of sync, then Tempfile is broken.  Note the
> class variable @@cleanlist.  A Tempfile might #become something else
> that changes @tmpname and @tmpfile, but that new class can't change
> @@cleanlist.
>
> This is what I mean when I refer to lifecycle issues.  It has nothing
> to do with C; every class in Ruby will have to guard against this sort
> of problem.

Those variables will still exist; all that changes is the class that handles 
them.  The original class still does all the initialization work.  #class= 
changes the class of an existing object, so the old class has no more 
responsibility once it has been replaced.  The class replacing it takes over 
all functionality.

	Sean O'Dell