From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20994 invoked by alias); 28 Oct 2013 18:51:17 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 20947 invoked by uid 55); 28 Oct 2013 18:51:11 -0000 From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/58887] Allow recursion in variadic macros? Date: Mon, 28 Oct 2013 18:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: preprocessor X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-10/txt/msg02024.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887 --- Comment #10 from 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).