At Fri, 19 Jun 2009 18:21:02 +0000, David Holland
<dholland-tech%netbsd.org@localhost> wrote:
Subject: Re: UVM typedef struct
>
> 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 in Unix it doesn't matter though -- Unix had too much
baggage carried forward from the days before the invention of "typedef".
I'd guess dmr might even agree with me and also close by saying
"practice what I preach, not what I do".
Just because Unix has/had poor programming practises as extra baggage
doesn't mean NetBSD needs to carry it all, or even some, forward as well.
(except where mandated by POSIX, but even then only on the surface :-))
> > 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.
Perhaps historically the only really good reason to ever use "typedef"
for primitive types where where they might have to change size within
the same class of primitive type for some variant implementation such as
to mask underlying hardware differences, or to support scaling, etc.
However the reasons for using "typedef" to alias struct or union
definitions are far more numerous and perhaps more vaporous as well, but
now those reasons are generally accepted they apply to primitive data
types also.
> 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. Use of "_t"
for all typedef names is a convention that helps both human and computer
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.
Indeed the tagging of typdef names is not necessary for the compiler,
but neither is the use of meaningful nouns in identifiers (instead of
just creating them from random alphabetic sequences for example) -- I'm
not talking about syntax, I'm talking about human factors and
non-compiler partial parsers used to support human factors (such as
syntax highlighters, etc.)
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgpO2tYLJqMnO.pgp
Description: PGP signature