[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSNativeChar type on Windows
From: |
Frederik Seiffert |
Subject: |
Re: GSNativeChar type on Windows |
Date: |
Sat, 15 Jan 2022 15:01:14 +0100 |
I did some more testing changing GSNativeChar to wchar_t, and I’m running into
one issue: When calling -[NSString fileSystemRepresentation] (which returns
"const GSNativeChar*") in an Objective-C++ file I’m getting the following
warning from libobjc2:
> Calling [GSCInlineString -fileSystemRepresentation] with incorrect signature.
> Method has r^S16@0:8 (r^S16@0:8), selector has r^i16@0:8
Calling the same method in an Objective-C file does not trigger the warning.
This seems to be because of the MSVC behavior around wchar_t explained in [1]:
> If /Zc:wchar_t is on, wchar_t is a keyword for a built-in integral type in
> code compiled as C++. If /Zc:wchar_t- (with a minus sign) is specified, or in
> code compiled as C, wchar_t is not a built-in type. Instead, wchar_t is
> defined as a typedef for unsigned short in the canonical header stddef.h
...
> The /Zc:wchar_t option is on by default in C++ compilations, and is ignored
> in C compilations.
...
> The wchar_t built-in type is not supported when you compile C code.
From the warning it seems like the built-in type (in C++) ends up as "i" (int)
in the type encoding. Is this expected?
One way I found to fix this is to define GSNativeChar as "__wchar_t", which is
the built-in type. However, this again causes warnings when calling Windows
APIs ("incompatible pointer types passing __wchar_t * to parameter of type
wchar_t *")...
I guess this means we should just leave GSNativeType as uint16_t, but I wanted
to see if anyone else has an idea about
Thanks!
Frederik
[1]
https://docs.microsoft.com/en-us/cpp/build/reference/zc-wchar-t-wchar-t-is-native-type
> Am 13.01.2022 um 16:44 schrieb Frederik Seiffert <frederik@algoriddim.com>:
>
> Hi all,
>
> I was wondering: does anyone know of a reason why GSNativeChar is defined as
> uint16_t instead of wchar_t in GSConfig.h on Windows?
>
> While they are probably technically the same (both are 16 bit on Windows),
> the latter would avoid a bunch of warnings / avoid having to cast when
> passing paths to Windows system APIs that expect wchar_t. This also applies
> to client code as this type is returned by NSString fileSystemRepresentation.
>
> If there’s no objections I’d like to change it to wchar_t.
>
> Thanks,
> Frederik
>