Preprocessor bug

[Neil Booth]

I don't like the idea.  If we added flags to be compatible with
breakage in other compilers there'd be hundreds of them.  Macro
expansions are complicated enough as it is.

It would be less bad if the behaviour we would be turning on were well
defined; however, I'm sure it isn't here.  I doubt you could define X
where you say "in situation X expand, otherwise don't".  A
preprocessor either expands complex nested macros correctly or it
doesn't.

I'd be interested in what others think, though.

Neil.

John Hinke wrote:-

> Unfortunately I do not have enough information to know what the Standard
> says, it has been a long time since I was part of those committees.  However
> I do know that every compiler that I have tested (Sunpro, SGI, HP, AIX,
> MSVC, GCC2.95.2) all of them handle this as I expected them to.  Now this
> might be incorrect behavior according to the standard, but because all of
> them support this incorrect behavior it means that this has become the
> expected behavior.  So if nothing else, we should have a compatibility flag
> that reverts to the old behavior.  I would expect there to be very little
> (if any) code that requires this new behavior.  But I would expect there to
> be a lot of existing code that requires the old behavior.
> 
> I strongly believe in being standards compliant; however, I also believe in
> maintaining portability.
> 
> What solution can we find that is the best for the entire C/C++ community?
> One that allows older (non-standard conforming) code to work and one that
> allows newer (conforming) code to work?
> 
> John