ISO/IEC JTC1/SC22/WG14 N860
Title: Liaison statement from SC22/WG14 - C to WG15 - POSIX
Status: approved by WG14
Based on a report from the liaison officer (Keld Simonsen) from
WG14 to WG15, WG14 would like to submit the following information:
WG14 is in the process of revising the C standard, code-named C9X,
and with that revision a number of features which may be useful to
the further work in POSIX standardization will be provided:
To address n-bit neutrality:
Use of typedefs is encouraged.
The C9X standard provides a new header <stdint.h> with
definitions for exact-width and minimum-width types.
The FCD for C9X is available from the WG14 web site at
To address architecture neutrality:
Basically, there are no new facilities in C9X to help
with that problem, but we can offer common tricks of the trade:
For endianness, we recommend using macros similar to the
socket programming macros htons() et al.
There are no facilities in C9X to make explicit structure padding.
This could however be achieved by creating arrays of char formatted
as desired. Creating char arrays can also be used to control
For coded character set neutrality we recommend the use of
UTF-8 (which is in line with WG15's own recommendations).
1's complement vs. 2's complement: You should specify precisely
the interchange format, including sign, complement representation,
and bits of significance, then use the technique previously
It is probably difficult to use binary formats to interchange data
between different architectures, and a character representation
(probably using UTF-8) would be preferable.
WG14 recommends against incorporating the actual text for C9X in a
forthcoming revision of the POSIX standards, as that would make
maintenance cumbersome, with defect reports and technical corrigenda
processing on the same issues but via different channels and
procedures. We strongly recommend that changes to the C9X standard
be made in the form of conforming extensions only, for example
additional constraints, additional characteristics and propoerties,
or additional functions and headers, but in all cases not
contradicting requirements on conforming hosted implementations made
by the C9X standard. WG14 notes that a reference to the C9X
standard could be made to a specific edition of that standard by
a reference to the year of publication. On the other hand,
the changes of the C9X standard, including corrections of defects,
could be tracked by the POSIX standards by a reference without
the publication year.
With respect to participation from C experts in POSIX work, WG14
would like to help here, and could ask WG14 experts to engage
in reviewing POSIX drafts if information on the availability
of these could be sent to the WG14 reflector at
email@example.com . WG15 can also use this reflector to solicit
participation in WG15 work from WG14 experts.
In the revision of the C standard, WG14 has sought alignment
with ISO/IEC 9945-1:1996 and ISO/IEC 9945-2:1993 with respect
to internationalization APIs. In that process WG14 has found some
inconsistencies in monetary formatting, which we would like
to offer to WG15 for comment and possible implementation.
WG14 would like to work with WG15 on a registration of
the C and POSIX locales with the new cultural registry
in ISO/IEC 15897:1998.