<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 8, 2019, 12:26 Niall Douglas &lt;<a href="mailto:s_sourceforge@nedprod.com" target="_blank" rel="noreferrer">s_sourceforge@nedprod.com</a>&gt; wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; To evaluate this, it would be important to state what the semantics for<br>
&gt; bytes are on Windows. Interpreting them according to the “ANSI” code<br>
&gt; page of the process would be traditional but does not allow addressing<br>
&gt; all files and goes directly against the motivation stated.<br>
<br>
Path view doesn&#39;t specify what consumers do with the path view data, but<br>
P1031 LLFIO currently always does this on Microsoft Windows:<br>
<br>
1. Byte input =&gt; Passthrough bytes untouched.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">On Windows, leaving the bytes “untouched” doesn’t really leave the untouched: the FooA() APIs convert to UTF-16 before the data reaches the kernel, so pretending on the C++ standard library layer that this does not happen is not useful and fails the stated goal of being able to represent file paths that don’t constitute a sequence of Unicode scalar values.</div><div dir="auto"><br></div><div dir="auto">Making this WTF-8 to UTF-16 conversion and then submitting the UTF-16 code units would allow addressing all NT file paths with 8-bit code units.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2. UTF-8 input =&gt; to UTF-16 conversion =&gt; Submit bytes.<br>
<br>
3. UTF-16 input =&gt; Passthrough bytes untouched.<br>
<br>
P1031 LLFIO does not use the ANSI Windows APIs, at all ever.<br>
<br>
<br>
For completeness, this is what P1031 LLFIO does on POSIX:<br>
<br>
1. Byte input =&gt; Passthrough bytes untouched.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">WTF-8 on Windows would be the best match for this behavior from the portability perspective.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2. UTF-8 input =&gt; Passthrough bytes untouched.<br>
<br>
3. UTF-16 input =&gt; to UTF-8 conversion =&gt; Submit bytes.<br>
<br>
In other words, the UTF-8/UTF-16 encoding is EXCLUSIVELY user side only.<br>
It is there merely for C++ code portability. It does not provide --<br>
because it cannot -- any form of portability once the bunch of bytes<br>
reach the OS kernel.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">But you don’t get to submit bytes to the NT kernel. You get to submit unsigned 16-bit code units.</div><div dir="auto"><br></div><div dir="auto">WTF-8 is the best way to let the application be written as if the NT kernel took bytes.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; I encourage the committee to look at supporting WTF-8<br>
&gt; (<a href="https://simonsapin.github.io/wtf-8/" rel="noreferrer noreferrer noreferrer" target="_blank">https://simonsapin.github.io/wtf-8/</a>) as an 8-bit-code-unit encoding that<br>
&gt; 1) Allows addressing all NT file paths<br>
&gt; 2) Is equivalent to UTF-8 for those NT file paths that have a textual<br>
&gt; interpretation.<br>
<br>
I must reiterate, once again, that filesystem paths are primarily<br>
matched by memcmp() on Microsoft Windows, and only if that does not<br>
match does a non-bits match OPTIONALLY occur.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The input to the matching operation is 16-bit units, though.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I already explained, different parts of a path may have different<br>
matching algorithms, because each directory on Microsoft Windows can<br>
specify how it is to be matched if exact match failed.<br>
<br>
Depending on those settings, UCS-16, UTF-16, or something may be used,<br>
per path item. This is TOTALLY outside user space control.<br>
<br>
WTF-8 is useful in many parts of Microsoft Windows, but for filesystem<br>
paths I find it of very limited utility.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That’s an odd position considering that file paths on modern (NT-kernel-era) Windows via the Win32 API is a motivating use case for the design of WTF-8 and there are other programming language standard libraries, plural, that use it for the Windows path purpose. See <a href="https://simonsapin.github.io/wtf-8/#implementations">https://simonsapin.github.io/wtf-8/#implementations</a></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am unaware of any valid<br>
use case for anything but a bunch of bits as filesystem path identifiers<br>
on BOTH POSIX and Windows. Neither lets you inform the OS of encoding<br>
per path, therefore these are bunches of bits. <br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">On Windows, the bits are sequences of 16-bit units. On POSIX they are sequences of 8-bit units. On Windows, if the 16-bit units form a valid UTF-16 sequence, the path has a textual interpretation. On modern* POSIXish systems, if the 8-bit units form a valid UTF-8 sequence, the path has a textual interpretation. WTF-8 allows one to write application code on Windows as if the paths had the modern POSIX properties. This is hugely valuable for writing portable application code that can still address file paths that don’t have a textual interpretation.</div><div dir="auto"><br></div><div dir="auto">* Configuring a POSIXish system in a different way counts explicitly as not modern for the purpose of this email.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>