Hi,
type WCHAR* and since sizeof(WCHAR)==2, it just adds two.
Sounds likely. A cast back to WCHAR fixes it, anyhow, but isn't especially nice.
Which means you get warnings too. I'm not too convinced about this patch especially because it does not return the proper type. On the other hand it seems what I did returns a WCHAR* (after a fashion).
As you say, based on the above it seems that currently the conditional expression returns WCHAR* despite their being 2 possible returns. So it returns the wrong type for characters anyway.
The whole macro can be cast to a WCHAR* if thats a problem and the behavior will be the same as with the patch as it stands (only one warning, when used with L'x' , for assigning a pointer to an int), but the bug above will remain. Assigning from a void* is perfectly safe and fixes the bug, so I chose that.
it seems there's no really good solution (besides -fshort-wchar) :-(.
Sadly we're a long way away from having that option for the majority.Also going forward with Winelib there will be people who aren't using gcc, and who mightn't have that option at all.
If you are going to modify your source, I think casting TEXT('x') to WCHAR is not the solution. The solution is to not use TEXT (and equivalents) on characters.
I agree, its not the best solution. My point was that it is possible to fix the problem (either by casting or some other method), and then compile your code without warnings.
The purpose of the change is to remove all warnings except for the specific problematic case, which makes it considerably easier to locate and fix the offending code. Currently you get spurious warnings which dont help when the macro is used correctly (with L'string'). Given that it generates multiple warnings even when used corectly, how is a developer to notice that s/he has to fix that one case?
IMHO its better to only generate a warning for the case that has problems, especially when its safe to eliminate the other warnings.
So rather than leaving the broken macro in with warnings for both cases and a bug for one case, why not just remove support for characters from the macro altogether? Personally I prefer the patch because IMO it leaves the option to ignore the warning, and fixes the bug as well.
Cheers, Jon