Re: UVM typedef struct

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Tue Jun 16 2009 at 21:00:35 +0100, Mindaugas Rasiukevicius wrote:
> > The underlying problem is that I do not see any benefit from arbitrary
> > typedefs such as struct x -> x_t.  Will we get u32_t next?
> 
> I understand that it is a personal preference, but at least to me, it would
> increase readability. It would be good to hear opinions of more people who
> are working in sys/uvm.
> 
> Also, as already mentioned, this would be consistent with other core parts,
> eg. various code in sys/kern.

No, your argument is personal preference, mine is technical.  This was
already hinted a few times, but here we go again:

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.  With struct foo * you have no such problems since you can
use forward declarations.  Now, either you will implicitly create rules
about type exposure, need to have two sets of prototypes, some #ifdef
magic, or you will have inconsitency in code (interface has struct foo*,
code uses foo_t and foo_t *).

This is *especially* problematic if you want to provide an interface which
takes foo_t *, but cannot include the headers which provide the type due
to collisions.  Now you have a mismatch between the caller and the callee.
See *for example* sys/rump/include/rump/rump.h for a few examples of
current lossage with useless_t.  In addition to the #ifdef crap at the
top, notice how struct lwp interfaces take struct lwp * instead of lwp_t *
and remember what I said above about silly_t *reducing* consistency.
If there was no ridiculous_t, there would be no problem.

Only if struct foo is never ever a part of any public interface, this
does not apply.  Even then I'd say that foo_t obfuscates, but that *is* a
matter of personal preference and I don't care enough to argue about it.
Still, it is difficult to know that 100 years from now we don't want
struct foo in an interface.

Hopefully that was clear and verbose enough.