Re: [C patch] void_type_node

[Nathan Sidwell <nathan at codesourcery dot com>]

Jason Merrill wrote:
> 
> >>>>> Nathan Sidwell <nathan@codesourcery.com> writes:
> 
>  > ? -- For those who may not have noticed, g++ tries to treat
>  > `extern "C" int foo ()' as `extern "C" int foo (...)', and tries to DTRT,
>  > but it fails in ways that are breaking conformant programs. It looks to
>  > me awkward to fix with the existing scheme.
> 
> Why?  Note that the latter is not valid C.
See my email of last week
(http://gcc.gnu.org/ml/gcc-bugs/2000-05/msg00730.html)
My preference would be to ditch the extension, but I suspect that
would be drastic usability reduction :-)

The difficulty is that empty_parms (parse.y) is used to generate
the parmlist for `()', regardless of what's getting the parms. The
current situation is that -pedantic is changing the mangling & meaning
of code, which I think is bad. Mark's proposed solution, if I understand
correctly, is for -fpermissive to have this effect, but I think that to
be bad too. -fpermissive should just downgrade errors to warnings.

Now to fix this, we could always treat "C"  `()' as `(...)', but mangle
it as `(void)', and put smarts in decls_match, comp_target_parms, etc
to know that `(...)' means unspecified (those smarts are already correctly
there, except for `T (*)()' which blows up). (We'd pedwarn so that
-fpermissive had the expected behaviour). Note that in some cases we'll
have lost information about whether the function type is extern "C" (we
don't mark the linkage of types do we?).

Is `(...)' valid C++ on a non-member or static-member function?[1] If it
is, then it might become tricky to do the above fix up, as we can't tell
whether the `(...)' was specified in the source, or intuited from `()'.
If we can do the above, we'll have got yet another special case on
parameter lists. I.e.
	TYPE_ARG_TYPES == NULL && non_static_member_fn -> really (...)
	TYPE_ARG_THPES == NULL && !non_static_member_fn -> really ()
	current_parm_type == void_type_node -> no varadic parms
	current_parm_type == NULL -> varadic parms
To distinguish all these conditions requires knowledge of where one is
when iterating over a parameter list. I'd really like to wrap these up
as macros which just take the current parameter type i.e. something like
	UNSPECIFIED_PARM_P (parm_type) -> was it `()'
	VARADIC_PARM_P (parm_type) -> was it `...)' -- trailing ...
	END_PARM_P (parm_type) -> was it ')' -- no trailing ...
Not sure of the best name for that last one, and it'd be neat if we didn't
need it because that was indicated by NULL_TREE, rather than void_type_node.

nathan

[1]AFAICT [8.3.5]/1 allows it, but 18.7/3 gives no way to access the
varadic args, there being no named parameter before the `...'. 

-- 
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