ISO/ IEC JTC1/SC22/WG14 N847

SC22/WG14 N847 1998-09-04

               Issues with CD2
                Clive Feather

The following 43 items represent issues with CD2. Regrettably, many of them
were also issues with CD1 and do not seem to have been addressed; where
possible the item has been rewritten to explain the problem better.

Items 1 to 42 are in order of location within CD2.

[Item 01, based on PC-UK0021]

Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 4

Title: Further requirements on the conformance documentation

Detailed description:

The Standard requires an implementation to be accompanied by documentation
of various items. However, there is a subtle difference between the terms
"implementation-defined" and "described by the implementation" which has
been missed by this wording (this is partly due to the tightening up of the
uses of this term between C89 and C9X - see for example subclause 6.10.6).
As a result, the wording does not actually require the latter items to be

Change the paragraph to:

    An implementation shall be accompanied by a document that describes
    all features that this International Standard requires to be described
    by the implementation, including all implementation-defined
    characteristics and all extensions.

[Item 02, based on PC-UK0001]
Category: Editorial change/non-normative contribution
Committee Draft subsection:

Title: Error in applying working paper N673

Detailed description:

When N673 was applied to the draft, a new footnote was erroneously left
out. The following footnote should be included, with a reference at the end
of translation phase 2:

    [*] Thus the physical source lines (delimited by | characters):
    generate the logical source lines:
    and a source file may end with a backslash followed by two
    physical newlines, which will generate a last logical source
    line ending in a backslash.

[Item 03]

Category: Feature that should be included
Committee Draft subsection:, 5.2.2,

Title: provide a \s character

Detailed description:

Translation phase 5 states that if the execution character set cannot
represent a character in the source set, it is converted to "an
implementation-defined member" (of the execution character ser). It would
be useful to have access to this character in an consistent manner, and the
escape sequence \s ("substitute") is proposed for this purpose.

