<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 6, 2019 at 4:59 PM Thiago Macieira &lt;<a href="mailto:thiago@macieira.org">thiago@macieira.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Friday, 6 September 2019 13:09:23 PDT Tony V E wrote:<br>
&gt; On Fri, Sep 6, 2019 at 3:52 PM Thiago Macieira &lt;<a href="mailto:thiago@macieira.org" target="_blank">thiago@macieira.org</a>&gt; wrote:<br>
&gt; &gt; &gt; - if you encode the raw bytes, there might still be cases not covered,<br>
&gt; &gt; &gt; might need to fall back to UTF8.  It sounds like *no* answer will be<br>
&gt; &gt; &gt; guaranteed to work.<br>
&gt; &gt; <br>
&gt; &gt; Which case could there be that the raw bytes fail but UTF-8 supports? I<br>
&gt; &gt; would<br>
&gt; &gt; think it&#39;s the other way around.<br>
&gt; <br>
&gt; the case where the encoding changed.  Or the raw bytes are being used with<br>
&gt; the wrong FS API.<br>
<br>
The encoding is only needed when converting raw bytes to text. Since there&#39;s <br>
no conversion, the raw bytes are passed through unmodified from payload to <br>
filesystem API and from filesystem API to the payload.<br>
<br></blockquote><div><br></div><div>If I know which API it was from, and have it available to me.  And the filesystem 
encoding 

hasn&#39;t changed since then.  Niall gives me the impression that can change. (Or is that only the display encoding that can change?)<br></div><div><br></div><div>I know you listed all the rules for many scenarios (on linux do..., on MS do...) but it seems a bit precarious to me.  What happens when a new FS API comes around, or some other OS, EBCIDIC, etc?<br></div><div><br></div><div>How portable do we want/need this interchange files to be?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The two files below are simply bags of bytes:<br>
<br>
$ for f in /tmp/*.c; do paste - &lt;&lt;&lt;$f &lt;(printf $f | xxd -ps); done<br>
/tmp/�.c        2f746d702fe92e63<br>
/tmp/é.c        2f746d702fc3a92e63<br>
<br>
The pass-through is possible for all systems where the native FS API is 8-bit. <br>
This includes Cygwin and WSL.<br>
<br>
For systems where the FS API is natively 16-bit, we have a transformation of <br>
the 16-bit input to the 8-bit payload. That&#39;s CESU-8. That means the file <br>
C:\temp\é.c is represented by<br>
         43 3a 5c 74 65 6d 70 5c c3 a9 2e 63<br>
          C   :   \   t   e   m   p   \ 303 251   .   c<br>
<br>
Today, this applies to any system where _WIN32 is defined.<br>
<br>
Please note that this payload is compatible with all four types of tools <br>
runnable on Windows (Cygwin, WSL, MSVC and MinGW), so long as they agree on <br>
the root of the filesystem and how to represent separators. We weren&#39;t asked <br>
to provide feedback on that.<br>
<br>
&gt; &gt; &gt; Are there systems where filenames *that developers use* can&#39;t be found<br>
&gt; &gt; via<br>
&gt; &gt; &gt; UTF8?<br>
&gt; &gt; <br>
&gt; &gt; The problem is what happens when the locale isn&#39;t UTF-8, which is common<br>
&gt; &gt; enough when LC_ALL=C was set in the environment.<br>
&gt; <br>
&gt; And how common is that (besides you :-)<br>
<br>
Setting LC_ALL to C is recommended for any tool that needs to parse the output <br>
of another tool. Searching just qtbase in Qt, I found:<br>
<br>
        LC_ALL=C $AWK &lt;script goes here&gt;<br>
        LC_ALL=C $$QMAKE_CXX -E -v -xc++ -<br>
        LC_ALL=C readelf -l /bin/ls<br>
<br>
The following commits added the LC_ALL=C to the first and third examples, <br>
after real life failures in deployed code:<br>
<a href="https://code.qt.io/cgit/qt/qtbase.git/commit/?id=529a31c967a202458abd126d378a2" rel="noreferrer" target="_blank">https://code.qt.io/cgit/qt/qtbase.git/commit/?id=529a31c967a202458abd126d378a2</a><br>
<a href="https://code.qt.io/cgit/qt/qtbase.git/commit/?id=7839979c07e6f9e1a9c2e038f031f" rel="noreferrer" target="_blank">https://code.qt.io/cgit/qt/qtbase.git/commit/?id=7839979c07e6f9e1a9c2e038f031f</a><br>
<br>
Note how the AWK example isn&#39;t about parsing the output, it&#39;s for AWK to parse <br>
another input correctly.<br>
<br>
The middle one was introduced with LC_ALL=C from the first patch submission.<br>
<br>
-- <br>
Thiago Macieira - thiago (AT) <a href="http://macieira.info" rel="noreferrer" target="_blank">macieira.info</a> - thiago (AT) <a href="http://kde.org" rel="noreferrer" target="_blank">kde.org</a><br>
   Software Architect - Intel System Software Products<br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Be seeing you,<br></div>Tony<br></div></div></div>