Why are typedef names in the same name space as variable names?

[bs at alice.UUCP]

In article <7374 at utzoo.UUCP>, henry at utzoo.UUCP writes:
> > ...default sc-specifiers are assigned.  K&R state that the default is auto
> > inside a function and *extern* outside.  It seems to be *static* in most
> > C implementations these days.
> 
> Can you name a few?  Extern is the way it has always been in C; compilers
> which default to static are broken.  (Please don't cite C++, that isn't C.)
> -- 
> 				Henry Spencer @ U of Toronto Zoology
> 				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

Most (all?) C compilers and lint will accept the following program:

file1:

	typedef int I;
	I i = 1;

file2:
	typedef char* I;
	I p = "asdf";

Is it legal? Personally, I think not because the name I which is external by
default has two definitions (but the C++ compiler also accepts it).

The default storage class specifiers are identical in C and C++ so the glib
remark about C++ is irellevant in the context. What is different about C++
in this context is that structure tags are in the same name space as
identifiers (including typedef names). For example, the following is not C++:

	struct s { int a; };
	struct s s;

As it happens, the generally available C++ implementation accepts this as an
aid to people mixing C and C++.

On a more general note what does it take for a C-like language/implementation
to be ``not C''?

For example, is the C-like language used on many UNIX systems ``not C'' for
failing accept this (perfectly legal) C program?:

	typedef double T;

	f() {
		typedef int T;
	}

(C++ accepts it, but on many systems its ``code generator'', cc, chokes on its
perfectly legal intermediate C).

C++ is C by the simple test of its compiler accepting a larger subset of what
is accepted to be C than most C compilers.

Is a ``C-like language'' with a keyword like ``near'' ``not C''? The compiler
for such a C-like language does not accept the perfectly legal C program:

	main() { int near = 2; printf("%n\n",near); }

Is a ``C-like language'' without the keyword ``enum'' C?

Clearly, any C with an extension that renders even a single legal C program
uncompilable is in a real sense ``not C''. One purpose of the ANSI C effort
is to define a minimum standard for what should be called C, but is the
minimum all that matters? If so, ought the ANSI C commitee abandon the
different standards found in the proposal (I think their names are:
``conforming'', ``strictly conforming'', `hosted'', and ``embedded''
implementations - each in a real sense defines a different language)?

I don't think so (this would imply 7 character names and several other horrors
- including having to change just about every large C program written to date
because of use of features not in ``strictly conforming ANSI C''). I don't
think that any member of the ANSI C comitte wants to have ONLY a minimal
standard and thereby stop further evolution of C. Hence the practical, but
rather ad hoc, acceptance of unspecified extensions in (mearly) conforming
implementations of C.

C++ is not strictly conforming ANSI C (as proposed), but it is C. The problem
is that it is also much more. In particular, being able to write things like

	class complex {
		double re, im;
	public:
		complex(double r, double i)
			{ re=r; im=i; }
		friend complex operator+(complex a, complex b)
			{ return  complex(a.re+b.re, a.im+b.im); }
	};

	f()
	{
		complex a = complex(1,2);
		complex b = a+complex(3,4);
	}

precludes writing things like

	main() { int class = 2; printf("%n\n",class); }

and

	struct complex { double re, im; };

	struct complex complex;
	complex.re = 2;