http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #12 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Wed, 30 Oct 2013, mtewoodbury at gmail dot com wrote: > I think I understand consensus, but I only hear your voice here, not the voice > of a multitude. You may be part of the consensus you speak of, but you are > not I was agreeing with Andrew. Jason, the other maintainer likely to review libcpp patches, hasn't commented on this issue. (There are plenty of others who *can* review such patches but are unlikely to do so in practice.) That someone doesn't reply to some point (if they read it) only indicates, at most, that they do not have anything to add that has not already been said adequately somewhere in the totality of the discussion, rather than whether they agree or disagree. > >> 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). > > I have worked for companies where there was a formal definition of roles, and > what you describe is something from that world. On the other hand, I believe > open-source projects like GCC have less authoritarian structures and that such > decisions are much less formal. In other words, membership in 'maintainers' > is > consensus based on merit, not the open and shut rule of corporate structure. Bugs languish because the maintainers - and other developers who might fix them - are individuals, there is indeed no formal structure as regards reviewing bugs or assigning people to fix them, and each individual who looked at it was not interested in implementing the feature / fixing the bug. Misfiling is only a minor part - it could be relevant, if someone had gone through all the "preprocessor" bugs, implementing lots of things, and missed that one because it wasn't a "preprocessor" bug - but it so happens no-one has been active in that way with preprocessor bugs lately. Maintainers are appointed by the Steering Committee (based on merit) (but someone's views on a patch or feature can be relevant and useful without them being a maintainer who can approve the patch). > As I said, I need to go over it carefully. It is obviously pseudo-code and > both the code and the explanation deserve careful study. Where it has built > in > the no-recursion rule was not quite obvious at first glance, thus the remark > about hand waving. Again, I need to study it carefully, and I have not done > that yet... No-recursion is built in through hide sets - that is, each token has at each time an associated set of names of macros that cannot be expanded if encountered when expanding that token. Thus, when expanding a macro M, the name M is added to the hide sets of the tokens in the expansion before they, and the rest of the input, are considered for reexpansion (for details see the pseudocode). Some discussions of C macro expansion use the term "blue paint" when discussing the rules for recursion. Your proposal is apparently something that means a macro is no longer in or out of a hide set, but in a state meaning whether it can be expanded depends on the number of parameters. Maybe the hide sets will need to contain pairs (macro, number of arguments), or something like that, instead of just macro names.
