Re: UVM typedef struct

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Jun 19, 2009 at 02:57:14PM -0400, Greg A. Woods wrote:
 > > > > Historically, *_t types are primitive types
 > > > 
 > > > No, not really, especially not in C generally (perhaps in Unix, but
 > > > there are perhaps other explanations for why Unix code failed to use
 > > > this powerful idiom as uniformly as it should have).
 > > 
 > > Historically in Unix, though, which is the point.
 > 
 > Historically in Unix it doesn't matter though -- Unix had too much
 > baggage carried forward from the days before the invention of "typedef".

Yes, and that baggage was kept precisely because of the distinctions
I've cited.

 > >  > Historically the real reason for appending "_t" to typedef names is to
 > >  > mark the identifier as being a "type" -- i.e. it's a special identifier
 > >  > that exists in a unique namespace.
 > > 
 > > Yes, it is a type, but it is a *primitive* type. Non-primitive types
 > > have been, historically, marked with 'struct' or 'union', and the
 > 
 > Well, yes, up to the point where "typedef" came into being at least.
 > 
 > Since then "typedef" offers a way to name any kind of type, primitive or
 > otherwise.

You are talking about what is possible; I am talking about historic
practice in the kernel and the ... more important parts of userland.

 > > Structs and particularly pointers are not used the same way (no matter
 > > how abstract they are!) and should be tagged, if tagged, with
 > > something other than _t.
 > 
 > The point with "_t" is to distinguish the type alias name as being a
 > typedef name, not in how the underlying data structure is used
 > regardless of whether it is a pointer, struct, or union.

This is entirely pointless.

 > Use of "_t"
 > for all typedef names is a convention that helps both human 

Not likely. Or do you also advocate full Hungarian notation?

 > and computer

Bollocks.

 > distinguish the unique properties of these unique identifiers.  They are
 > not labels on storage (text or data) they are labels on language
 > constructs and as such it is critically important that they be treated
 > as unique.
 > 
 > > Myself, I don't see any great need to tag them, as the distinction
 > > between types and values is abundantly clear from syntax,
 > 
 > I certainly don't agree at all with the use of "abundantly" there.

There are very few cases where they aren't clear to a human reading
sane code. Arguably, any such case is a bug.

Meanwhile, the compiler has a symbol table and doesn't care in the
least.

 > I'm talking about human factors

So am I, that's the point.

However, it appears that it's a lost cause. Someone even went and
created a vnode_t, for heaven's sakes.

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