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

Reply via email to