[C++] extern "C" typedefs

[Nathan Sidwell]

Mark Mitchell wrote:
> I think this should extension should be removed, by default.  It's
> simply too hard to maintain.  Correct operation would require tagging
> the types in some way, and then adjusting the type-conversion code to
> treat the type as `void (*)()' *unless* that didn't work and then do
> `void (*)(...)'.
> 
> As a point of reference, the EDG front-end does not implicitly add an
> ellipsis inside `extern "C"'.
> 
> One reasonable option would be to only add the `...' with
> -fpermissive.  I think that's what we should do.
OK, I've had a look in more detail. We're trying to be nice about
	extern "C" int foo ();
but, in parse.y, make all instances of () equivalent to (...) in an
extern "C" region. I.e. the problem with pointers to functions is an
accident. It would be a little tricky, but not impossible, to make ()
equivalent to (...) only when it's a function declaration and not when
it's a pointer to function, for instance.

Presume we do do the tricky thing. Using -fpermissive to switch this on
and off goes against the documented meaning of -fpermissive, which is to
change things which are pedantically errors into warnings. To fit with
that scheme we'd have to treat them as (void) always, but mark C function
decls which were `()', and then try and treat them as C would, should
the (void) treatment fail. Treating an unknown arg list as ... is not
really the right thing anyway, as varargs parameters might be passed
differently to K&R style self promoted args anyway.

Ripping out all the strict prototype stuff causes four test failures, two
of which are incidental, the other two are testing that

	extern "C" {
		int foo ();
		int foo (int);
	};

is acceptable.

So, do we really need the tricky stuff, or can we just kill it? What
killer software out there is relying on this extension?

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org