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

[Jacek Caban]

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.


Thanks,

Jacek