PROPOSAL FOR A NEW WORK
ITEM
|
|
|
|
Date of presentation of
proposal: |
Proposer: |
|
Secretariat: |
ISO/IEC JTC 1/SC 22 N 3356 |
A proposal for a new work item shall be submitted to the secretariat of the ISO/IEC joint technical committee concerned with a copy to the ISO Central Secretariat.
Presentation of the proposal - to be completed by the proposer Guidelines for
proposing and justifying a new work item are given in ISO Guide 26.
|
|
|
Title Specification for additional character data types to the programming language C. |
|
Scope To introduce additional character data types and corresponding character and string literals to the programming language C (as defined in ISO/IEC 9899:1999). This will allow support for encodings such as UTF-16 in a portable way, examples will be included to show the use of these new data types. The relationship between the existing (char and wchar_t) character data types and the new types will be explained, a rationale for the choices made will also be documented. |
|
Purpose and justification The programming language C as specified by the International Standard ISO/IEC 9899:1999 provides two data types for character processing: char and wchar_t. For these data types a set of library functions is also specified. Current data processing systems have to be able to support many natural languages. This requires character sets that comprise more characters than can be represented in a single byte. Common approaches are to use a variable number of bytes for each character or to base the character encoding on 16-bit or 32-bit units. The C Standard requires that the type wchar_t be capable of representing any character in the current locale. However, a minimum width is not guaranteed. On the other hand, the width of wchar_t may be large, implying excessive memory requirements for application programs. In multi-user environments, as well as on mobile devices, memory is limited. Additional memory overhead means that cache limits will be exceeded more often and paging will occur more frequently. Using wchar_t, the portability of programs is limited since the width is platform-dependent. Some other programming languages support encodings based on 16-bit units or even use them as the processing character set. A number of database systems and some other commercially important software products offer APIs for UTF-16. UTF-16 is also a viable choice when migrating from UCS-2 implementations. When UTF-8 is used, byte-oriented APIs are sufficient, but for almost every commonly used language, the complexity of variable width characters shows up, except for the characters in the 7-Bit ASCII range. This work does not seek to change or invalidate the support for character sets currently used in C and C++ programs, but to make sure that portable support for a range of additional encodings is possible, including UTF-16. It is not proposed to define these additional character data types and corresponding character and string literals in an Amendment to the C standard but as a Technical Report type 2, which can at a later stage, and if deemed relevant, be included in the C standard as a new part or (normative of informative) annex. |
|
Programme of work If the proposed new work item is approved, which of the following
document(s) is (are) expected to be developed? |
|
Relevant documents to be considered · ISO/IEC 9899:1999 - Programming Language C · ISO/IEC JTC 1/SC22 WG14 N962 - Proposal for a work item - Additional character types · ISO/IEC 11404:1996 - Language-independent datatypes. |
|
Cooperation and liaison All ISO/IEC JTC 1/SC22 Working groups that have an interest in supporting many natural languages, especially ISO/IEC JTC 1/SC22 WG21 (C++). |
|
Preparatory work offered with target date(s) A PDTR document will be ready for registration 24 months after the approval of the project by JTC 1. |
|
Signature: Siegfried Badenmüller
|
|
Will the service of a
maintenance agency or registration authority be required?
.......NO............. Are there any known requirements for
coding? ..........NO......... Are there any known requirements for
cultural and linguistic adaptability? .....NO.... Does the proposed standard concern known
patented items? .......NO.......... |
Comments and recommendations of the JTC 1
Secretariat - attach a separate page as an annex, if necessary
|
|
|
Comments with respect to
the proposal in general, and recommendations thereon: |
Voting on the proposal - Each
P-member of the ISO/IEC joint technical committee has an obligation to vote
within the time limits laid down (normally three months after the date of
circulation).
|
|
||
|
Date of circulation:
|
Closing date for
voting: |
Signature of SC 22
Secretary: |
|
|
||
|
NEW WORK ITEM PROPOSAL - PROJECT ACCEPTANCE CRITERIA |
|
|
|
Criterion |
Validity |
Explanation |
|
A Business Requirement |
|
|
|
A.1 Market Requirement |
Essential ___ |
|
|
A.2 Regulatory Context |
Essential ___ |
|
|
B. Related Work |
|
|
|
B.1 Completion/Maintence of current standards |
Yes ___ |
|
|
B.2 Commitment to other organization |
Yes ___ |
|
|
B.3 Other Source of standards |
Yes ___ |
|
|
C. Technical Status |
|
|
|
C.1 Mature Technology |
Yes ___ |
|
|
C.2 Prospective Technology |
Yes ___ |
|
|
C.3 Models/Tools |
Yes ___ |
|
|
D. Conformity Assessment and Interoperability |
|
|
|
D.1 Conformity Assessment |
Yes ___ |
|
|
D.2 Interoperability |
Yes ___ |
|
|
E. Other Justification |
|
|
Notes to Proforma
A. Business Relevance. That which identifies market place relevance in terms of what problem is being solved and or need being addressed.
A.1. Market Requirement. When submitting a NP, the proposer shall identify the nature of the Market Requirement, assessing the extent to which it is essential, desirable or merely supportive of some other project.
A.2 Technical Regulation. If a Regulatory requirement is deemed to exist - e.g. for an area of public concern e.g. Information Security, Data protection, potentially leading to regulatory/public interest action based on the use of this voluntary international standard - the proposer shall identify this here.
B. Related Work. Aspects of the relationship of this NP to other areas of standardization work shall be identified in this section.
B.1 Competition/Maintenance. If this NP is concerned with completing or maintaining existing standards, those concerned shall be identified here.
B.2 External Commitment. Groups, bodies, or fora external to JTC1 to which a commitment has been made by JTC for cooperation and or collaboration on this NP shall be identified here.
B.3 External Std/Specification. If other activities creating standards or specifications in this topic area are known to exist or be planned, and which might be available to JTC1 as PAS, they shall be identified here.
C. Technical Status. The proposer shall indicate here an assessment of the extent to which the proposed standard is supported by current technology.
C.1 Mature Technology. Indicate here the extent to which the technology is reasonably stable and ripe for standardization.
C.2 Prospective Technology. If the NP is anticipatory in nature based on expected or forecasted need, this shall be indicated here.
C.3 Models/Tools. If the NP relates to the creation of supportive reference models or tools, this shall be indicated here.
D. Any other aspects of background information justifying this NP shall be indicated here.
D. Conformity Assessment and Interoperability
D.1 Indicate here if Conformity Assessment is relevant to your project. If so, indicate how it is addressed in your project plan.
D.2 Indicate here if Interoperability is relevant to your project. If so, indicate how it is addressed in your project plan.