From: William Djaja Tjokroaminata <billtj@...>
Date: 2002-10-23T08:38:09+09:00
Subject: Re: rb_gc_register_address problem

Hi,

I think we are slightly off-topic if we start discussing on the
"const" type specifier.  It seems that gc.c was not written by taking the
advantage of "const" type specifier; gc.c even has the K&R style instead
of the ANSI C style.

Back to the original topic.  The question was why the function is defined
as

    rb_gc_register_address (VALUE*)

instead of

    rb_gc_register_value (VALUE)

struct gc_list stores a VALUE* and a struct gc_list* (it is part of a
linked list to store a bunch of VALUE*'s).  The question is why it stores
VALUE* instead of VALUE.  If we examine the code, it becomes obvious that
it never takes the advantage of having address of VALUE instead of VALUE.

I seems it is purely design decision to use VALUE*, because then once you
call rb_gc_register_address(&gvar), the C variable gvar is free to change
to different VALUE's.  If it were rb_gc_register_value(gvar), then every
time gvar is set to a different VALUE, we need to call
rb_gc_register_value(gvar) (and rb_gc_unregister_value() the previous
VALUE).

This design decision of course makes sense when C global variables are
involved.  But when a C temporary variable is involved,
rb_gc_register_value(VALUE) probably makes more sense, as already
questioned by Paul (but of course there will be some people who will
object to this kind of code design).

Regards,

Bill
=============================================================================
ahoward <ahoward@fsl.noaa.gov> wrote:
> my feeling is that, given a prototype like

>   void method (const char const *ptr);

> you can be certain the method will change neither the thing pointed at, nor
> the ptr itself.

> given a prototype like

>   void method (VALUE *ptr);

> you cannot be sure that, in a current or future release, the ptr itself will
> not be changed, since the compiler would allow this behavior.  therefore it
> would be a bad idea to rely on the ptr not being changed.  also, i agree that
> this was probably a design descision by matz; but since he did NOT write the
> prototype as

>   void method (const VALUE const ptr);

> we may not assume ptr will never be changed.  even if examination of the
> source reveals this to be true.