[Pika-dev] Re: vtable bug (Re: Replacing cport [...])

[Tom Lord]

    > From: Andreas Rottmann <address@hidden>

    > > Unfortunately, it also has:
    > >
    > >         void * scm_binary_data_addr (t_scm_arena arena, t_scm_word * 
value);
    > >
    > > That one is problematic.  Unless VALUE is locked, the address returned
    > > can not be trusted.  A copying collector can move it at any time.
    > > (This would be a good example of how even "noop" locking code can be
    > > handy --- scm_binary_data_addr could verify that VALUE is, indeed,
    > > locked.)
    > >
    > So should I add a scm_object_lock_is_held() or so function? The same
    > issue also comes up with scm_string_value(), which turned to public
    > function with my latest string foo (not yet published).


I was going to say: scm_object_lock_is_held should not be in any
public API, at any level.  Maybe some need for it will show up down
the road.

No, I just meant an `invariant()' inside of `scm_binary_data_addr'.

But, hmm.... I suppose that lock_is_held could be in a public API for
just exactly that reason --- to enable people to write invariants.

Maybe, to discourage abuse of it, make it a macro named:

        scm_object_is_locked_invarient

with the spec that it panics should it's argument not be locked
(rather than making it a predicate).

-t