[bug #57714] libintl: Unicode paths passed to bindtextdomain fail on Windows (when linked to the MSVCRT)

[INVALID.NOREPLY]

URL:
  <https://savannah.gnu.org/bugs/?57714>

                 Summary: libintl: Unicode paths passed to bindtextdomain fail
on Windows (when linked to the MSVCRT)
                 Project: GNU gettext
            Submitted by: pastdue
            Submitted on: Fri 31 Jan 2020 07:51:03 PM UTC
                Category: End-user / runtime
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

== Description: ==
libintl fails to load message catalogs from dirnames containing non-ASCII
UTF-8 characters

*Environment:* Windows
*Compiler:* MSVC, & presumably anything else that links to (any version of)
the MSVCRT

== To Reproduce: ==
With a Windows build linked to the MSVCRT:
* Call *bindtextdomain* with a UTF-8 dirname, containing characters outside of
the ASCII range (as works on other platforms)

== Expected Behavior: ==
libintl succeeds at finding message catalogs in the valid UTF-8 dirname

== Actual Behavior: ==
libintl fails to load message catalogs

== Cause: ==
*gettext-runtime/intl/loadmsgcat.c* uses *open()
<https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/open?view=vs-2019>*
internally, which does *not* support / expect UTF-8 filenames on the MSVCRT

== Solution: ==
*gettext-runtime/intl/loadmsgcat.c*: Provide a wrapper for *open()* that
converts the input _char*_ to a UTF-16 _wchar_t*_ and then calls *_wopen()
<https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/open-wopen?view=vs-2019>*,
which properly handles a Unicode path

I've attached an example patch (for an earlier version of libintl).
But note: the example patch requires linking to kernel32.lib on Windows for
_MultiByteToWideChar_. If you have an alternative recommendation for
converting UTF-8 char* to UTF-16 wchar_t* that would fit an upstream patch
better, please let me know.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Fri 31 Jan 2020 07:51:03 PM UTC  Name: example_patch.txt  Size: 1KiB  
By: pastdue

<http://savannah.gnu.org/bugs/download.php?file_id=48317>

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57714>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/