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
