[net.lang.c] unique namespace for typedefs, struct names, struct tags?

alan@cucca.UUCP (Alan Crosswell) (03/12/86)

I recently ran into a problem with a C compiler with the following
typedef:

	typedef struct foo {
		struct foo *next;
		int foo;
	} foo;

It didn't like the multiple uses of "foo".  Since I am porting
someone else's large program and not writing one from scratch,
the solution of "don't do it that way" doesn't work for me.

Is there any statement in the ANSI proposed standard regarding this
name space issue?  I'd like to be able to coax my compiler vendor
to fix it with a reasonable argument like conformance rather than
saying "well,  it works right with the 4.2 compiler." 

Thanks in advance.

Alan Crosswell
Columbia University

rbj@icst-cmr (Root Boy Jim) (03/13/86)

	I recently ran into a problem with a C compiler with the following
	typedef:
	
		typedef struct foo {
			struct foo *next;
			int foo;
		} foo;
	
	It didn't like the multiple uses of "foo".  Since I am porting
	someone else's large program and not writing one from scratch,
	the solution of "don't do it that way" doesn't work for me.

You are within your rights. But don't try saying: `foo foo;' later on.
Typedefs share the same name space as ordinary identifiers. Struxure
tags are a completely different namespace. Each struxure has its own
separate name space which is its own little universe, separate from
other struxures and the global name space.

Be sure you haven't used foo as a variable elsewhere, altho scope
rules allow redefining within blox. My 4.2 compiler handles the
above fragment okay. I would expect other serious ones to as well.
	
	Is there any statement in the ANSI proposed standard regarding this
	name space issue?  I'd like to be able to coax my compiler vendor
	to fix it with a reasonable argument like conformance rather than
	saying "well,  it works right with the 4.2 compiler." 
	
Tell him to read K&R and get the ANSI standard draft.

	Thanks in advance.
	
	Alan Crosswell
	Columbia University
	

levy@ttrdc.UUCP (Daniel R. Levy) (03/16/86)

:1,$s/x/ct/g
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy