Re: UVM typedef struct

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> If you have typedef struct foo foo_t; and use foo_t * in an
> interface, you must always expose the implementation struct foo since
> you cannot typedef twice.

You must expose the struct tag name, but there's no need to expose the
struct itself.  This is not because you can't typedef twice but rather
because you can't use foo_t without defining it, and the incomplete
struct is not interface-compatible with the complete struct unless the
struct tags are the same.

This works fine (I've done it often enough):

foo.h:

struct foo;
typedef struct foo foo_t;
void foo_something(foo_t *, int);

foo.c:

#include "foo.h" /* or <foo.h> */
struct foo {
        ...
};
...implementation...

> With struct foo * you have no such problems since you can use forward
> declarations.

How is the above example with foo_t not a forward declaration?

> See *for example* sys/rump/include/rump/rump.h for a few examples of
> current lossage with useless_t.

I don't see any such.  What I see there are problems with trying to use
interfaces _without_ including the files exporting the interface
definitions in question, which is bound to have problems no matter what
the interface style.

> [N]otice how struct lwp interfaces take struct lwp * instead of lwp_t
> *

So?  That's because there's no "typedef struct lwp lwp_t;" line.  I
can't see why not; because of the edict against including the proper
definition file, there's no reason not to typedef it alongside the
incomplete struct declaration.

> and remember what I said above about silly_t *reducing* consistency.

I still can't see the typedefs as being the problem.  The problem I see
is an attempt to use interfaces without including the files declaring
the relevant types.  That this breaks less visibly when using struct
tags strikes me as a reason to use foo_t, to render the bustification
blatant, rather than the converse.

"Then there's no hope of this working off NetBSD" is not an excuse to
avoid including the interface definitions.  Rather, it's a reason to
build an include-file glue layer, or an include-file link farm, some
such, so you can get the interface from wherever it needs to come from
for the environment you're trying to build in.  Perhaps on the next
system you try to use, lwp_t won't be a struct type at all.

> If there was no ridiculous_t, there would be no problem.

If there were no types, there would be no problem.  (BLISS, anyone?)

When you have a symptom and you find something that, if different,
would make the symptom go away, it does not necessarily follow that you
have found the problem.  Say it's summer, and I'm uncomfortably hot;
perhaps the problem is not that my city is too far south but instead is
this overcoat I'm wearing.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B