<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 14, 2019, 4:57 PM Peter Dimov <<a href="mailto:pdimov@gmail.com">pdimov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Tom Honermann wrote:<br>
> On 8/14/19 3:54 AM, Peter Dimov wrote:<br>
> > Tom Honermann wrote:<br>
> ><br>
> >> I think we *might* be successful in using "execution encoding" to <br>
> >> apply to both the compile-time and run-time encodings by extending the <br>
> >> term with specific qualifiers; e.g., "presumed execution encoding" and <br>
> >> "run-time/system/native execution encoding".<br>
> ><br>
> > This would be implying that there's a single "execution" or "native" <br>
> > encoding, whereas there are many.<br>
> ><br>
> > - encoding used for character literals<br>
><br>
> I made the "presumed execution encoding" distinction specifically for this <br>
> case.<br>
<br>
Right, and I am saying that calling all the encodings "<adjective> execution <br>
encoding" implies that they are if not the same, then somehow related, and <br>
they aren't.<br>
<br>
I would call the encoding used for narrow character literals "narrow literal <br>
encoding" and the encoding used for wide character literals "wide literal <br>
encoding". This is what they are.<br></blockquote></div><div><br></div><div>I strongly agree. Someone should write a paper :)</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
"Execution encoding" made sense when a program was, say, written in <br>
Krasnoyarsk and intended to be executed in Kuala Lumpur. A Krasnoyarsk <br>
machine used the Krasnoyarsk encoding for everything, and a Kuala Lumpur <br>
machine used the Kuala Lumpur encoding for everything. Hence source and <br>
execution..<br></blockquote></div><div><br></div><div>+1</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
...<br>
> > (*) Here "none" (arbitrary NTBS not interpreted as characters by the FS) <br>
> > is an option<br>
><br>
> Except that, historically, some implementations apply locale <br>
> transformations to *some* of the filesystem interfaces. For example, <br>
> paths passed to std::fstream may be converted in a locale sensitive way <br>
> while paths passed to std::wfstream may not be.<br>
<br>
Right, some FSs accept arbitrary NTBSs and guarantee a perfect roundtrip, <br>
and others do not and do not. But that's library. The point is that there is <br>
no single system execution encoding. Different parts of the system use <br>
different encodings. <br>
<br>
</blockquote></div>