[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?

Tom Honermann tom at honermann.net
Wed Aug 14 14:45:41 CEST 2019


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.




More information about the Unicode mailing list