Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond!diamond
From: diamond@diamond.csl.sony.junet (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re: Multiple typedefs
Keywords: typedefs, includes, defines
Message-ID: <10224@socslgw.csl.sony.JUNET>
Date: 8 May 89 01:57:58 GMT
References: <2322@lethe.UUCP> <10167@smoke.BRL.MIL> <2402@lethe.UUCP> <10190@smoke.BRL.MIL> <12937@haddock.ima.isc.com>
Sender: news@csl.sony.JUNET
Reply-To: diamond@csl.sony.junet (Norman Diamond)
Organization: /usr/lib/news/organization
Lines: 89

In article <12937@haddock.ima.isc.com> suitti@haddock.ima.isc.com (Stephen Uitti) writes:

>Four design options come to mind:

>1. Omit typedef from the language.  People will then not be tempted to
>   use it.
>Option 1) is what my choice would have been at the dawn of time
>(which is sometime before i knew any C).  Typedef functionality
>can be obtained with #defines.  Of course, enums would also be
>gone, replaced by #defines.

Option 1) was in fact the case at the dawn of time.  The C community
discovered that this was one of the things that Pascal did right, and
it was copied (clumsily) into C.

>2. iftypedef(x), untypedef(x), and possibly retypedef(x, y).  Example:
>	iftypedef(mode_t) {
>		untypedef(mode_t);
>		retypedef(mode_t, (char *));
>	}
>Option 2) is a hack on a kludge.  In particular it makes typedef stuff
>look executable.

That's exactly true.  These kinds of operations are expected more at the
preprocessing stage.  If you can design some preprocessing directives
that would handle this problem correctly and not be too difficult to
implement, you might get it into C-0X  (the next standard after C-89).

>3. Disallow typedef definitions using typedef'ed symbols.  Allow
>   typedef foo int;
>   typedef foo int;
>   to work.
>Option 3) doesn't support "complex declarations".

typedef definitions using typedef'ed symbols really are important.
Anyway, gcc does allow duplicate typedefs if they match (warning about
shadows instead of giving an error).  So complex declarations can still
be permitted, and shadows can still be allowed.  Any vendor who has
trouble with these could perhaps distribute gcc instead of their own
C compiler.

>4. Disallow
>   typedef foo *foo;
>   that is, self-referential typedefs.

Huh?  typedef foo *foo;  is already illegal.  It is self-contradictory,
not just self-referential.

>Then allow
>   typedef foo int;
>   typedef foo int;
>   to work,

as in Option 3) above

>   or even
>   typedef u_int unsigned int;
>   typedef foo unsigned int;
>   typedef foo u_int;	/* synonym - it is the same */
>   to work.

unsigned unsigned x;  does not become a valid declaration, no matter
what you do with typedefs (though it was legal in K&R, again no matter
what you do with typedefs).  What happens next:
typedef signed foo int;  is this equivalent to
typedef signed unsigned int int;

>Be real.

That's good advice.  Take it!

>Typedefs are nuisance synonyms that seldom have real use

This is completely false.

>(the UN*X kernel is one of those "seldom" places

It is one of those "many" places.

>- nothing i've ever written outside the kernel would benefit by them.

So _you_ haven't done any real programming outside the kernel.
Big deal.

--
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net)
  The above opinions are my own.   |  Why are programmers criticized for
  If they're also your opinions,   |  re-inventing the wheel, when car
  you're infringing my copyright.  |  manufacturers are praised for it?