Re: [PATCH] dir.c --- Dir.chdir error handling

>|I think the safest way is to store object into volatile variable just after construction.
>|
>|  volatile VALUE v = rb_str_new2("foo");
>|
>|  foo(v); /* don't have to think about GC */
>|
>|but on this policy, we can't do this
>|
>|  foo(rb_str_new2("foo"));
>|
>|.... totally.
>
>I'm not sure about your concern.  If the string from rb_str_new()
>still used somewhere, it would not be treated as garbage.  The only
>problem raises when you retrieve data from a VALUE, and forget about
>the original VALUE, e.g.
>
>  VALUE s = rb_str_new2("foo");
>  char *ptr = RSTRING(s)->ptr;
>
>  .. no reference to s, but ptr ..
>
>In the cases like this, you must protect your VALUE explicitly (by
>volatile), but not for rb_rescue() arguments etc.

Well, what I concern is it's difficult to confirm that ruby object is really protected.

To confirm this, we must go down function call. That is,

  void somefunc()
  {
      VALUE s = rb_str_new2("foo");

      func1(s);
  }

  void func1(VALUE v) /* this function doesn't protect v explicitly, so that resposibility */
  {                   /* is for sub functions ... */
      /* too complex codes here */

      rb_fooboo(v);

      if (/* ...... */)
      {
         func2(v, -1, 2, 3);
      }
      else
      {
         func3(1, v, rb_str_new2("foo"));
      }
  }

And move to func2, func3.... mostly object will be protected with volatile or
touched with OBJ_INFECT() or StringValue() somewhere, but there is possibility
none of the functions won't protect it. I think [ruby-dev:19854] is such bug.

(For example, rb_str_intern() is external function but it doesn't protect argument)

I feel it's safter to gurantee ruby-object's life at construction rather than
such chain of resposibility. Of cause, this aproach must have another problem....

>|but on this policy, we can't do this
>|
>|  foo(rb_str_new2("foo"))