Re: UVM typedef struct

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

On Fri, Jun 19, 2009 at 01:51:27PM -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 also structures are always used as "struct foo"; but
 > > preserving this convention is not as important as not treading on
 > > other related conventions.
 > 
 > Well, maybe, if you go back in time so far that "typedef" didn't exist.

Again, historically in Unix.

 > > So, if we want to do this, which I don't have a strong opinion about,
 > > can we use some naming convention other than _t?
 > 
 > I really strongly disagree with the idea of not using "_t" for typedef
 > names.
 > 
 > 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
desire to retain this visual distinction is why Unix code does not do
the "typedef struct { ... } foo" idiom that much other C code does.

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.

Myself, I don't see any great need to tag them, as the distinction
between types and values is abundantly clear from syntax, but I don't
have anywhere near such a strong opinion about that.

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