Re: vtable bug (Re: Replacing cport [...])

Tom Lord <lord-1tv/[email protected]> writes:

>     > From: Andreas Rottmann <[email protected]>
>
>     > > 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.
>
Yep, that was the intention.

> 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).
>
That's a good idea, IMHO.

Andy
-- 
Andreas Rottmann         | [email protected]      | 118634484@ICQ | [email protected]
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Any technology not indistinguishable from magic is insufficiently advanced.
   -- Terry Pratchett