[Bug preprocessor/58887] Allow recursion in variadic macros?

joseph at codesourcery dot com gcc-bugzilla@gcc.gnu.org
Mon Oct 28 18:51:00 GMT 2013


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887

--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 28 Oct 2013, mtewoodbury at gmail dot com wrote:

> (Stop the 'we'!  Name or enumerate the group involved please.)

Well-established consensus among the GCC maintainers about what sorts of 
features are appropriate to add and what sorts of features cause problems.  
It's not as if the preprocessor has lots of active development with 
disagreement among its developers about what should go in; it's rightly 
pretty stable in terms of features with only occasional bug fixes or new 
features (mainly coming from WG21) needed.

> But that bug was filed on the wrong component and has languished for YEARS as a
> result of that miss-filing.  It looks like no one has looked at its problem
> seriously...

That maintainers wouldn't necessarily object to the addition of a feature 
doesn't mean any maintainer has any interest in implementing it.  There 
are lots of "bugs" filed suggesting some vaguely reasonable new feature 
that was of interest to the submitter but not of sufficient interest to 
anyone wanting to implement it (but not rejected either, because the 
feature might well be accepted if implemented).

> (In reply to joseph@codesourcery.com from comment #8)
> > (And for recursion, even specification at the level of standard text might 
> > leave something to be desired; I'd think specification at the level of 
> > X3J11/86-196, the algorithm GCC tries to follow regarding when a macro 
> > name generated in macro expansion can itself be expanded, would be desired 
> > as well.  Not that I think recursion is appropriate to include in GCC's 
> > preprocessor unless it's standardized.)
> 
> Hmm.  Is X3J11/86-196 the pdf that shows up at the top of a Google search?

Yes.

> If so, I'll need to go over it fairly carefully.  A quick review left me with
> the impression that determining when to allow additional expansion involved a
> bit of hand-waving.

The point is it defines, through the pseudocode functions, exactly how 
hide sets (the sets of macros for which expansion is currently suppressed 
because it would be recursive) are determined - it's the pseudocode that 
you need to study more than the surrounding text.  And it's this algorithm 
that GCC is intended to follow.  So anything allowing new forms of 
recursion needs to explain how this algorithm is affected.

> possible.  With the proper hedges in place it would have the same kind of power
> that variadic functions posses.  As things currently stand, variadic macros
> have apparently arbitrary limitations that reduces their usefulness.  With an
> intelligent design, this would be where the language aught to be going.

I suggest that the language ought not to be going in the direction of 
adding much power to the preprocessor at all - that expressive power 
belongs in the language, not the preprocessor (and that it's fine to use 
programs to generate C program text if neither is convenient for what you 
want to do).

Obviously you can experiment with adding a feature to GCC's preprocessor 
in preparation for submitting it to WG14 - and detailed definitions in 
terms of pseudocode algorithms and proposed standard text will be helpful 
for that as well.  But for actual inclusion in mainline GCC, you need to 
convince the maintainers that it's desirable for such features to be 
present in the preprocessor at all - that they are worth the maintenance 
burden that any feature imposes (which includes being well-enough defined 
that reimplementing a bit of the compiler won't change them incompatibly, 
rather than doing things in ways that are accidents of the implementation 
and so hard to specify and keep compatible over time).

Sometimes a development branch is a better place for gaining experience 
with an experimental feature than mainline, until the standards committees 
reach a conclusion on the feature and how to specify it (that was done 
with C++ concepts, for example).



More information about the Gcc-bugs mailing list