tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: UVM typedef struct



On Tue, Aug 11, 2009 at 02:18:47AM -0500, Peter Seebach wrote:
 >> That is not a benefit.
 > 
 > It can be.
 > 
 > In particular, it encourages you to use the API, rather than trying to
 > outsmart it.

If the public header for the API declares the structure in question,
but does not define it, as should be the case for anything calling
itself an opaque type, it's sufficient to write

   struct thingy;  /* Opaque. */

and dressing it up any further just obscures what's really going on.

 > If you are quite sure whether x_t is a pointer or not, you may
 > take steps based on your expectations of how to manage pointers (or
 > non-pointers).  This can be an advantage, especially for other people who
 > may need to update an API you were supposed to be using...

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.

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.

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index