Question about wide-char string literals

[Alex Henrie]

Hello everyone,

Currently the WineHQ Wiki's "Developer Hints" page says that L-strings
are only allowed in the source code of PE modules [1] (although the
"Code Hygiene" page still says that they are not allowed at all [2]).
However, if MinGW is not installed, Wine's build system will compile
that same source code with L-strings as an SO module and it works
thanks to the -fshort-wchar compiler flag. So what's stopping us from
using -fshort-wchar and L-strings everywhere?

-Alex

[1] https://wiki.winehq.org/Developer_Hints#Using_only_C89-compliant_code
[2] https://wiki.winehq.org/Code_Hygiene#Constants_as_Character_Arrays

[Stefan Dösinger]

> Am 13.11.2020 um 03:45 schrieb Alex Henrie :
>
> However, if MinGW is not installed, Wine's build system will compile
> that same source code with L-strings as an SO module and it works
> thanks to the -fshort-wchar compiler flag. So what's stopping us from
> using -fshort-wchar and L-strings everywhere?

A non-mingw compiled PE module will only call other Wine libraries and only use Wine headers, so -fshort-wchar is an option. A not-yet-split module like msvcrt.dll.so will include system headers and call unix libraries so we can't safely use -fshort-wchar.

[Alex Henrie]

On Fri, Nov 13, 2020 at 12:20 AM Stefan Dösinger
 wrote:
> Am 13.11.2020 um 03:45 schrieb Alex Henrie :
>
> However, if MinGW is not installed, Wine's build system will compile
> that same source code with L-strings as an SO module and it works
> thanks to the -fshort-wchar compiler flag. So what's stopping us from
> using -fshort-wchar and L-strings everywhere?
>
> A non-mingw compiled PE module will only call other Wine libraries and only use Wine headers, so -fshort-wchar is an option. A not-yet-split module like msvcrt.dll.so will include system headers and call unix libraries so we can't safely use -fshort-wchar.

Wouldn't that only be a problem if the module tried to call a wcs
function like wcslen, which we can't do right now anyway because wcs
functions expect an array of 4-byte characters and all the wide-char
functions in the Win32 API use 2-byte characters? Most system
functions don't use wchar_t at all and thus can be safely called no
matter how it's defined.

-Alex

[Stefan Dösinger]

> Am 13.11.2020 um 10:35 schrieb Alex Henrie :
> Wouldn't that only be a problem if the module tried to call a wcs
> function like wcslen, which we can't do right now anyway because wcs
> functions expect an array of 4-byte characters and all the wide-char
> functions in the Win32 API use 2-byte characters? Most system
> functions don't use wchar_t at all and thus can be safely called no
> matter how it's defined.

Possibly, but it seems fragile and too high a cost to get L"" literals.

You don't know what -fshort-wchar will do to the headers and inline functions in there. And having Wine's WCHAR and host wchar_t separate is a nice way to get compiler warnings if we accidentally mix them.

[Alex Henrie]

On Fri, Nov 13, 2020 at 12:45 AM Stefan Dösinger
 wrote:
> > Am 13.11.2020 um 10:35 schrieb Alex Henrie :
> > Wouldn't that only be a problem if the module tried to call a wcs
> > function like wcslen, which we can't do right now anyway because wcs
> > functions expect an array of 4-byte characters and all the wide-char
> > functions in the Win32 API use 2-byte characters? Most system
> > functions don't use wchar_t at all and thus can be safely called no
> > matter how it's defined.
>
> Possibly, but it seems fragile and too high a cost to get L"" literals.
>
> You don't know what -fshort-wchar will do to the headers and inline functions in there. And having Wine's WCHAR and host wchar_t separate is a nice way to get compiler warnings if we accidentally mix them.

That makes sense, thanks for the explanation. I suppose that being
able to catch wchar_t errors at compile time is worth the ugly syntax.
I'm glad that we're moving away from it though.

-Alex