https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
--- Comment #12 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Tue, 12 Aug 2014, potswa at mac dot com wrote: > > each instance of a ## preprocessing token in the replacement list (not > > from an argument) is deleted and the preceding preprocessing token is > > concatenated with the following preprocessing token. > > This is unambiguous in that consecutive ## tokens get pasted; they can't > all be operators. I think my reading was: they are all operators, all get deleted, and then, after the deletion, the (preceding, following) pairs of remaining tokens get concatenated (the concatenations happening in an unspecified order, with it being OK if they do all happen simultaneously). I see nothing to rule out that sequence of events, or any other sequence of deletions and concatenations of tokens (where if the sequence results in ## being concatenated with a non-placemarker, you have undefined behavior). I wouldn't object to a future standard revision tightening up what's allowed here - though if you do the obvious tightening of adding a new Constraint "Two consecutive ## preprocessing tokens shall not occur in the replacement list for either form of macro definition." (to C11 6.10.3.3), implementation of that would need to be conditional on the standard version selected (it's clear that macro definitions with consecutive ## are valid at present and only their expansion may result in undefined behavior).
