Intel C++ 19.0 for Windows invalid macro expansion with stringizing operator

[eldiener]

This example is taken from the C++ standard when discussing the rules for redefinition and reexamination. Given:

#define str(x) # x

the macrto expansion of:

char c[2][6] = { str(hello), str() };

should be:

char c[2][6] = { "hello", "" };

but with Intel C++ 19.0 on Windows the expansion is erroneously:

char c[2][6] = { "hello", };

This is clearly a bug in the preprocessor so I am reporting it here.

[Viet_H_Intel]

Don't you need to have an argument for the second call?

[eldiener]

It is perfectly legal to pass nothing as an argument to any macro. It is not legal not to pass an argument as in:

#define amacro(a,b) anything
amacro(3); // illegal

but

#define amacro(a,b) anything
amacro(3,);

is perfectly legal as is:

#define amacro(a,b) anything
amacro(,3);

or even

#define amacro(a,b) anything
amacro(,);

That is why the initial example of this post is correct C++. Furthermore stringizing a parameter means that the argument for that parameter, without being macro expanded in any way, must be put in quotes, even if the argument is nothing.

[Viet_H_Intel]

By default on Windows, Intel compiler tries to match the behavior of Microsoft Compiler.  And Microsoft has recently introduced an experimental switch which tries to bring the Microsoft behavior more in line with the standard as described here:

https://devblogs.microsoft.com/cppblog/msvc-preprocessor-progress-towards-conformance/

The option is /experimental:preprocessor. However, Intel Compiler doesn't support this option yet.

[eldiener]

I do not understand what the vc++ experimental preprocessor has to do with the fact that the Intel C++ compiler has a preprocessor bug. Are you saying that the justification for having any preprocessor bug in the Intel C++ compiler should be whether or not any vc++ preprocessor has that same bug ?

[Viet_H_Intel]

If you would like I can request to have /experimental:preprocessor supported by Intel compiler to address this issue?

[eldiener]

Viet Hoang (Intel) wrote:

If you would like I can request to have /experimental:preprocessor supported by Intel compiler to address this issue?

What is /experimental:preprocessor supposed to do ? Mimic vc++'s experimental preprocessor ? Are you aware that vc++'s experimental preprocessor has bugs also ?

If all Intel C++ is trying to do is to mimic the bugs in vc++'s default preprocessor or the bugs in vc++'s experimental preprocessor, rather than trying to produce a bug-free C++ standard preprocessor, I am just wasting my time reporting preprocessor bugs in the Intel C++ product to Intel in this forum. I can not tell you how discouraging it is for any programmer trying to use a programming product when the creator of that programming product is just trying to mimic another programming product to the point of having the exact same bugs as the product being mimicked. If that is all the Intel C++ preprocessor is trying to do I can only tell you that you are following a ridiculous path, but it is your right to do what you want. But in that case there really is no point for me to bother reporting bugs to you, as you are evidently uninterested in fixing them with the reasoning that vc++ has the same bugs so it is alright for Intel C++ to propagate them also.