<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 8/15/19 7:12 AM, Steve Downey wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAJEGDKrCbPruBJNbMhOYfnQu5108R61-=YYF6J4wSfS34buNhg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto">Execution encoding is a term we use in
        conversation, it'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>
    </blockquote>
    <p>Indeed.  I just can't bring myself to use "character set" when
      the context calls for "encoding".  This is something else I'd like
      to clean up in the standard.<br>
    </p>
    <p>Tom.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAJEGDKrCbPruBJNbMhOYfnQu5108R61-=YYF6J4wSfS34buNhg@mail.gmail.com"><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" moz-do-not-send="true">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
          "execution encoding" 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.,
          "presumed execution encoding" and<br>
          &gt;&gt;&gt;&gt; "run-time/system/native execution encoding".<br>
          &gt;&gt;&gt; This would be implying that there's a single
          "execution" or "native"<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 "presumed execution encoding" distinction
          specifically for this<br>
          &gt;&gt; case.<br>
          &gt; Right, and I am saying that calling all the encodings
          "&lt;adjective&gt; execution<br>
          &gt; encoding" implies that they are if not the same, then
          somehow related, and<br>
          &gt; they aren't.<br>
          Ok, that is a fair critique.<br>
          &gt;<br>
          &gt; I would call the encoding used for narrow character
          literals "narrow literal<br>
          &gt; encoding" and the encoding used for wide character
          literals "wide literal<br>
          &gt; encoding". 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'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 "presumed execution encoding" as indicating a
          compatible subset <br>
          of all of the encodings used at run-time.<br>
          <br>
          &gt;<br>
          &gt; "Execution encoding" 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" target="_blank"
            rel="noreferrer" moz-do-not-send="true">Core@lists.isocpp.org</a><br>
          Subscription: <a
            href="https://lists.isocpp.org/mailman/listinfo.cgi/core"
            rel="noreferrer noreferrer" target="_blank"
            moz-do-not-send="true">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" target="_blank"
            moz-do-not-send="true">http://lists.isocpp.org/core/2019/08/7062.php</a><br>
        </blockquote>
      </div>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>