On 8/14/19 3:54 AM, Peter Dimov 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
I made the "presumed execution encoding" distinction specifically for
this case.
> - what the locale has been set to (at compile time, at run time)
I made the "run-time/system/native execution encoding" distinction
specifically for this case.
> - what file names use, per filesystem, there can be more than one (*)
Indeed, I think path names need their own term.
> - what file contents use
The only suitable default assumption here is to match
"run-time/system/native execution encoding". Otherwise, explicit
specification is needed.
> - what the console/the terminal uses
Since historically the console/terminal encoding may differ (and in
practice does on Windows), I think a new term is needed for this case.
>
> (*) Here "none" (arbitrary NTBS not interpreted as characters by the
> FS) is an option
>
Except that, historically, some implementations apply locale
transformations to *some* of the filesystem interfaces. For example,
paths passed to std::fstream may be converted in a locale sensitive way
while paths passed to std::wfstream may not be.

Tom.