Stringify operator discrepancy with rc.exe's preprocessor

[Michaelangel007]

It looks like the Stringizing operator in a macro isn't supported.

Running this minimal test case bug.rc under resinator.exe ...

#define MY_VERSION     1,2,3,4
#define str(a)         #a
#define xstr(a)        str(a)
#define MY_VERSION_STR xstr(MY_VERSION)

#define ID_TEST 100

STRINGTABLE
BEGIN
    ID_TEST  MY_VERSION_STR
END

... generates this error log:

error: failed during preprocessing:

bug.rc:10:14: error: expected 1 argument(s) got 4
    ID_TEST  MY_VERSION_STR
             ^
bug.rc:4:24: note: expanded from here
#define MY_VERSION_STR xstr(MY_VERSION)
                       ^
bug.rc:3:24: note: expanded from here
#define xstr(a)        str(a)
                       ^
1 error generated.

This file compiles fine with Microsoft's rc.exe producing bug.res:

00000000: 00 00 00 00 20 00 00 00  FF FF 00 00 FF FF 00 00  .... ...........
00000010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
00000020: 2E 00 00 00 20 00 00 00  FF FF 06 00 FF FF 07 00  .... ...........
00000030: 00 00 00 00 30 10 09 04  00 00 00 00 00 00 00 00  ....0...........
00000040: 00 00 00 00 00 00 00 00  07 00 31 00 2C 00 32 00  ..........1.,.2.
00000050: 2C 00 33 00 2C 00 34 00  00 00 00 00 00 00 00 00  ,.3.,.4.........
00000060: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................

I verified the bug.res file is valid via:

• Using cvtres /machine:X64 bug.res to convert it to an .obj
• Linked the bug.obj to an .exe, and
• Used resdump.exe to dump the resource:

Win64 Portable Executable (PE) file:
#0001A600
STRINGTABLE    #00000007h
Language 1033 (US English)
  100 (  64h) "1,2,3,4"

Any chance of updating resinator to support stringify / stringizing?

[squeek502]

Looks like your input also produces an error during preprocessing with clang (even with -fms-compatibility) and gcc, so this particular use of the stringify operator doesn't seem to be portable (i.e. you'd run into issues using windres, llvm-rc, wrc, etc since they use the system C compiler for preprocessing).

resinator uses Aro for preprocessing and passes the --emulate=msvc flag, so this may be something it's interested in supporting when --emulate=msvc is set. I'll look into this more and see if I can write up a PR for that if it seems correct to do so.

(side note: a long term goal is for resinator to use a custom preprocessor that is more compatible with rc.exe's preprocessor, warts and all).

EDIT: Confirmed that cl.exe /E succeeds, so this is not rc.exe-specific and therefore is likely something that arocc --emulate=msvc will want to support

[squeek502]

Did a bit more testing, and it turns out that cl.exe will error if you set the /std flag to >= c11 or use /Zc:preprocessor ("enable standard conforming preprocessor in C/C++")

> cl.exe /E /std:c11 version.rc
version.rc(10): error C4002: too many arguments for function-like macro invocation 'str'
version.rc(4): note: in expansion of macro 'MY_VERSION_STR'
version.rc(3): note: in expansion of macro 'xstr'

So I'm not sure this is something that Aro proper would want to support after all. Will likely need to fork Aro to support this (which is already part of the plan as mentioned before).