<div dir="auto">I think it&#39;s clear now that we don&#39;t have an answer to Tom&#39;s question in the title. And that the standard&#39;s language is both vague and archaic in this area. <div dir="auto">I think, before we make observable behavior changes, it would be worthwhile to respecify [lex] using more modern language, particularly distinguishing codepoints and encodings, and avoiding &#39;character&#39;, as being misleading. </div><div dir="auto"><br></div><div dir="auto">As observed in [filesystem] unsigned and signed char do not have associated encodings. Moving that forward into the front matter might be useful. As well as providing a (better) name for presumed narrow/wide character execution encoding and a better name for current default locale associated narrow/wide character encoding. </div><div dir="auto"><br></div><div dir="auto">I&#39;m willing to take a stab at it. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 15, 2019, 07:12 Steve Downey &lt;<a href="mailto:sdowney@gmail.com">sdowney@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Execution encoding is a term we use in conversation, it&#39;s not actually a term in the standard. The standard speaks of execution character sets, the values of which are determined by locale. Which locale is not specified.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 14, 2019, 23:21 Tom Honermann via Core &lt;<a href="mailto:core@lists.isocpp.org" target="_blank" rel="noreferrer">core@lists.isocpp.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 8/14/19 10:57 AM, Peter Dimov wrote:<br>
&gt; Tom Honermann wrote:<br>
&gt;&gt; On 8/14/19 3:54 AM, Peter Dimov wrote:<br>
&gt;&gt;&gt; Tom Honermann wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;   I think we *might* be successful in using &quot;execution encoding&quot; to<br>
&gt;&gt;&gt;&gt; apply to both the compile-time and run-time encodings by extending the<br>
&gt;&gt;&gt;&gt; term with specific qualifiers; e.g., &quot;presumed execution encoding&quot; and<br>
&gt;&gt;&gt;&gt; &quot;run-time/system/native execution encoding&quot;.<br>
&gt;&gt;&gt; This would be implying that there&#39;s a single &quot;execution&quot; or &quot;native&quot;<br>
&gt;&gt;&gt; encoding, whereas there are many.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; - encoding used for character literals<br>
&gt;&gt; I made the &quot;presumed execution encoding&quot; distinction specifically for this<br>
&gt;&gt; case.<br>
&gt; Right, and I am saying that calling all the encodings &quot;&lt;adjective&gt; execution<br>
&gt; encoding&quot; implies that they are if not the same, then somehow related, and<br>
&gt; they aren&#39;t.<br>
Ok, that is a fair critique.<br>
&gt;<br>
&gt; I would call the encoding used for narrow character literals &quot;narrow literal<br>
&gt; encoding&quot; and the encoding used for wide character literals &quot;wide literal<br>
&gt; encoding&quot;. This is what they are.<br>
<br>
I feel some reluctance to changing a term that has been around for so <br>
long, and this strikes me as too specific.  There are other constructs <br>
that are also encoded according to the (presumed) execution encoding.  <br>
For example source locations exposed via the __FILE__ macro, function <br>
names exposed via __func__, etc..<br>
<br>
We don&#39;t know at compile-time how encoded literals will be used at <br>
run-time.  They may be passed to the locale sensitive character <br>
conversion functions, used as filenames, written to a terminal, etc...  <br>
All of these encodings are not known until run-time.  I kind of like the <br>
use of &quot;presumed execution encoding&quot; as indicating a compatible subset <br>
of all of the encodings used at run-time.<br>
<br>
&gt;<br>
&gt; &quot;Execution encoding&quot; made sense when a program was, say, written in<br>
&gt; Krasnoyarsk and intended to be executed in Kuala Lumpur. A Krasnoyarsk<br>
&gt; machine used the Krasnoyarsk encoding for everything, and a Kuala Lumpur<br>
&gt; machine used the Kuala Lumpur encoding for everything. Hence source and<br>
&gt; execution.<br>
<br>
It still very much makes sense when cross-compiling today.<br>
<br>
Tom.<br>
<br>
_______________________________________________<br>
Core mailing list<br>
<a href="mailto:Core@lists.isocpp.org" rel="noreferrer noreferrer" target="_blank">Core@lists.isocpp.org</a><br>
Subscription: <a href="https://lists.isocpp.org/mailman/listinfo.cgi/core" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.isocpp.org/mailman/listinfo.cgi/core</a><br>
Link to this post: <a href="http://lists.isocpp.org/core/2019/08/7062.php" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.isocpp.org/core/2019/08/7062.php</a><br>
</blockquote></div>
</blockquote></div>