From: Sean O'Dell <sean@...>
Date: 2004-06-26T02:49:03+09:00
Subject: Re: Is it considered Harmful?

On Friday 25 June 2004 10:40, Lennon Day-Reynolds wrote:
> On Sat, 26 Jun 2004 02:25:42 +0900, Sean O'Dell <sean@celsoft.com> wrote:
> > On Friday 25 June 2004 10:11, Lennon Day-Reynolds wrote:
> > > [snip]
> > >
> > > > No code should "expect" data to be there that isn't.  If a C
> > > > extension wraps a native C struct as a Ruby object with Make_Struct,
> > > > then when it unwraps it, and gets nothing or a NULL pointer, it
> > > > shouldn't continue to try and use it. That's sloppy coding.
> > > >
> > > >        Sean O'Dell
> > >
> > > I agree with you about it being sloppy programming, but then again,
> > > part of the reason that I write code in Ruby (and Python, Java, C#,
> > > Perl, etc.) is so that I can be a little sloppy, without getting
> > > segfaults or buffer overruns. Programming in C seems to consist mostly
> > > of wrapping unsafe calls in error checks and handlers; I would hate to
> > > see Ruby become similarly burdened due to low-level hacks like #class=
> > > or #become entering the langauge core.
> >
> > I was actually speaking of Ruby C code, not so much Ruby script code. 
> > Ruby should be stable even in exceptional circumstances, although you
> > might not get the results you're after.  It still shouldn't crash.  C
> > code shouldn't use internal data without performing some checks,
> > especially if the data makes the rounds to other libraries/extensions and
> > such.
>
> The point of this whole thread, though, is that adding #become and
> #class= to the language would effectively make Ruby code as
> potentially unsafe as C. Look at the .NET CLR -- they have "unsafe"
> blocks, in which you can do raw pointer-based operations, but which
> mark the entire assembly (a compiled module) as unsafe, and therefore
> platform (and perhaps even OS version) specific.

No, changing an object's class wouldn't cause Ruby code to be as prone to 
problems as C code.  Not in theory, anyway.  In theory, it would be as 
problematic as redefining methods, or including modules that conflict with 
existing object instance variables and methods.

However, after looking a bit at the actual Ruby implementation, it's clear 
that theory and practice are two different worlds.  Ruby uses internal data 
on assumption in a lot of places, and changing an object's class causes it to 
crash quite easily.

But, I think simply placing checks in certain appropriate places would 
alleviate the problem.  Sometime today I think I'll try putting type checks 
in the R_CAST macro and see how that works.

	Sean O'Dell