The recent mention of something being wrongly defined as just the first char of a string reminded me of a problem I saw when trying to build a Unicode version on Windows so I went and had a look at it again and I think that there are problems with several of our macros and their usage…
#define PORTNOTETRACE(section, text) \
TRACE(_T("PORTNOTE[" section "]: " text))
If this is used with two ansi strings as follows:
This expands to:
TRACE(_T("PORTNOTE[" “other” "]: " “Blobby”))
But as _T(s) is defined as L ## s this expands to:
TRACE(L"PORTNOTE[" “other” "]: " “Blobby”)
...and the VC compiler errors about mismatched strings being concatenated as only the first “PORTNOTE[“ string gets prefixed with L. Why gcc usually works I’m not sure. Perhaps it concatenates strings as part of the tokenisation (i.e. before the ## is handled) or perhaps this case hasn’t been considered properly in the compiler and the fact they are different char types is simply ignored causing incorrect strings to be generated.
I have “fixed” PORTNOTETRACE by putting _T() around each of the items that are concatenated but unfortunately this also affects all macros that expect to take ansi params (e.g. ENSURE etc) but internally do a _T(param) to widen them. If these are called with concatenated strings e.g. ENSURE(“Hello\n” “world”), then it will fail. This happens quite a lot in quite a few places.
Basically, I think we need to check every use of # and ## in our macros and then document what type of string should be passed to each macro and whether they can be called with concatenated strings (e.g. ENSURE expects a single ANSI string). I have made quite a lot of changes (mostly to ENSUREs and #pragma message because _LOCMSG_ is ANSI) but have not yet tested them on linux.
Could this explain the weird issue in CamArtControl?