http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #9 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> --- (In reply to jos...@codesourcery.com from comment #7) > On Sun, 27 Oct 2013, mtewoodbury at gmail dot com wrote: > >> That has not always stopped you all in the past, but that is really neither > > We have plenty of experience dealing with the consequent problems of the > old habit of adding extensions because they seemed like a good idea at the > time (or because a feature was supported in some language other than C, > and there used to be an idea that GNU C should support all features of > GCC's internal representation that could be accessed from any language > supported by GCC) without any real effort in designing them at the level > of precise proposed standard text to specify the feature. Based on that > experience, the bar for new extensions is much higher now. > > Unlike recursion, __VA_ARGC__ seems like something reasonably well-defined > and in accordance with the spirit of the preprocessor and unlikely to be > problematic as an extension - but as you note, there's already a separate > bug for it. (Stop the 'we'! Name or enumerate the group involved please.) 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... (In reply to jos...@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? 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. So, the description of what should expanded has to be carefully worked out before any implementation is released. Indirect recursion would be part of the package. I am trying to look at the reasons behind the specifications in the standard. In the case of 'no recursion' it was obvious that simple recursion was a snake eating its own tail and as originally specified could not be anything else. With the addition of variadic macros, a self limiting form of recursion becomes 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.
