Incorrect preprocessor output with /P option

Question

If I use the /P option to produce a preprocessed .i file from the code at the bottom of this post, the line using the macro expands to

int x = --20;

If that is truly the expansion that the compiler is using then obviously a compilation error should occur when the /P option is not used and the code is compiled all the way to a .obj file.  Since no error is occurring, however, then obviously either the .i file does not reflect the real preprocessed output or the compiler itself is broken.  I realize that good programming practice dictates that in most cases a macro replacement list should be parenthesized if it consists of more than a single token and that individual arguments should also be parenthesized in that replacement list, but that is not my point here.  I have seen this inconsistent behavior in all Microsoft compilers since the 1980s and I'm just wondering if anyone knows the reason why it hasn't been fixed, or if there is some other option (other than using a different preprocessor/compiler) that produces consistent results (or maybe I'm just missing something myself).

Thanks,
Ray

#define negate(x) -x

int main(void)
{
   int x = -negate(20);

   return 0;
}

  

Answer 1

If I use the /P option to produce a preprocessed .i file from the code at the bottom of this post, the line using the macro expands to

int x = --20;

Well-known, long-standing problem. It's not just the /P output - in some cases, this improper joining together of preprocessor tokens happens during normal compilation. See

http://connect.microsoft.com/VisualStudio/feedback/details/385034/preprocessor-bug-two-tokens-may-be-joined-into-a-single-token

http://connect.microsoft.com/VisualStudio/feedback/details/783043/c-c-preprocessor-generating-files-with-missing-whitespace-between-separate-tokens

---

Igor Tandetnik

Answer 2

Igor, Thanks for your quick and informative reply.  It seems strange that Microsoft would be unwilling to fix such a long-standing, fundamental, and seemingly relatively easily correctable problem.  Ray

Answer 3

You can define the macro as - #define negate(x) (-x)

---

«_Superman_»
Microsoft MVP (Visual C++)

Polymorphism in C

Answer 4

You can define the macro as - #define negate(x) (-x)

I believe the most appropriate and generic workaround would be #define negate(x) (-(x)) but my main concern was why Microsoft would allow a problem like this to go on for the last ~30 years, with apparently no plans to fix it anytime in the next 30 years either.