On Wed, Aug 14, 2019, 9:54 AM Peter Dimov <pdimov@gmail.com> wrote:
Tom Honermann wrote:

>  I think we *might* be successful in using "execution encoding" to apply
> to both the compile-time and run-time encodings by extending the term with
> specific qualifiers; e.g., "presumed execution encoding" and
> "run-time/system/native execution encoding".

This would be implying that there's a single "execution" or "native"
encoding, whereas there are many.

- encoding used for character literals

We are specifically talking about that uniquely and how to refer to that.

Of course such strings will be interpreted with a different encoding to the one they were writing in at compile time - Even if the standard assumes compatibility between how a string is layed out in memory and how it will be interpreted by standard and system provided facilities.

- what the locale has been set to (at compile time, at run time)
- what file names use, per filesystem, there can be more than one (*)
- what file contents use
- what the console/the terminal uses

(*) Here "none" (arbitrary NTBS not interpreted as characters by the FS) is
an option

Probably the only portable option even.