<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 8:35 AM, Steve Downey wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAJEGDKotzpW+VeQRrD0kKmAcVSGCaHTOq_BarDmsztvY8TVahg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto">I think it's clear now that we don't have an
        answer to Tom's question in the title. And that the standard'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 'character', 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'm willing to take a stab at it. <br>
        </div>
      </div>
    </blockquote>
    <p>Excellent, me too.  I put this on the agenda for the next SG16
      telecon (on August 21st), but I strongly suspect we won't get to
      it as the first item on the agenda for that meeting is web_view
      and I think it will take most of our time.  So let's plan to have
      a draft (even if just a list of potential replacement terms and
      general strategy for parts of the standard to be updated) for the
      following telecon (September 4th or 11th).  We can collaborate
      offline in the mean time.<br>
    </p>
    <p>Tom.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAJEGDKotzpW+VeQRrD0kKmAcVSGCaHTOq_BarDmsztvY8TVahg@mail.gmail.com"><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"
            moz-do-not-send="true">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'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" 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" rel="noreferrer
                noreferrer" target="_blank" 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 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 noreferrer" target="_blank"
                moz-do-not-send="true">http://lists.isocpp.org/core/2019/08/7062.php</a><br>
            </blockquote>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>