Re: UVM typedef struct

[seebs%seebs.net@localhost (Peter Seebach)]

In message <20090811074826.GA16058%netbsd.org@localhost>, David Holland writes:
>If you don't know whether it's a pointer, you can't use it correctly,
>except in a very limited set of cases for very simple APIs. You get
>bitten by both memory management and sharing.

True.

>Consider:
>
>   silly_t foo, bar;
>
>   foo = get_silly_thing();
>   bar = foo;
>   change_silly_stuff(foo);
>   /* Ok, at this point, has bar been changed? Guess away. */
>   /* And for that matter, is bar even valid any more? */
>
>If you're coding in Haskell, where nothing is mutable and everything
>is garbage-collected, you can genuinely do without this distinction.
>But most people don't want to code in Haskell.

Let's say we commit to you that, definitely, silly_t is a pointer.

Do you now know, without checking the API docs, whether or not bar is
valid?  Well, uhm.  No.  (And if the function is a function-like macro,
you don't even know that foo and bar are still equal.)

Okay, but what if we say that, for sure, silly_t is not a pointer, but an
opaque non-pointer object.  Now do you know?  ... Well, actually, you still
don't know, because it could be that silly_t is a structure CONTAINING at
least one pointer.  In which case bar might well now contain an invalid
pointer, or a pointer to an obsolete object, or... well, we just don't know.

So in short, if types can be opaque, you have already lost.

-s