Subject: Re: [SG16-Unicode] [isocpp-core] What is the proper term for the locale dependent run-time character set/encoding used for the character classification and conversion functions?
From: Tom Honermann (tom_at_[hidden])
Date: 2019-08-14 07:45:41
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
> - 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.
SG16 list run by firstname.lastname@example.org