octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #61166] mkdir(parent, dirname) fails if parent


From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #61166] mkdir(parent, dirname) fails if parent does not exist
Date: Tue, 21 Sep 2021 11:30:05 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36 Edg/93.0.961.52

Follow-up Comment #7, bug #61166 (project octave):

I didn't look at their code. But I guess gnulib is using the Windows API that
MS calls "ANSI".
That takes `char *` for strings. These are interpreted in the system's (8 bit)
locale encoding. Not all characters can be represented in all locales.
There is another variant of the Windows API that MS calls "Unicode".
That takes `wchar_t *` for strings. Those are 16 bit wide on Windows. They are
required to be encoded in UTF-16 (not locale dependent).

Octave stores strings internally in UTF-8 wherever possible. We are converting
those to UTF-16 and use the Unicode Windows API in our code.
With that approach, we are able to access files or folders that contain
characters that cannot be represented in the system's locale (we had bug
reports about that in the past that imprinted in memory).
If we don't want to lose that, we'd need some interface changes to the gnulib
functions.

One possible way could be that gnulib required UTF-8 encoded strings on
Windows (always). But that would break existing code if it relies on `char *`
strings being encoded in the system's locale encoding.
Another possibility would be that gnulib duplicated their functions à la MS
and added functions that accepted `wchar_t *`.
Yet another possibility might be that they kept the functions with the current
API (i.e., locale encoded `char *` strings) and added new modules that
implement the same functions but using UTF-8 encoded `char *` strings (and the
Unicode API on Windows). We could select to use these UTF-8 modules.

None of those alternatives seem likely to happen.


Your changeset looks good to me and seems to work on Windows 10. It fixes the
example in comment #0.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]