Xref: utzoo comp.lang.c:21049 comp.std.c:1553
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond
From: diamond@csl.sony.co.jp (Norman Diamond)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: type-redef's (was: va_list used in <stdio.h>)
Message-ID: <10723@riks.csl.sony.co.jp>
Date: 22 Aug 89 10:54:14 GMT
References: <1140@midgard.Midgard.MN.ORG> <10720@smoke.BRL.MIL> <2095@dataio.Data-IO.COM> <10739@smoke.BRL.MIL> <13572@bloom-beacon.MIT.EDU> <10766@smoke.BRL.MIL> <3020@solo1.cs.vu.nl> <10784@smoke.BRL.MIL>
Reply-To: diamond@riks. (Norman Diamond)
Followup-To: comp.lang.c
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 27

In article <3020@solo1.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes:
>>Why is a type-redef still forbidden?

In article <10784@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:

>Because to do otherwise would result in severe parsing problems.

It is very believable that the parsing problems are severe.  However,
I believe that every C compiler already solves those parsing problems.

typedef int *(*my_type)();           /* my global type */

void my_func()
{
    typedef char ***my_type[5];      /* my local type */

(It would also be legal if my local type shadowed my global type instead
of being different.)

So parsers already have to be prepared for possible-typedef identifiers.

--
-- 
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net)
  The above opinions are inherited by your machine's init process (pid 1),
  after being disowned and orphaned.  However, if you see this at Waterloo or
  Anterior, then their administrators must have approved of these opinions.