Path: utzoo!attcan!uunet!yale!mfci!karzes
From: karzes@mfci.UUCP (Tom Karzes)
Newsgroups: comp.lang.c
Subject: Re: recursive typedefs
Message-ID: <403@m3.mfci.UUCP>
Date: 18 May 88 20:18:29 GMT
References: <8805180221.AA15564@jade.berkeley.edu>
Sender: root@mfci.UUCP
Reply-To: karzes@mfci.UUCP (Tom Karzes)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 39
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <8805180221.AA15564@jade.berkeley.edu> ERICMC@USU.BITNET (Eric McQueen) writes:
>) From: chris%MIMSY.UMD.EDU@UMD2.BITNET 12-MAY-1988 06:04
>)
>) My own feeling is that it should be legal.  The argument against
>) it is that it is not obvious what this means:
>)
>)       typedef int (*pfi)();
>)       typedef unsigned pfi upfi;
>)
>) and I believe that because of this argument, it is explicitly
>) illegal.  Certainly the `#define's are safer.
>)
>) Chris

I think it's extremely bad practice to try to "modify" typedef types as
if they were mere macros.  It's much better to simply create the set of
"machine" typedefs you need at the start, constructed from primitive data
types, rather than to try to modify them later.

Furthermore, trying to support this sort of thing causes problems in many
lexers/parsers, making it harder to support legal C in cases like the
following:

    typedef int     foo;

    double xxx()
    {
        double  foo;

        foo = 123.456;

        return foo;
    }

Try this on a pcc-based C compiler.  It's legal C, but it doesn't work on
most compilers, particularly those that allow unsigned to be applied to
typedef types, because they try to lex "foo" in the declaration in xxx as
if it were a type, rather than a symbol.  A reasonably debugged C compiler
will handle the above code.