On Mon, Mar 1, 2021 at 5:43 PM Steve Downey <sdowney_at_[hidden]> wrote:

>
>
> On Mon, Mar 1, 2021 at 5:17 PM Hubert Tong <
> hubert.reinterpretcast_at_[hidden]> wrote:
>
>> On Mon, Mar 1, 2021 at 11:27 AM Steve Downey via SG16 <
>> sg16_at_[hidden]> wrote:
>>
>>> Could we perhaps make use of the encoding used by the "C" locale to talk
>>> about how the "encoding of the execution character set" is meant to be
>>> interpreted? http://eel.is/c++draft/lex.ccon#2
>>> Execution encoding isn't currently used in the standard as that exact
>>> phrase, although lex.ccon does come close, as does
>>> http://eel.is/c++draft/tab:lex.string.literal
>>>
>> The sentence above is using "encoding of the execution character set" for
>> its position in the status quo of the working draft, right? That is, we
>> should read it as saying that the "literal encoding" can be taken as the
>> locale-specific encoding used in the C locale. In practice, that's not true
>> (e.g., literals encoded as UTF-8 on systems with a C locale using
>> US-ASCII). What is probably true is that the encoding difference is not
>> observable if only characters from the basic execution character set are
>> used. I think it is safe to say that there are seriously many
>> scripts/programs that (ab)use text processing facilities via the property
>> that "C" locales basically treat bytes as characters.
>>
>>>
>>> Yes, I'm trying to make sure we're agreeing what the status quo is that
> we're changing. Execution encoding isn't currently defined (although
> everyone thinks it is), so maybe we can just avoid defining it.
>
I think that makes sense. I guess "locale-specific narrow/wide encoding"
works.


> There's literal encoding and what locale provides for the associated
> encodings for char and wchar. That literal encoding may be different than
> that at runtime, and also from the "C" locale, is a large part of what
> we're trying to describe?
>
Yes.