Change translation phase 5 ( to end:

    if there is no corresponding member, it is converted to the
    character represented by \s.

In 5.2.2p2, add a entry to the list:

    \s (substitute) Produces a visible indication that a source character
    was used that does not correspond to a member of the execution
    character set. The active position is advanced as for a graphic

In, add \s to "simple-escape-sequence" in p1 and to the list in p8.

[Item 04, based on PC-UK0027]

Category: Inconsistency
Committee Draft subsection: 5.2.1 plus scattered other changes

Title: inconsistencies in use of "basic" and "extended" character sets

Detailed description:

[Please note: this is *not* a UCN issue.]

The Standard uses the terms "basic character set" and "extended character
set" at various places. However, the exact meaning of these two is not
clear, and this leads to confusion.

Consider the UTF-8 encoding (codes from 0 to 127 are single byte, codes
from 128 to 255 form part of multibyte characters with length from 2 to 5
bytes). At execution time here are five "interesting" character sets based
on this encoding:

[1] The 95 characters required by 5.2.1p3, plus the null character.
[2] The 128 single byte characters.
[3] The 2**31 multibyte characters.
[4] Set [3] minus set [1].
[5] Set [3] minus set [2].

(and of course the corresponding source sets).

It is unclear whether the "basic character set" means [1] or [2] or something
else, and as a result the Standard has to use circumlocutions such as "the
required characters". Looking at the various places where the term is used
has led me to believe that it is most useful to have terms for [1] and
for [4], while there is little or no need to refer to any of the others.
Therefore it would be logical for "basic character set" to represent [1] (the
set of characters required in all implementations) and "extended character
set" to represent [4] (any other characters provided by the specific

This requires the following changes:

Replace 5.2.1p1, second sentence, by:

    Each set is further divided into a /basic character set/, whose contents
    are given by this subclause, and an /extended character set/, consisting
    of zero or more locale-specific members (which are not members of the
    basic character set).

[Note that this defines the two terms.]

In 5.2.1p3, delete "at least" in the first sentence, and in the fourth
sentence change "In the execution character set" to "In the basic
execution character set".

Replace, first bullet, by:

    - The basic character set shall be present and shall be encoded
      using single-byte characters.

In 6.2.5p3, replace "required source character set enumerated in 5.1.2"
with "basic execution character set". (Note that the execution set is more
sensible in this context than the source set.)

In, change "that are not part of the required source character
set" to "that are in the extended source character set".

In 6.4.3p2 and p3, change "required" to "basic".

In change "required" to "basic".

Change 7.1.1p2 to:

    A /letter/ is one of the 52 lowercase and uppercase letters in the
    basic extension character set. All letters are printing characters.

In Annex Ip2, delete "required".

In Annex K.2p1, third bullet, change "required" to "basic".

In Annex K.2p1, fifth bullet, delete "required".

In Annex K.3.4p1, fourth bullet, change "required" to "basic".

Change K.4p1, first bullet, to:

    - Any members of the extended execution character set (5.2.1).

Change K.4p1, second bullet, to:

    - The presence, meaning, and representation of any multibyte
      characters in the extended execution character set (

In Annex K.5.2p1, change "required" to "basic".

[Item 05, based on PC-UK0015]

Category: Feature that should be included
Committee Draft subsection:

Title: ensure int can hold all characters

Detailed description:

A number of functions in the standard library (particularly in <ctype.h> and
<stdio.h> assume that an int is capable of holding every possible unsigned
char value. If this is not the case then these functions will, to say the
least, behave in a peculiar manner. While it is arguable to say that this
implies that int must be able to hold every unsigned char value, it would
be better to make this an explicit requirement on the implementation.

To do so, append to

    On a hosted implementation, INT_MAX shall be not less than UCHAR_MAX.

Note that this does *not* forbid char and int from being the same type.

[Item 06, based on PC-UK0047]

Category: Request for information/clarification
Committee Draft subsection: 6.10

Title: Parsing ambiguity in preprocessing directives

Detailed description:

Consider parsing the following text during the preprocessing phase
(translation phase 4):

    # if 0
    # else
    # endif

The third line fits the syntax for the first option of group-part, and thus
generates two possible parsings. One of these will cause both text lines to
be skipped, while the other only causes the second to be skipped.

It is easy to fix this ambiguity. In the syntax in 6.10p1, change group-part

        non-directive new-line

and add:


Then add a new paragraph to the Constraints, after 6.10p3:

    The first preprocessing-token (if any) in a non-directive shall not
    be /#/.

Finally, delete 6.10.3p8, because this can no longer occur.

Note that this change has the added benefit of making it clear that unknown
preprocessing directives require a diagnostic and do not affect conditional

[Item 07, based on PC-UK0049]

Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 6.10.1

Title: Handling of UCNs in character constants in #if directives

Detailed description:

Consider the line:

    #if '\u0024' < 100

where dollar is in the single-byte execution character set. It is not
completely clear from 6.10.1p3 that the UCN is converted to a single
character, since this normally happens in translation phase 5 and it is
not specifically mentioned here.

In 6.10.1p3 (near the end), change:

    ... which may involve converting escape sequences into execution
    character set members.


    ... which may involve converting escape sequences and universal
    character names into execution character set members in the manner
    of translation phase 5.

[Item 08, based on PC-UK0071]

Category: Inconsistency
Committee Draft subsection: 6.10.2

Title: Clarify included file process

Detailed description:

6.10.2p3 ends:

    If this search is not supported, or if the search fails, the directive
    is reprocessed as if it read

        #include <h-char-sequence> new-line

    with the identical contained sequence (including > characters, if any)
    from the original directive.

The wording is technically incorrect, precisely because the original
directive could contain angle brackets within the quotes whereas an
h-char-sequence cannot. Better wording would be:

    If this search is not supported, or if the search fails, the directive
    is reprocessed as if it read

        #include <h-char-sequence> new-line

    with the identical contained sequence from the original directive
    (if the q-char-sequence contains a > character, this is retained in
    the name searched for even though it could not appear in a true

[Item 09, based on PC-UK0052]

Category: Feature that should be included
Committee Draft subsection: 6.10.3

Title: Add a __VA_COUNT__ facility for varargs macros

Detailed description:

Unlike with function calls, it is trivial for an implementation to
determine the number of arguments that match the ... in a varargs macro.
There are a number of useful things that can be done with this (at the
least, providing argument counts to varargs functions). Therefore this
information should be made available to the macro expansion.

In 6.10.3p5, change
    The identifier /__VA_ARGS__/ ...
    The identifiers /__VA_ARGS__/ and /__VA_COUNT__/ ...

Append to

    An identifier /__VA_COUNT__/ that occurs in the replacement list
    shall be replaced by a single token which is the number of trailing
    arguments (as a decimal constant) that were merged to form the variable

[Item 10, based on PC-UK0054]

Category: Other: C++ conflict avoidance
Committee Draft subsection: 6.10.8

Title: Require that __cplusplus not be defined

Detailed description:

Add to 6.10.8 a new paragraph 5:

    The implementation shall not predefine the macro /__cplusplus/,
    nor shall it define this macro in any header defined in clause 7.

This change was agreed by the full committee at the Menlo Park meeting, but
seems to have been lost.

[Item 11, based on PC-UK0169]

Category: Feature that should be included
Committee Draft subsection: 6.10.8

Title: provide a __STDC_HOSTED__ macro

Detailed description:

There is currently no way for a program to determine if the implementation
is hosted or freestanding. A standard predefined macro should be provided.

Add to the list in 6.10.8p1:

    __STDC_HOSTED__  The decimal constant 0 if the implementation is a
                     freestanding one and the decimal constant 1 if it is
                     a hosted one.

[Item 12, based on PC-UK0024]

Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.2.5

Title: Replace footnote 25

Detailed description:

Footnote 25 is unclear in the context in which it appears (implementation-
defined types). The wording of footnote 29 explains what is meant much more
clearly, and can be applied to both situations.

Replace the text of footnote 25 with that of footnote 29, and change all
references to the latter to be references to the former.

[Item 13, based on PC-UK0050]

Category: Inconsistency
Committee Draft subsection:,

Title: Effects on other members of assigning to a union member

Detailed description: has wording concerning the storing of values into a union member:

    With one exception, if the value of a member of a union object is
    used when the most recent store to the object was to a different
    member, the behavior is implementation-defined.

When this wording was written, "implementation-defined" was interpreted
more loosely and there was no other relevant wording concerning the
representation of values. Neither of these is the case anymore.

The requirement to be implementation-defined means that an implementation
must ensure that all stored values are valid in the types of all the other
members, and eliminates the possibility of them being trap representations.
It also makes it practically impossible to have trap representations at all.
This is not the intention of other parts of the Standard.

It turns out that the wording of is sufficient to explain the
behavior in these circumstances, and the cited wording in merely
muddles the issue. It should be removed; the rest of the paragraph can
stand alone.

[Item 14]

Category: Improved terminology (technically normative)
Committee Draft subsection: 6.3.4, plus scattered other changes

Title: better terminology for object lifetimes

Detailed description:

The term "lifetime" is used at a few places in the Standard but never
defined. Meanwhile a number of places uses circumlocutions such as "while
storage is guaranteed to be reserved". These would be much easier to read
if the term "lifetime" was defined and used.

Make the following changes to subclause 6.3.4.

Delete paragraph 5 and insert a new paragraph between 1 and 2:

    The /lifetime/ of an object is the portion of program execution
    during which storage is guaranteed to be reserved for that object.
    An object exists and retains its last-stored value throughout its
    lifetime. Objects with static or automatic storage duration have a
    constant address throughout their lifetime.23 If an object is referred
    to outside its lifetime, the behavior is undefined. The value of a
    pointer is indeterminate after the end of the lifetime of the object
    it points to.

Change paragraphs 2 to 4 (which will become 3 to 5) to:

    [#2] An object whose identifier is declared with external or
    internal linkage, or with the storage-class specifier static,
    has static storage duration. The lifetime of the object is the
    entire execution of the program. Its stored value is initialized
    only once.

    [#3] An object whose identifier is declared with no  linkage
    and without the storage-class specifier static has automatic
    storage duration. For objects that do not  have  a  variable
    length  array type, the lifetime extends from entry into the
    block with which it is associated until execution of the block
    ends in any way. (Entering an enclosed block or calling a function
    suspends, but does  not end, execution of the current block.)
    If the block is entered recursively a new object is created each
    time. The initial value of the object is indeterminate; if an
    initialization is specified for the object, it is performed each
    time the declaration is reached in the execution of the block;
    otherwise, the value  becomes indeterminate each time the
    declaration is reached.

    [#4] For objects that do have a variable length array type, the
    lifetime extends from the declaration of the object until execution
    of the program leaves the scope of that declaration24. If the scope
    is entered recursively a new object is created each time. The initial
    value of the object is indeterminate.

Other changes:

In 5.1.2p1 change "in static storage" to "with static storage duration".

Change footnote 9 to:

    9) In accordance with 6.2.4, a call to exit will remain within the
    lifetime of objects with automatic storage duration declared in main
    but a return from main will end their lifetime.

Delete as it just duplicates material in 6.2.4p3-4.

Change the last portion of to:

    of  the  loop only, and on entry next time around p would be
    pointing to an object outside of its lifetime, which would
    result in undefined behavior.

Change the last portion of footnote 72 to:

    and the address of an automatic storage duration object after the
    end of its lifetime.

Change the first sentence of to:

    Here an execution of B means the lifetime of a notional object with 
    type /char/ and automatic storage duration associated with B.

Add to 7.20.3 a second paragraph:

    The lifetime of an object allocated by the calloc, malloc, or
    realloc functions extends from the function call until the
    object is freed by the free or realloc functions. The object has a
    constant address throughout its lifetime except when moved by a call
    to the realloc function.

The last sentence of 7.20.3p1 is redundant and could be deleted.

Relevant bullet points in annex K should also be changed.

[Item 15]

Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.4.3

Title: reword the list of forbidden UCNs

Detailed description:

Change 6.4.3p2 to read:

    A universal-character-name shall not specify (in either form) a
    character short identifier less than 000000A0 other than:
        00000024  00000040  00000060
    or in the range 0000D800 to 0000DFFF inclusive.

This wording makes it easier to understand the restriction, because it is
not necessary to cross-reference the list in 5.2.1 and then determine the
UCNs of those characters.

[Item 16, based on PC-UK0026]

Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.4.5

Title: improve the example of character string literals

Detailed description:

Append to 6.4.5p7, the example:

    When this is used to initialize a static array, the array has three
    members that are initialized to /18/, the value of /'3'/, and /0/

[Item 17, based on PC-UK0036]

Category: Normative change where the intent is unclear
Committee Draft subsection: 6.5.16

Title: Define the result of the assignment operator

Detailed description:

6.5.16p3 states:

    An assignment expression has the value of the left operand after the
    assignment, but is not an lvalue.

Two interpretations have been put on this wording:
* the value of the assignment expression is the value that will also be
  stored in the left operand ("same-value" semantics);
* the value of the assignment expression is the result of reading the left
  operand after storing the value in it ("write-then-read" semantics).
These two have different results when the left operand is a volatile object
that can be changed by external causes (such as a clock or a memory-mapped
device register). This ambiguity needs to be resolved.

Consider the code:

    int x;
    extern volatile int system_timer;  // precision of 1 microsecond
    extern volatile int serial_port;   // writing sends a word, reading
                                       //   returns the next word received
    // ...
    x = system_timer = 42;  // statement 1
    serial_port = 66;       // statement 2

With same-value semantics, statement 1 will set x to 42 and will send the
value 66 to the serial port. With write-then-read semantics, statement 1
will set x to some other value (the change in the timer between writing to
it and reading it back).

More important, though, is the effects of statement 2 in write-then-read
semantics. Because a statement expression is evaluated for its side effects,
it is reasonable to require the value of the assignment statement to be
determined before being thrown away (in particular, there is *no* statement
in the Standard as to when the value of the assignment expression is or is
not evaluated). This means that statement 2 always has the side effect of
reading a word from the serial port, and there is no way to write without

Assuming that same-value semantics are intended, replace the cited words

    The value of the assignment expression is the value stored into the
    left operand, but is not an lvalue.

If write-then-read semantics are intended, replace the cited words by
something along the lines of:

    The value of the assignment expression is the result of reading the
    left operand after the value has been stored in it [*], but is not an
    lvalue. If the value of the assignment expression is not used as an
    operand in another expression,it is unspecified whether or not the
    left operand is actually read.

    [*] Thus if the left operand has volatile-qualified type and can be
    changed by external means, the value of the expression might not be
    the same as the value stored.

[I do *not* claim that these later words actually have the desired effect.]

[Item 18, based on PC-UK0033]

Category: Editorial change/non-normative contribution
Committee Draft subsection:

Title: Fix wording relating to "number of arguments"

Detailed description: states "the number of arguments shall agree with the number of
parameters". This does not clearly take account of varargs functions.
Similarly the second sentence does not allow for the trailing arguments of
varargs functions.

Change the paragraph to:

    If the expression that denotes the called function has a type that
    includes a prototype, the number of arguments shall agree with the
    number of parameters (that is, if the prototype contains an ellipsis
    there shall be at least as many arguments as parameters, otherwise
    there shall be the same number of arguments as parameters). Each
    argument that corresponds to a declared parameter shall have a type
    such that its value may be assigned to an object with the unqualified
    version of the type of its corresponding parameter.

[Item 19, based on PC-UK0003]
Category: Normative change to existing feature retaining the original intent
Committee Draft subsection:,

Title: Adjustment to permitted incompatible argument types

Detailed description:

At the Menlo Park meeting we agreed to amend to permit
incompatible parameter and argument types in certain cases where the
representation is required to be the same. The cases permitted form the two
bullet points at the end of the paragraph. However, the second case was
intended to be slightly wider than the wording appearing in the draft; it
should have been:

    - both types are pointers to qualified or unqualified versions of /void/
      or of character types.

(in other words, it should be possible to pass unsigned char * values to
parameters of type char * as well as of void *).

The same change needs to be made in

[Item 20]

Category: Normative change to existing feature retaining the original intent
Committee Draft subsection:

Title: Forbid sizeof bit-fields when not lvalues

Detailed description:

Consider the expression:

    sizeof func().bit_field

This is currently not forbidden by because it is not an lvalue.
This is clearly an oversight.

Change to:

    The sizeof operator shall not be applied to an expression that has
    function type, an incomplete type, a bit-field type, or to the
    parenthesized name of any such type.

[Item 21, based on PC-UK0017]

Category: Editorial
Committee Draft subsection: 6.5.9

Title: tidy up changes to pointer comparison

Detailed description:

Though the wording is mostly correct, 6.5.9p6 does not complete cover every
case and does not make it clear that it is exhaustive.

Append to 6.5.9p6:

    Otherwise they shall compare unequal.

Append to footnote 80:

    Two different subobjects of an object are not "the same object" and
    pointers to them compare unequal.

[Item 22, based on PC-UK0040]

Category: Normative change to intent of existing feature
Committee Draft subsection:

Title: Bitfields of unsupported types should require a diagnostic.

Detailed description:

If a bitfield is declared with a type other than /_Bool/ or plain, signed,
or unsigned int, the behavior is undefined. Since this can easily be
determined at compile time, a diagnostic should be required. It is
reasonable to exempt other integer types that the implementation knows how
to handle.

Add to the end of

    A bit-field shall have a type that is a qualified or unqualified
    version of /_Bool/, /signed int/ or /unsigned int/, or of some other
    implementation-defined integer type.

Delete the first sentence of

Note that this wording allows additional implementation-defined bitfield
types so long as they are integers. If they are not, the behaviour would
not be defined by the Standard and so a diagnostic should still be required.
An implementer can also allow non-integer bitfield types, but a diagnostic
is still required.

[Item 23, based on PC-UK0007]

Category: Other: outstanding problem
Committee Draft subsection:

Title: Problem with restrict and string literals

Detailed description:

Consider any function which takes two char * parameters where one of them
is restrict-qualified and a call where the corresponding arguments are
both string literals. For example:

    char *s = "test string\n";
    printf ("This - %s - is the test string\n", s);

Because of the restrict qualification, it is not permitted for the two
strings to share storage. However, an implementation is entitled to let the
literals do so, quite possibly without the programmer realizing that the
situation happened (for example, the first parameter might be a macro
defined in a makefile).

A similar situation occurs when compound literals share storage; in this
case the parameters might have almost any restrict-qualified type.

One solution would be to exempt unmodifiable objects from the requirements
of restrict. Another would be to adopt alternative semantics for restrict
as proposed by the UK (that the object pointed to by a restrict-qualified
pointer is either not altered or is only accessed via that pointer).

[Item 24, based on PC-UK0042]

Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.7.4

Title: Clarify some aspects of inline

Detailed description:

A good inlining implementation can inline calls to the comparison function
of qsort and other indirect calls. It should be clearer that this is

In 6.7.4p6, add a footnote referenced at the end of the last but one
sentence ("An inline definition provides ... the same translation unit"):

    [*] The call need not be due to the direct appearance of the name of
    the function at the point of calling; it may be through some kind of

[Item 25, based on PC-UK0042]

Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.7.4

Title: Clarify some aspects of inline

Detailed description:

The exact relationship between the inline and extern keywords is not
obvious, particularly when the extern declaration of an inline function
occurs after its definition. For this reason it should be made clearer in
the examples. In 6.7.4p8, after:

    because /fahr/ is also declared with /extern/


    (even though that declaration is not visible at the definition of

[Item 26, based on PC-UK0167]

Category: Normative change to intent of existing feature
Committee Draft subsection:

Title: require side effects in VLA declarations to work normally

Detailed description: states in part:

    It is unspecified whether side effects are produced when the size
    expression is evaluated.

This rule will be extremely confusing to the normal programmer. It places
a unreasonable burden on anyone who needs to write code with side-effects
(particularly if the size is determined via a function call), and it does
not offer any significant benefit to the implementation; to see this,
consider that, however the implementation handles:

    int vla [n++][func()];

it must correctly handle the equivalent code:

    int vla_size [2] = { n++, func () };
    int vla [vla_size [0]][vla_size [1]];

Other issues, such as the order of side effects, can be ignored here and
handled in the same way as elsewhere in the Standard. See the WG14
archives for a fuller discussion of the topic.

Change required: delete this sentence.

[Item 27, based on PC-UK0046]

Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.7.7

Title: Correct ranges of bitfields in an example

Detailed description:

In 6.7.7p6, example 3, describes the ranges of various bit-fields in terms
of "at least the range". This is because C89 was not clear on what the
permitted ranges of integer types was. These ranges are now tightly
specified by, and so the wording of this example should be altered

- change "at least the range [-15, +15]"
  to "either the range [-15, +15] or the range [-16, 15]"
- change "values in the range [0, 31] or values in at least the range
  [-15, +15]"
  to "values in one of the ranges [0, 31], [-15, +15], or [-16, +15]"

[Item 28, based on PC-UK0014]

Category: Inconsistency
Committee Draft subsection: 6.7.8

Title: problems with initializing unsigned char arrays.

Detailed description:

Consider the following declaration:

    unsigned char s [] = "\x80\xff";

The first element of the string literal has the value:

    (char) 128

and the second element has the value:

    (char) 255

If the type char is signed and CHAR_MAX is less than 128, these two
expressions are implementation-defined. In particular, on a ones-
complement implementation likely values are -127 and -0 respectively.
When these are converted back to unsigned char during the initialization,
then (if UCHAR_MAX is 255) they will be converted to 129 and 0 respectively.
This is *not* intuitive. Furthermore, while I do not have access to an
implementation with ones-complement arithmetic, I suspect that they apply
"copy bytes" semantics for initialization, rather than the "double cast"
semantics that the strict wording requires.

The following changes provide the more intuitive semantics:

Append to 6.7.8p14:

    The value of each element is determined by converting the corresponding
    numerical representation of the mapped character, or the octal or
    hexadecimal escape sequence, directly to the array element type,
    not via the type char.

Append to example 8 in 6.7.8p32:

    The declaration:

        unsigned char c [] = "\xFF";

    is identical to:

        unsigned char c [2] = { 0xFF, 0 };

    and not to:

        unsigned char c [2] = { (unsigned char)(char) 0xFF, 0 };

    (the latter could be different if /CHAR_MAX/ is less than 255 and
    the implementation-defined value of the expression /(char) 0xFF/
    is not equal to /254-UCHAR_MAX/).

[Item 29, based on PC-UK0072]

Category: Feature that should be included
Committee Draft subsection:, 7.20.4

Title: _exit function

Detailed description:

As part of a working paper (N789), I suggested that C provide an _exit()
function like that in POSIX, and signal handlers should be allowed to
call this function. The Menlo Park meeting agreed to add this function
unless an unresolvable technical issue was found that would make it not
conformant to POSIX - no such issue has been raised. Since the meeting I
have made some minor improvements to the wording.

In, change:

    or the signal handler calls any function in the standard library
    other than the /abort/ function or the /signal/ function


    or the signal handler calls any function in the standard library
    other than the /abort/ function, the /_exit/ function, or the
    /signal/ function

Add a new subclause within 7.20.4:

    7.20.4.X The _exit function


    #include <stdlib.h>
    void _exit (int status);


    The /_exit/ function causes normal program termination to occur,
    and control to be returned to the host environment. No functions
    registered by the /atexit/ function or signal handlers registered by
    the /signal/ function are called. The /_exit/ function never returns
    to the caller. The status returned to the implementation is determined
    in the same manner as for the /exit/ function. It is implementation-
    defined whether open output streams are flushed, open streams closed,
    or temporary files removed.

[Item 30, based on PC-UK0056]

Category: Feature that should be included
Committee Draft subsection: 7.17

Title: Add a symbol giving the maximum alignment

Detailed description:

When writing functions that use the results of malloc in a general
way (such as malloc wrappers) it is necessary to know what the worst
possible alignment is. This value is known to the implementation in order
to provide malloc in the first place, but cannot be derived by an
application program. Thus it is eminently suitable for standardisation.

Typical use might be:

    struct mallocinfo { char *file; unsigned line; time_t time };
    #define HDRSIZE (((sizeof (struct mallocinfo) - 1) / _ALIGNMENT_ALL \
                      + 1) * _ALIGNMENT_ALL)
    void *my_malloc (size_t n, char *file, unsigned line)
        unsigned char *p = malloc (n + HDRSIZE);
        if (p == NULL) return p;
        struct mallocinfo *h = (struct mallocinfo *) p;
        h->file = file;
        h->line = line;
        h->time = localtime();
        return p + HDRSIZE;
    void my_free (void *p)
        if (p != NULL)
            free ((unsigned char *) p - HDRSIZE);

[I eventually decided <stddef.h> is the right place for this.]

Add a new macro to <stddef.h>:


    which expands to an integer constant expression that has type /size_t/,
    the value of which is the least common multiple of the alignments of
    all object types.[*]

    [*] If /p/ has pointer to character type and is suitably aligned for
    some type /t/, then /(p + _ALIGNMENT_ALL)/ is also suitably aligned
    for the same type /t/, no matter what /t/ is.

[Item 31, based on PC-UK0169]

Category: Feature that should be included
Committee Draft subsection: 7.17

Title: relax restrictions on the offsetof macro

Detailed description:

The offsetof macro currently requires its first argument to be a structure
type, and is unclear what the second argument is. There is no particular
reason to forbid unions for the first argument, nor to forbid complex
constructs for the second argument, provided only that the address constant
requirement continues to hold.

In 7.17p3, change "structure" to "structure or union" in two places,
and change:

    The /member-designator/ shall be such that given


    The /member-designator/ may be any construct, provided that given

and add a footnote to the end of the paragraph:

    [*] Thus the member-designator may be a construct like /m [2]/ or
    /a.b.c/. The offset of any member of a union is 0.

[Item 32, based on PC-UK0057]

Category: Normative change to intent of existing feature
Committee Draft subsection: 7.19.2,, 7.24.6

Title: Better locale handling for wide oriented streams

Detailed description:

7.19.2p6 associates an /mbstate_t/ object with each stream, and 7.19.3p11-13
state that this is used with the various I/O functions. On the other hand,
7.24.6p3 places very strict restrictions on the use of such objects,
restrictions that cannot be met through the functions provided in the
Standard while allowing convenient use of wide formatted I/O.

Furthermore, an /mbstate_t/ object is tied to a single locale based on the
first time it is used. This means that a wide oriented stream is tied to
the locale in use the first time it is read or written. This will be
surprising to many users of the Standard.

Therefore, at the very least these objects should be exempt from the
restrictions of 7.24.6; the restrictions of 7.19 (for example, 7.19.2p5
bullet 2) are sufficient to prevent unreasonable behaviour. In addition,
the locale of the object should be tied and not affected by the current
locale. The most sensible way to do this is to use the locale in effect
when the file is opened, but allow /fwide/ to override this.

In 7.19.2p6, add after the first sentence:

    This object is not subject to the restrictions on direction of use
    and of locale that are given in subclause 7.24.6. All conversions
    using this object shall take place as if the /LC_CTYPE/ category
    setting of the current locale is the setting that was in effect when
    the orientation of the stream was set with the /fwide/ function or,
    if this has not been used, when the stream was opened with the
    /fopen/ or /freopen/ function.

In, add a new paragraph after paragraph 2:

    If the stream is successfully made wide oriented, the /LC_CTYPE/
    category that is used with the /mbstate_t/ object associated with
    the stream shall be set to that of the current locale.

In 7.24.6p3, append:

    These restrictions do not apply to the /mbstate_t/ objects associated
    with streams.

[Item 33, based on PC-UK0058]

Category: Request for information/clarification
Committee Draft subsection:

Title: Unclear how many times tmpfile() can be called.

Detailed description:

Nowhere does the Standard state how many times tmpfile() can be called, nor
does it state that several successful calls will actually access different
files !

Append to

    The file will be different from any other existing file, including any
    opened by a previous successful call to the /tmpfile/ function.

Add a new part to

    Recommended practice

    It should be possible to open at least /TMP_MAX/ temporary files
    during the lifetime of the program, and no limit on the number
    simultaneously open other than this limit and any limit on the
    number of open streams (FOPEN_MAX). The limit of /TMP_MAX/ could be
    shared with calls to /tmpnam/.

[Item 34, based on PC-UK0064]

Category: Request for information/clarification
Committee Draft subsection:,

Title: Clarify the actions of fread and fwrite

Detailed description:

The exact behaviour of fread and fwrite are not well specified, particularly
on text streams but in actuality even on binary streams. These changes
apply the obvious semantics.

In, add after the first sentence:

    For each object, /size/ calls are made to the /fgetc/ function and
    the results stored, in the order read, in an array of /unsigned char/
    exactly overlaying the object.

In, add after the first sentence:

    For each object, /size/ calls are made to the /fputc/ function, taking
    the values (in order) from an array of /unsigned char/ exactly
    overlaying the object.

[Item 35, based on PC-UK0063]

Category: Feature that should be included
Committee Draft subsection: 7.19.9

Title: Provide a way to compare fpos_t values.

Detailed description:

There is no way to determine whether two fpos_t values represent the same
position in a file. Therefore, it is not possible to do operations such as
the following:

- open a file
- move through it, looking for some mark
- note the position using fgetpos()
- rewind
- move through it again to the same position, using calls to fgetpos()
  to determine where you are, rather than relying on having made exactly
  the same sequence of reads and seeks

Add a new function to 7.19.9: The fcmppos function


        #include <stdio.h>
        struct fcmppos fcmppos (fpos_t* pos1, fpos_t* pos2, FILE *stream)


    The /fcmppos/ function compares the values pointed to by /pos1/ and
    /pos2/, which must both refer to the stream /stream/. If either of the
    first two arguments is a null pointer, the result of a call to the
    /fgetpos/ function on the stream is used instead. If the stream has
    been written to at any point before the later of the two positions,
    the behaviour is undefined.


    The value returned is a structured type containing at least the
    following fields:

        int before;   // Less than, equal to, or greater than zero according
                      // to whether /*pos1/ is before, at the same location
                      // as, or after /*pos2/ in the file.
        int mbstate;  // Zero if and only if the two positions have the same
                      // multibyte parsing status.

It will also be necessary to add /struct fcmppos/ to the start of 7.19.

[Item 36, based on PC-UK0061]

Category: Normative change to intent of existing feature
Committee Draft subsection:

Title: Explicitly allow assert on non-Boolean arguments

Detailed description:

DR 107 asked questions about the assert macro (it was written when the
parameter type was given as int). Part c asked:

    Must a conforming implementation convert the value yielded by the
    expression given in an invocation of the assert macro to type int
    before checking to see if it compares equal to zero?

and the answer given was "no". Other parts of the response stated:

    Passing a non-int argument in such a context will render the
    translation unit not strictly conforming.


    a violation of this requirement results in undefined behavior

It is clear from these, as well as from a reasoned consideration of 6.10,
that the argument to the assert macro is *not* converted to the required
type, but must already have that type. This means that expressions such

    assert (n > 0)        // new problem in CD2 - int is not _Boolean
    assert (p != NULL)    // new problem in CD2 - int is not _Boolean
    assert (1U)           // problem in C89 - unsigned int is not int
    assert (2.5)          // problem in C89 - double is not int

all produce undefined behavior. The change made between CD1 and CD2 has
only exacerbated this, requiring explicit casts of comparisons:

    assert ((_Bool) (n != 0))

The wording changes required to fix this are simple and do not affect the
spirit of assert. The implementation is also trivial - the definition of
the assert macro might need to have "expression" changed to either
"!!(expression)" or "(expression) != 0" where it is tested, though it is
possible that the existing definition might already be valid.

In, change "_Bool expression" to "scalar expression", where the
word "scalar" is in italics. Add to paragraph 2, either after the first
sentence or at the end:

    The argument of the /assert/ macro may be any expression with scalar

[Item 37, based on PC-UK0067]

Category: Other: tidy up (technically normative)
Committee Draft subsection: 7.20

Title: tidy up definitions of <stdlib.h> macros

Detailed description:

In 7.20p3, change:


    which expand to integer expressions which ...



    which expand to integer constant expressions which ...

and change:


    which expands to a positive integer expression whose value
    ... never greater than /MB_LEN_MAX/.



    which expands to a positive integer expression whose type is /size_t/
    and whose value ... never greater than /MB_LEN_MAX/. This is not a
    constant expression: it may change whenever the locale changes.

[Item 38, based on PC-UK0070]

Category: Feature that should be included
Committee Draft subsection: 7.22

Title: Type-generic macros should be generally useful

Detailed description:

7.9 introduces the concept of type-generic macros, but these are only
available for a small range of mathematical functions. This facility should
be made generally available so that they can be used for general

[Item 39]

Category: Various (some normative)
Committee Draft subsection: 7.23

Title: various changes to <time.h>

Detailed description:

The following items constitute a number of changes to 7.23 <time.h>. Some
are editorial and some are normative. They are all included in one place
for convenience, though each item stands alone.

Sub-item 1 (editorial):

In 7.23.1p5, "tm_extlen object" should read "tm_extlen member".

Sub-item 2 (editorial):

In the list should be closed up and indented, in the same style
as the lists in 7.23.1p4 and p5.

Sub-item 3 (normative):

There is an error in the algorithmin The first line of the
expression for D should read:

    D = Y*365 + DIV(Z,400)*97 + MOD(Z,400)/4 - MOD(Z,400)/100 +

Sub-item 4 (editorial):

In footnote 252 "401 B.C.E." should read "401 B.C.".

Sub-item 5 (editorial):

In, item %C, delete the "(00-99)" that seems to have appeared
since CD1 (the year is not limited to 0 to 9999).

Sub-item 6 (normative):

It would be convenient to provide a way to produce the output generated in
the "C" locale even when in another locale (for example to produce mixed
format output). This could reasonably be done by a "C" modifier (there is
no case where it makes sense to have this combined with the "E" or "O"

In add "C" to the list of modifiers, and add a new paragraph
before p4:

    The C modifier indicates that the replacement text shall be that
    produced in the "C" locale, irrespective of the current locale.

Sub-item 7 (normative):

The "E" and "O" modifiers could be made more general while, at the same
time, making their meanings clearer. The following wording replaces completely, though in principle one changed modifier could be
adopted without the other. If this change is not made, it should be noted
that "%OW" has been incorrectly written as "%Ou".

[E modifier]
    The E modifier indicates that a locale-specific alternate calendar
    shall be used. All specifiers whose replacement depends on the date
    shall use the alternate calendar, and the replacement text shall depend
    on all the members tm_year, tm_mon, and tm_mday as well as any listed
    for the specifier. If there is no such alternate system, the modifier
    is ignored.

    If the alternate system makes use of base years (also known as eras)
    and offsets from the base, then the following specifiers have different
        %EC is replaced by the name of the base year or era.
        %Ey is replaced by the offset from %EC (year only).
        %EY is replaced by the locale's full alternative year
            representation including both era and offset.

[O modifier]
    The O modifier indicates that a locale-specific set of alternative
    numeric symbols are to be used instead of decimal digits in the text
    replacing the conversion specifier. If there are no alternative
    numeric symbols, the modifier is ignored.

[Item 40, based on PC-UK0031]

Category: Normative change to existing feature retaining the original
Committee Draft subsection:

Title: make ispunct() true for basic punctuation characters

Detailed description:

In C89, including after the addition of NA1, the definition of ispunct()

    The ispunct function tests for any printing character that is
    neither space (' ') nor a character for which isalnum is true.

At sometime during the revision process this definition has been changed;
this is a Quiet Change with no obvious rationale. It also makes it
impossible to predict what will happen in the "C" locale.

Preferably this wording should be restored. Alternatively, wording should
be adopted that at least returns true for the required 29 punctuation
characters in the "C" locale. The following change uses wording analogous
to that in other <ctype.h> functions and has the benefit that it clearly
defines the results in the "C" locale without leaving them up to the

Replace by:

    The /ispunct/ function tests for any character that is one of the
    29 graphic characters in the basic execution character set or is
    one of a locale-specific set of printing characters for which neither
    /isspace/ nor /isalnum/ is true. In the "C" locale it returns true
    only for the characters in the basic execution character set.

[Item 41]

Category: Editorial
Committee Draft subsection: D.1

Title: Minor edit to clarify interpretation

Detailed description:

In D.1p2, change "to follow" to "to follow exactly". The point is not that
the annex is normative, but that it is to be applied "as is" rather than to
the exact letter.

[Item 42]

Category: Inconsistency
Committee Draft subsection: D.5

Title: Minor correction to an example in Annex D

Detailed description:

Replace D.5p9 with:

    Clearly there is no undefined behavior.

[The existing text is clearly wrong.]

[Item 43, based on PC-UK0066]

Category: Inconsistency
Committee Draft subsection: various

Title: The term "access" is not well defined.

Detailed description:

The term "access" is not well defined. From context, it is most often used
to mean "read or write the value" but sometimes to mean "read the value".
This ambiguity sometimes makes it hard to understand what is actually meant.
It appears that some work on this has been done since CD1, and
makes it clear that "read or write" should be the meaning. However, this
does not obviously apply to the whole document; it ought to be made clear
and the remaining "read the value" uses changed.

Add a new subclause to clause 3:

    (in the context of execution-time actions) to read or modify the
    value of an object; expressions that are not evaluated do not access

    NOTE 1  Where only one of these two actions is meant, the term "read"
    or "modify" is used.

    NOTE 2  The term "modify" includes the case where the new value of the
    object is the same as the previous value.

Delete the following words from

    An access to a value means either fetching it or modifying it;
    expressions that are not evaluated do not access values.

The following uses of "access" or its inflections need to be changed:   ("accessed"  -> "read")
    6.5p2       ("accessed"  -> "read")
    Footnote 68 ("accessing" -> "reading")  ("accessed"  -> "read")
and the corresponding bullets in annex K.