[PATCH 1/5] include: Fix undefined char16_t with -DWINE_UNICODE_CHAR16.

Jacek Caban jacek at codeweavers.com
Tue Jul 21 11:42:50 CDT 2020

On 21.07.2020 16:17, Puetz Kevin A wrote:
>>> We'd then typedef WCHAR to unsigned short, like we usually do. uchar.h
>>> uses unsigned short as well, so the result should be the same without
>>> introducing an additional includes.
>> That could work too, especially since in C char16_t is not a distinct type (and
>> there's no function-overload mangling). Once you have <uchar.h>, char16_t
>> is "the same type as uint16_t", which is almost certainly unsigned short
>> anyway.
>> So it's just a different route to the same result. And, since u"" *is* a built-in,
>> one could even still offer TEXT macros for C11 in the final #else.
>> e.g. a shape like the following
>> #if defined(WINE_UNICODE_NATIVE)
>> 	typedef wchar_t WCHAR
>> 	#define TEXT(x) L ## x
>> #elif defined(WINE_UNICODE_CHAR16) && defined(__cplusplus)
>> 	typedef char16_t WCHAR
>> 	#define TEXT(x) u ## x
>> #else
>> 	typedef unsigned short WCHAR
>> 	#if __STDC_UTF_16__ /* C11 */
>> 		#define TEXT(x) u ## x
>> 	#endif
>> #endif
>> It's a little less more complex (since you need to know how char16_t Is
>> defined to argue that u"" matches this WCHAR), but I think it would work for
>> any compiler that actually has a 16-bit unsigned integral type, and anything so
>> exotic it doesn't can't really plausibly support wine.
> Would you prefer that I redo this patch in the above shape? I think it would work,
> but I personally prefer it as it currently stands (consistently using char16_t in both
> C and C++). And I think there is sufficient opt-in; if you're  on a pre-C11 platform
> lacking <uchar.h>, or you don’t want any extra utf16 symbols in scope,
> just don't define WINE_UNICODE_CHAR16.
> Another option would be using __CHAR16_TYPE__, though that's gcc-specific.
> I originally had a version of "include: Fix conflicting definitions of wchar_t..."
> that used __WCHAR_TYPE__ in this fashion, before I settled on using <stddef.h> as
> a more portable solution and a path to also fixing my other ODR issue with NULL
> (e.g. windef.h's 0 is 32-bit, gcc <stddef.h> uses __null, which can be a 64-bit type).

I would prefer to make WINE_UNICODE_CHAR16 a no-op here, yes. I think 
that ideally we would keep it as simple as possible and try to avoid 
having differences between WINE_UNICODE_CHAR16 and 
non-WINE_UNICODE_CHAR16 to minimum. Those few typedefs are all places in 
Wine that need to be aware of char16_t, all other places may just use 
WCHAR. A new include with a new type that's not really needed  for Wine 
headers has bigger impact on compiled code than we need. I'd prefer to 
avoid it.

I'm not sure why you mention a problem with TEXT macro. Current solution 
from winnt.rh uses u"" always when WINE_UNICODE_NATIVE is not used, so 
it's used in WINE_UNICODE_CHAR16 case as well. While it could be 
possible to try harder to make sure that it's supported by compiler, 
where is not much we can do about it. I don't see any fallback we could 
use in such case, so we may as well just let compiler fail to parse code 
that uses it in such case.



More information about the wine-devel mailing list