<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 <<a href="mailto:sdowney@gmail.com"
moz-do-not-send="true">sdowney@gmail.com</a>> 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 <<a
href="mailto:core@lists.isocpp.org" target="_blank"
rel="noreferrer" moz-do-not-send="true">core@lists.isocpp.org</a>>
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>
> 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>
>>> 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>
>> I made the "presumed execution encoding"
distinction specifically for this<br>
>> case.<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>
Ok, that is a fair critique.<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>
<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>
><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>
<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>