Philip Ashmore writes:
>
> Package: cpp-4.4
> Version: 4.4.4-6
> Severity: normal
>
> Here's an example
>
> #define appendc(x) x##c
> #define aXc(X) appendc(a##X)
> #define abc appendc(abb)
>
> int aXc(b) = 0; // appendc(ab) -> abc -> appendc(abb) -> abbc
>
> int main(int argc, char *argv[])
> {
> return abbc;
> }
>
> The call "aXc(b)" should result in abbc.
> Instead the preprocessor refuses to invoke appendc() the second time,
> resulting in
>
> int appendc(abb) = 0;
>
> This isn't a self-referential macro, so I don't see why it should misbehave
> as it does.
Do you have any documentation to support your idea of how this should work?
n1124 (not Totally Official but hopefully close enough), as I understand it,
specifically forbids what you're trying to do. Here's how it describes the
rescanning of an expanded macro for further macro replacements (6.10.3.4):
..."the resulting preprocessing token sequence is rescanned, along
with all subsequent preprocessing tokens of the source file, for more
macro names to replace. If the name of the macro being replaced is
found during this scan of the replacement list (not including the rest
of the source file's preprocessing tokens), it is not replaced.
Furthermore, if any nested replacements encounter the name of the
macro being replaced, it is not replaced. These nonreplaced macro name
preprocessing tokens are no longer available for further replacement
even if they are later (re)examined in contexts in which that macro
name preprocessing token would otherwise have been replaced."...
In other words, "self-referentialness" is checked recursively. No mutual
recursion, no re-entry.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100722220308.5072.qm...@kosh.dhis.org
