c/5219: Wishlist : scope of typedef doesnt include typedef itself

c/5219: Wishlist : scope of typedef doesnt include typedef itself

[siward.de.groot]

>Number:         5219
>Category:       c
>Synopsis:       Wishlist : scope of typedef doesnt include typedef itself
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sat Dec 29 14:56:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Siward de Groot <siward.de.groot@worldonline.nl>
>Release:        all
>Organization:
>Environment:
all
>Description:
Hi !

I would like this code to work :

typedef struct {
  treenode * prev ;
  treenode * next ;
  char     * ball ;
  } treenode ;

I know I can change first line to give struct a name,
  but this name I never need,
  and I like my code to be clean.
As typedef defines a new name for an existing type,
  why not give that type its desired name directly ?

>How-To-Repeat:

>Fix:
I dont know internals of compiler.
I think that,
  since struct definition is inside typedef, and
  since this construct is valid if struct is named,
  solution might be :
    when parsing a typedef,
    first reserve a place where that type can be  specified
    fill in name to be typedef'd,
      and after that parse struct definition as usual.
This should present no problems (tm), since
  name is known, and
  it only needs to work for pointer types, who's size is known.

If I can do anything to help, please let me know.
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: c/5219: Wishlist : scope of typedef doesnt include typedef itself

[neil]

Synopsis: Wishlist : scope of typedef doesnt include typedef itself

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Sun Dec 30 01:35:14 2001
State-Changed-Why:
    Structure tags give the desired functionality.
    
    The problem with your idea is that the compiler doesn't know
    what a treenode is until it has parsed the whole lot.  In particular, it doesn't know it's a type, or if it was
    a mis-typed "unsigned" etc.  This makes the
    parser far more complicated than it currently is,
    would introduce some bizarre messages I'm sure, and for
    little (IMO) gain.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5219