21
edits
International Characters Support: Difference between revisions
Jump to navigation
Jump to search
m
International Characters Support (view source)
Revision as of 07:46, 12 January 2019
, 12 January 2019Format identifiers as fixed-width
AndrewJanke (talk | contribs) (Correct wchar_t description) |
AndrewJanke (talk | contribs) m (Format identifiers as fixed-width) |
||
| Line 26: | Line 26: | ||
<q>Objects declared as characters (char) shall be large enough to store any member of the implementation's basic character set. If a character from this set is stored in a character object, the integral value of that character object is equal to the value of the single character literal form of that character. It is implementation-defined whether a char object can hold negative values. Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (basic.types); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types. In any particular implementation, a plain char object can take on either the same values as a signed char or an unsigned char; which one is implementation-defined.</q> | <q>Objects declared as characters (char) shall be large enough to store any member of the implementation's basic character set. If a character from this set is stored in a character object, the integral value of that character object is equal to the value of the single character literal form of that character. It is implementation-defined whether a char object can hold negative values. Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (basic.types); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types. In any particular implementation, a plain char object can take on either the same values as a signed char or an unsigned char; which one is implementation-defined.</q> | ||
What is important here is that usual characters should be declared as "chars" or "signed chars". "Unsigned char" means they MAY be submitted to truncation of the eighth bit, this is implementation- | What is important here is that usual characters should be declared as "chars" or "signed chars". "Unsigned char" means they MAY be submitted to truncation of the eighth bit, this is implementation-dependent. | ||
In order to support "wide" characters with an extended range of values, the storage type wchar_t was added to the C standard. The size of wchar_t is system dependent: on Windows, it is 2 bytes, and on Linux and macOS it is 4 bytes. Functions whose argument is | In order to support "wide" characters with an extended range of values, the storage type <code>wchar_t</code> was added to the C standard. The size of <code>wchar_t</code> is system dependent: on Windows, it is 2 bytes, and on Linux and macOS it is 4 bytes. Functions whose argument is <code>wchar_t</code> instead of <code>char</code> are generally prefixed by "w". | ||
=Character functions= | =Character functions= | ||
| Line 94: | Line 94: | ||
Functions like 'length' and size return the space required for string storage, which may be greater than the effective number of symbols. | Functions like 'length' and size return the space required for string storage, which may be greater than the effective number of symbols. | ||
Tests like 'isalpha' are | Tests like 'isalpha' are modeled as their lower-layers C counterpart and are not aware of UTF-8 nor locales. | ||
String search should be OK provided the two arguments are UTF-8 | String search should be OK provided the two arguments are UTF-8. | ||
Strings concatenation works with respect to UTF-8 | Strings concatenation works with respect to UTF-8. | ||
Displaying strings works in most circumstances except help message (bug report and patch recently provided) | Displaying strings works in most circumstances except help message (bug report and patch recently provided). | ||
Using non-ASCII strings as paths doesn't works. | Using non-ASCII strings as paths doesn't works. | ||
| Line 107: | Line 107: | ||
* short term: tests to ensure every string processing is 8-bit clean | * short term: tests to ensure every string processing is 8-bit clean | ||
* middle and long term: there are a number of options to fully support whatever symbols exist in Unicode: | * middle and long term: there are a number of options to fully support whatever symbols exist in Unicode: | ||
** make use of C wchar_t, char16_t, or char32_t types | ** make use of C <code>wchar_t</code>, <code>char16_t</code>, or <code>char32_t</code> types | ||
** make use of ICU [http://site.icu-project.org/], an open-source lib with various Unicode support functions | ** make use of ICU [http://site.icu-project.org/], an open-source lib with various Unicode support functions | ||
[[Category:Development]] | [[Category:Development]] | ||