Multiple typedefs

Stephen Uitti suitti at haddock.ima.isc.com
Wed May 3 10:07:59 AEST 1989


In article <10190 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>In article <2402 at lethe.UUCP> dave at lethe.UUCP (Dave Collier-Brown) writes:
>>  Is there a technical reason for the difference in redefinition rules
>>for macros -vs- typedefs, ...?
>
>Yes.
We're waiting... holding our collective breath.
>
>Oh, you want to know what it is?  Well, consider how the compiler is
>going to parse a complex declaration containing several typedefs.
>How does it know whether you are defining the same typedef a second
>time or are just using it to help typedef something else?
>
>There's no analogous problem with #define, due to its unambiguous
>syntax that makes it clear what identifier is being defined.

This is the first good answer i've heard.  I still think it is
a (design) bug, though not by any means a new one.  

Four design options come to mind:

1. Omit typedef from the language.  People will then not be tempted to
   use it.

2. iftypedef(x), untypedef(x), and possibly retypedef(x, y).  Example:
	iftypedef(mode_t) {
		untypedef(mode_t);
		retypedef(mode_t, (char *));
	}

3. Disallow typedef definitions using typedef'ed symbols.  Allow
   typedef foo int;
   typedef foo int;
   to work.

4. Disallow
   typedef foo *foo;
   that is, self-referential typedefs.  Then allow
   typedef foo int;
   typedef foo int;
   to work, or even
   typedef u_int unsigned int;
   typedef foo unsigned int;
   typedef foo u_int;	/* synonym - it is the same */
   to work.

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 2) is a hack on a kludge.  In
particular it makes typedef stuff look executable.  Option 3)
doesn't support "complex declarations".  Be real.  Typedefs are
nuisance synonyms that seldom have real use (the UN*X kernel is
one of those "seldom" places - nothing i've ever written outside
the kernel would benefit by them.  The kernel uses them for
simple types for portability reasons - not for itself, but for
its clients).  Option 4) doesn't actually sound too bad.  It is
probably provably completely backwards compatible.

Stephen.
...And my spelling checker agrees, it said "No errors!".



More information about the Comp.std.c mailing list