C99 (superseded): issue log

Issue 0201: Integer types longer than long

Authors: Clive Feather (UK)
Date: 1999-07-06
Reference document: ISO/IEC WG14 N883
Status: Closed
Converted from: summary-c99.htm, dr_201.htm

Summary

Require that size_t be no wider than unsigned long and ptrdiff_t be no wider than signed long.

Urgency
If this change is not made now, there will be a window of opportunity - of at least two years - when implementations can make size_t be wider than unsigned long. By the time any future Amendment is ready it will be impractical to re-impose the restriction. If the change is made now, it can always be relaxed if it becomes necessary.

Rationale
Various types in the Standard are defined as integer types. Two of these size_t and ptrdiff_t - are frequently manipulated and on many implementations need to hold values of the same order as [un]signed long. In C89 there are various programming idioms that involve these types but also need a standard integer type. For example:

printf ("%lu", (unsigned long) sizeof X);

or:

int *P1, *P2;
... /* make P1 and P2 point into the same array*/
malloc (sizeof (int) * labs (P1 - P2));

If these types are allowed to become wider than long, these idioms will stop working. More importantly, this might not happen when the code is compiled but rather when large values first get used by a previously working program. This is clearly a Quiet Change.

There do not appear to be any implementations which would be affected by this proposal, and it eliminates the vast majority of potential problems with these two types. While there are other types that theoretically meet these criteria, such as sig_atomic_t, in practice they are unlikely to be larger than long and no action is needed. There are also types in POSIX and other standards, such as off_t, which are similarly affected, but they are outside the scope of C9X; the recommended practice section would assist them.

Suggested Technical Corrigendum

Append a new paragraph to 7.18.3:

The value of SIZE_MAX shall be no greater than that of ULONG_MAX. The absolute values of PTRDIFF_MIN and PTRDIFF_MAX shall be no greater than those of LONG_MIN andLONG_MAX respectively.

or change the first part of 7.17 paragraph 2 to:

[#2] The types are ptrdiff_t which is the signed integer type of the result of subtracting two pointers (the width of ptrdiff_t shall be no greater than that of signed long);

size_t

which is the unsigned integer type of the result of the sizeof operator (the width of size_t shall be no greater than that of unsigned long); or both (the changes are equivalent in effect).

Possibly also add the following paragraph somewhere (perhaps in 6.3.1.3):

Recommended practice

Implementations should provide a mode which will warn of conversions (including those involving an explicit cast) where:

• the original value was taken from an object whose type is derived from a typedef defined in a header provided by the implementation;
• that type has a conversion rank greater than that of signed long;
• the result type has a conversion rank equal to that of signed long.

(Headers provided by the implementation are not limited to those defined by this Standard, but explicitly excludes <stdint.h>.)

Comment from WG14 on 2007-09-06:

Committee Response

There is no consensus to make this change or any change along this line.

Issue 0202: Change return type of certain <fenv.h> functions

Authors: Clive Feather (UK)
Date: 1999-07-06
Reference document: ISO/IEC WG14 N883
Status: Fixed
Fixed in: C99 TC1
Converted from: summary-c99.htm, dr_202.htm

Summary

Change the return type of various functions in 7.6.2 from void to int so that they can fail.

Urgency
These functions are new in C99. Once the function prototypes have been published it will not be practical to change them. The only solution will be to produce new parallel functions with a return value; because of the way these functions are defined, this will involve significantly more change than just that.

Rationale
The functions in question are to do with the floating-point exception and environment flags. The former will do as an example.

The wording of the FDIS assumes that either:

• the implementation has full control over the flags, or
• the implementation has no control over the flags.

In the first case it defines various FE_ macros such as FE_DIVBYZERO for the flags. The Standard then assumes that it is always possible to set or clear the flag or to raise the exception. In the second case the macros are not defined and so there are no valid argument values for the functions (other than zero).

However, there are implementations that can do some things with the flags but not others. For example, it may be possible to raise exceptions but not to clear flags. This case is not allowed in the present draft.

The two alternative proposed changes are:

1. Change the return types of the functions to int. For now the functions always return zero (success) but a later Amendment can alter this. This is the minimum to "future-proof".
2. Change the definitions properly to allow them to fail. This is more complex but solves the problem once and for all.

Option 2 contains an extra item to makefesetround more consistent with the other changes. This change may be omitted if it will increase consensus.

Proposed solutions
Option A - placeholder change

For each of the following functions:

feclearexcept
fegetexceptflag
feraiseexcept
fesetexceptflag
fegetenv
fesetenv
feupdateenv

change the return type to int and add the following:

Returns

This function always returns zero. [*]

[*] This may change in a future revision of this Standard, in which case a zero return will mean success and a non-zero return will mean failure of some kind.

Add to the Future Directions clause:

The fact that various functions in 7.6.2 and 7.6.4 always return zero is an obsolescent feature.

Option B - full change

In 7.6 paragraph 5, attach a footnote to the wording:

if and only if the implementation supports the floating-point exception by means of the functions in 7.6.2.

where the footnote is:

[*] The implementation supports an exception if there are circumstances where a call to at least one of the functions in 7.6.2, using the macro as the appropriate argument, will succeed. It is not necessary for all the functions to succeed all the time.

For each of the following functions:

feclearexcept
fegetexceptflag
feraiseexcept
fesetexceptflag
fegetenv
fesetenv
feupdateenv

make changes equivalent to the following (which shows the wording changes for 7.6.2.1).

In paragraph 2, replace "clears" with "attempt to clear".

Add a new heading and paragraph 3:

Returns

[3] The feclearexcept function returns zero if the excepts argument is zero or if all the specified exceptions were successfully cleared. Otherwise it returns a nonzero value.

Optional additional change: replace 7.6.3.2p3 by:

[3] The fesetround function returns zero if and only if the requested rounding direction was established.

Comment from WG14 on 2001-01-22:

Technical Corrigendum

In 7.6 paragraph 5, attach a footnote to the wording:

if and only if the implementation supports the floating-point exception by means of the functions in 7.6.2.

where the footnote is:

[*] The implementation supports an exception if there are circumstances where a call to at least one of the functions in 7.6.2, using the macro as the appropriate argument, will succeed. It is not necessary for all the functions to succeed all the time.

In 7.6.2.1 paragraph 1, change the result type from void to int.

In 7.6.2.1 paragraph 2, replace "clears" with "attempts to clear".

In 7.6.2.1 add a new heading and paragraph 3:

Returns

[#3] The feclearexcept function returns zero if the excepts argument is zero or if all the specified exceptions were successfully cleared. Otherwise it returns a nonzero value.

In 7.6.2.2 paragraph 1, change the result type from void to int.

In 7.6.2.2 paragraph 2, replace "stores" with "attempts to store".

In 7.6.2.2 add a new heading and paragraph 3:

Returns

[#3] The fegetexceptflag function returns zero if the representation was successfully stored. Otherwise it returns a nonzero value.

In 7.6.2.3 paragraph 1, change the result type from void to int.

In 7.6.2.3 paragraph 2, replace "raises" with "attempts to raise".

In 7.6.2.3 add a new heading and paragraph 3:

Returns

[#3] The feraiseexcept function returns zero if the excepts argument is zero or if all the specified exceptions were successfully raised. Otherwise it returns a nonzero value.

In 7.6.2.4 paragraph 1, change the result type from void to int.

In 7.6.2.4 paragraph 2, replace "sets" with "attempts to set".

In 7.6.2.4 add a new heading and paragraph 3:

Returns

[#3] The fesetexceptflag function returns zero if the excepts argument is zero or if all the specified flags were successfully set to the appropriate state. Otherwise it returns a nonzero value.

In 7.6.3.2 replace paragraph 3 by:

[#3] The fesetround function returns zero if and only if the requested rounding direction was established.

In 7.6.4.1 paragraph 1, change the result type from void to int.

In 7.6.4.1 paragraph 2, replace "stores" with "attempts to store".

In 7.6.4.1 add a new heading and paragraph 3:

Returns

[#3] The fegetenv function returns zero if representation was successfully stored. Otherwise it returns a nonzero value.

In 7.6.4.3 paragraph 1, change the result type from void to int.

In 7.6.4.3 paragraph 2, replace "establishes" with "attempts to establish".

In 7.6.4.3 add a new heading and paragraph 3:

Returns

[#3] The fesetenv function returns zero if the environment was successfully established. Otherwise it returns a nonzero value.

In 7.6.4.4 paragraph 1, change the result type from void to int.

In 7.6.4.4 paragraph 2, replace "saves" with "attempts to save", replace "installs" by "install", and replace "raises" by "raise".

In 7.6.4.4 add a new heading and paragraph 3:

Returns

[#3] The feupdateenv function returns zero if all the actions were successfully carried out. Otherwise it returns a nonzero value.

In 7.6.4.4 change to existing paragraph 3, also renumbering it as 4:

[#3] EXAMPLE Hide spurious underflow floating-point exceptions:

       #include <fenv.h>
         double f(double x)
         {
             #pragma STDC FENV_ACCESS ON
             double result;
             fenv_t save_env;
             if (feholdexcept(&save_env))
                 return /* indication of an environmental problem*/;
             // compute result           if (/* test spurious underflow*/)
                 if (feclearexcept(FE_UNDERFLOW))
                     return /* indication of an environmental problem */;
             if (feupdateenv(&save_env))
                 return /* indication of an environmental problem*/;
             return result;
         }

In Annex B change the return types for the following to int.

feclearexcept
fegetexceptflag
feraiseexcept
fesetexceptflag
fegetenv
fesetenv
feupdateenv

Issue 0203: C locale conflict with ISO/IEC 9945-2

Authors: WG15, Project Editor (Larry Jones)
Date: 1999-08-18
Reference document: ISO/IEC WG14 N888
Status: Fixed
Fixed in: C99
Converted from: summary-c99.htm, dr_203.htm

Summary

In subclause 7.23.3.5p7, the specifications for the strftime %c, %p, and%x conversion specifiers in the C locale conflict with the specifications in ISO/IEC 9945-2 for the POSIX locale.  As the POSIX and C locales have always been intended to be compatible, we strongly suggest changing these specifications to match the pre-existing POSIX specifications.

Suggested Correction

In subclause 7.23.3.5, paragraph 7, page 345, change the definitions of %c, %p, and %x to:

%c

equivalent to "%a %b %e %T %Y".

%p

one of "AM" or "PM".

%x

equivalent to "%m/%d/%y".

Comment from WG14 on 2000-04-18:

Committee Response

Changes were incorporated into the Standard just before printing. This was considered an editorial change by the Committee.

Issue 0204: size_t and ptrdiff_t as a long long type

Authors: Canada C Working Group, Raymond Mak (Canada C Working Group)
Date: 1999-09-15
Reference document: ISO/IEC WG14 N893
Status: Fixed
Fixed in: C99 TC1
Converted from: summary-c99.htm, dr_204.htm

Summary

size_t and ptrdiff_t can now be a long long type, which is not necessary for hardwares that do not support 64-bit addressing. Implementors should be encouraged to choose a type for these two that minimizes compatibility problems to existing (32-bit) code.

Suggested Correction

In 7.17 at the end of p2, add the following:

Recommended Practice

The long long type should be used only if no other integer types can represent the value range required by the implementation.

Comment from WG14 on 2000-11-02:

Technical Corrigendum

Add to the end of 7.17:

Recommended Practice

[#4] The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long unless the implementation supports objects large enough to make this necessary.

Issue 0205: New keyword __at_least

Authors: Canada C Working Group, Raymond Mak (Canada C Working Group)
Date: 1999-09-15
Reference document: ISO/IEC WG14 N893
Status: Closed
Converted from: summary-c99.htm, dr_205.htm

Summary

6.7.5 introduces a new use of the static keyword. A new keyword should be used instead.

This use of static can only occur in function parameter declaration. If we examine the syntax carefully, static assignment-expression taken together inside [ and ] really plays the role of a type qualifier qualifying a pointer. This means the assignment-expression should only be allowed to follow immediately after the keyword static (when static is present), with no other type qualifiers allowed in between. Also, a new keyword should be used to make the meaning clear.

Suggested Correction

Use a new keyword, __at_least, in place of static.

Change 6.4.1p1 to add a new keyword: __at_least

Change the syntax under 6.7.5 to (the two occurrences of static to __at_least):

direct_declarator :
identifier
( declarator )
direct-declarator [ type-qualifier-list_opt assignment-expression_opt ]
direct-declarator [ __at_least assignment-expression type-qualifier-list_opt ]
direct-declarator [ type-qualifier-list_opt __at_least assignment-expression ]
... (the rest is the same as in the FDIS) ...

Change 6.7.5.2p1 to (i.e. the two occurrences of static to __at_least):

[#1] In addition to optional type qualifiers and the keyword __at_least, the [ and ] may delimit an expression or *. If they delimit an expression (which specifies the size of an array), the expression shall have an integer type. If the expression is a constant expression, it shall have a value greater than zero. The element type shall not be an incomplete or function type. The optional type qualifiers and the keyword __at_least shall appear only in a declaration of a function parameter with an array type, and then only in the outermost array type derivation.

Change 6.7.5.2p3 to (i.e. the three occurrences of static to __at_least, and bind __at_least with assignment-expr in the syntax):

D[ type-qualifier-list_opt assignment-expr_opt ]
D[ __at_least assignment-expr type-qualifier-list_opt ]
D[ type-qualifier-list __at_least assignment-expr ]
D[ type-qualifier-list_opt * ]

and the type specified for ident in the declaration "T D" is "derived-declarator-type-list T", then the type specified for ident is "derived-declarator-type-list array of T".¹²¹⁾ (See 6.7.5.3 for the meaning of the optional type qualifiers and the keyword __at_least.)

Change 6.7.5.3p7 to (i.e. static to __at_least):

[#7] A declaration of a parameter as "array of type" shall be adjusted to "qualified pointer to type", where the type qualifiers (if any) are those specified within the [ and ] of the array type derivation. If the keyword __at_least ...

Change 6.7.5.3p21 to (i.e. static to __at_least):

[#21] EXAMPLE 5 The following are all compatible function prototype declarators.

       double maximum(int n, int m, double a[n][m]);
        double maximum(int n, int m, double a[*][*]);
        double maximum(int n, int m, double a[ ][*]);
        double maximum(int n, int m, double a[ ][m]);

as are:

       void f(double (* restrict a)[5]);
        void f(double a[restrict][5]);
        void f(double a[restrict 3][5]);
        void f(double a[restrict __at_least 3][5]);
        ...

Change A.1.2 to add keyword:

__at_least

Explanation of the change
The new syntax groups '__at_least assignment-expression' together. For example:

double a[restrict __at_least 3] /* ok */
double a[__at_least 3 restrict] /* ok */
double a[__at_least restrict 3] /*not ok */

Conceptually, '__at_least assignment-expression' is a type qualifier. Even though we do not treat it as such in C9X, the potential is there for future enhancement of the language. Therefore we should not interfere with possible future changes in this respect. The following example illustrates the point.

In a function parameter declaration, a parameter of "array of type" is adjusted to "qualified pointer to type". The type-qualifiers inside [ and ] become the qualifier for the pointer. If '__at_leastassignment-expression' is also a type qualifier, this adjustment enables us to write:

int * __at_least(10) p;

which declares a pointer pointing to the first of a sequence of 10 integers in memory. (The parentheses are used for clarity.) The clumsy description in 6.7.5.3p7 become unnecessary. Note that the current static syntax prevents us from writing the equivalent pointer declaration for an array parameter declaration.

This example is presented here only as an illustration of what is possible in the future; it is not meant as a suggested change for this DR. Nevertheless, it does show that allowing other qualifiers appearing between static and the assignment-expression is a conceptual error.

Comment from WG14 on 2001-09-18:

Committee Discussion

The committee has had several viewpoints on this controversial item. These are ranked with the choice getting the most support first, the last entry getting little or no support.

1. Do nothing.

2. Remove this feature (the use of static to mean a minimum array size).

3. Deprecate this feature (the use of static to mean a minimum array size).

4. In 6.7.5 Declarators (p. 114) and its subclauses, deprecate:

   direct-declarator [ static type-qualifier-list_opt assignment-expression ]

   and change:

   direct-declarator [ type-qualifier-list static assignment-expression ]

   to:

   direct-declarator [ type-qualifier-list_opt static assignment-expression ]

5. Accept the suggestions of this DR.

Note:

There was a unanimous vote that the feature is ugly, and a good consensus that its incorporation into the standard at the 11^th hour was an unfortunate decision.

Comment from WG14 on 2001-09-18:

Committee Response

There is no consensus to make this change or any change along this line.

Issue 0206: Default argument conversion of float _Complex

Authors: Clive Feather (UK)
Date: 1999-09-13
Reference document: ISO/IEC WG14 N892
Status: Closed
Converted from: summary-c99.htm, dr_206.htm

Summary

For consistency with real floating types, the type float _Complex should be promoted by the default argument promotions to double _Complex.

Suggested Technical Corrigendum

Change 6.5.2.2p6 in part, from:

and arguments that have type float are promoted to double.

to:

and arguments that have a corresponding real type of float are promoted, without change of type domain, to a type whose corresponding real type is double.

Comment from WG14 on 2001-09-18:

Committee Response

This was intentional because real float promotion to double is in Standard C purely for compatibility with K&R. Since complex is new, that compatibility is not an issue, and having it behave like real float would introduce undesired overhead (and be less like Fortran).

The following words were added the Rationale.

float _Complex is a new type with C99. It has no need to preserve promotions needed by pre-ANSI-C. It does not break existing code.

Issue 0207: Handling of imaginary types

Authors: Clive Feather (UK)
Date: 1999-06-27
Reference document: ISO/IEC WG14 N892
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_207.htm

Summary

The handling of imaginary types in the Standard is somewhat inconsistent. For example, they are not mentioned at all in 6.2.5 (other than a footnote), but are treated as first-class types in 6.7.2. Annex G makes certain assumptions about such types but these assumptions are not supported by the Standard.

Details

There are two reasonable approaches that could be followed. The first is to remove all mention of imaginary types from the main text of the Standard and put them all in Annex G. The second is to make the basic properties of imaginary types part of the main language (while still making them optional), leaving Annex G to handle the details of ISO 60559 imaginary types.

After some thought, the author of this DR feels that imaginary types are experimental enough that the first approach is better and has worded the Suggested Technical Corrigendum on that basis.

The keyword _Imaginary is mentioned in 6.4.1, 6.7.2, and 7.3.1. These references - and any related text - are all to be removed and replacement wording added to Annex G.

A new subclause G.4.4 is added. This specifies the practical implications of giving imaginary types the same representation and alignment as real floating types.

Suggested Technical Corrigendum

Delete "_Imaginary" from the list of keywords in 6.4.1. If this is felt to be too radical, instead add the following text to paragraph 2:

The keyword _Imaginary is not used in the C language, but is reserved for specifying imaginary types such as described in Annex G.

Delete "_Imaginary" from 6.7.2p1 and the three imaginary cases from 6.7.2p2.

Change 6.7.2p3 to read:

The type specifier _Complex shall not be used if the implementation does not provide complex types.

Delete 7.3.1p3.

Delete "imaginary" from 7.3.1p5.

Replace 7.3.1p4 with:

The macro I expands to _Complex_I.

Add a new paragraph before G.2p1:

There is a new keyword _Imaginary used to specify imaginary types. It is used as a type-specifier within declaration-specifiers in the same way as _Complex is (thus "_Imaginary float" is a valid type name).

Add a new subclause G.4.4

G.4.4 Interchangeable values

Though imaginary types are not compatible with the corresponding real type, values of one may be used where the other is expected in the following cases. In each case the value is converted to the value of the other type that has the same representation (that is, by multiplying by the imaginary unit when converting to an imaginary type, and by dividing by the imaginary unit when converting to a real type).

• one type is the type of the parameter, and the other type the type of the argument, when a function is called without a prototype in scope; [*]
• one type is the type of an argument corresponding to a trailing ellipsis in a function call and the other is specified as the type argument of an invocation of the va_arg macro;
• one type is the type of an argument to a function such as fprintf or the type pointed to by an argument to a function such as fscanf, and the other is the type implied by the corresponding conversion specifier.

[*] If a prototype is in scope, conversion is as if by assignment and the value will be converted to zero.

Replace G.6p1 with:

The macros

imaginary

and

_Imaginary_I

are defined, respectively, as _Imaginary and a constant expression of type const float _Imaginary with the value of the imaginary unit. The macro I is defined to be _Imaginary_I (not _Complex_I as stated in 7.3). Notwithstanding the provisions of 7.1.3, a program may undefine and then perhaps redefine the macro imaginary.

Afternote
If WG14 wishes to take the alternative approach of moving _Imaginary types more firmly into the body of the Standard, then the following areas would be affected.

• Do not make any of the above changes.
• Add text to 4p6 explaining that imaginary types are never required.
• Merge the text from G.2 into 6.2.5.
• Merge the existing text from G.4 into 6.3.1.
• Make the cases described in the new G.4.4 above further cases of the relevant subclauses (6.5.2.2, 7.15.1.1, 7.19.6.1, 7.19.6.2, 7.24.2.1, and 7.24.2.2).
• Move G.5.1p1 and G.5.2p1 into 6.5.5 and 6.5.6.
• Delete G.6p1.

Comment from WG14 on 2001-09-18:

Technical Corrigendum:

In 6.4.1 append to paragraph 2:

The keyword _Imaginary is reserved for specifying imaginary types.^footnote

^footnoteOne possible specification for imaginary types is Annex G.

In 6.7.2 delete "_Imaginary" from paragraph 1, delete the cases:

• float _Imaginary
• double _Imaginary
• long double _Imaginary

from paragraph 2, and change paragraph 3 to read:

[#3] The type specifier _Complex shall not be used if the implementation does not provide complex types.¹⁰¹

Change footnote 101 to read:

¹⁰¹Freestanding implementations are not required to provide complex types.

In 7.3.1 replace paragraphs 3 to 5 with:

[#3] The macro

I

expands to _Complex_I.¹⁶²

[#4] Notwithstanding the provisions of subclause 7.1.3, a program may undefine and perhaps then redefine the macros complex and I.

Add a new paragraph to the start of G.2:

[#0] There is a new keyword _Imaginary, which is used to specify imaginary types. It is used as a type-specifier within declaration-specifiers in the same way as _Complex is (thus "_Imaginary float" is a valid type name).

Replace G.6 paragraph 1 with:

[#1] The macro

imaginary

and

_Imaginary_I

are defined, respectively, as _Imaginary and a constant expression of type const float _Imaginary with the value of the imaginary unit. The macro

I

is defined to be _Imaginary_I (not _Complex_I as stated in 7.3). Notwithstanding the provisions of 7.1.3, a program may undefine and then perhaps redefine the macro imaginary.

Issue 0208: Ambiguity in initialization

Authors: Clive Feather (UK)
Date: 1999-09-06
Reference document: ISO/IEC WG14 N892
Status: Fixed
Fixed in: C99 TC1
Converted from: summary-c99.htm, dr_208.htm

Summary

When there is more than one initializer for the same object it is not clear whether both initializers are actually evaluated. Wording changes are proposed to clarify this.

Details

Subclause 6.7.8 paragraph 19 reads:

The initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject; all subobjects that are not initialized explicitly shall be initialized implicitly the same as objects that have static storage duration.

Paragraph 23 reads:

The order in which any side effects occur among the initialization list expressions is unspecified.

If the same object is initialized twice, as in:

int a [2] = { f (0), f (1), [0] = f (2) };

the term "overriding" could be taken to mean that the first initializer is ignored completely, or it could be taken to mean that the expression is evaluated and then discarded. The proposed wording change assumes the latter.

Suggested Technical Corrigendum

Replace 6.7.8 paragraph 23 with:

All the initialization list expressions are evaluated, even if the resulting value will be overridden, but the order in which any side effects occur is unspecified.

Comment from WG14 on 2000-11-02:

Committee Response

The question asks about the expression

int a [2] = { f (0), f (1), [0] = f (2) };

and the meaning of the wording

each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject;

It was the intention of WG14 that the call f(0) might, but need not, be made when a is initialized. If the call is made, the order in which f(0) and f(2) occur is unspecified (as is the order in which f(1) occurs relative to both of these). Whether or not the call is made, the result of f(2) is used to initialize a[0].

The wording of paragraph 23:

The order in which any side effects occur among the initialization list expressions is unspecified.

should be taken to only apply to those side effects which actually occur.

Technical Corrigendum

In 6.7.8 paragraph 19, attach a footnote to "the same subobject":

[*] Any initializer for the subobject which is overridden and so not used to initialize that subobject might not be evaluated at all.

Issue 0209: Problem implementing INTN_C macros

Authors: Douglas A. Gwyn (J11)
Date: 1999-10-19
Reference document: ISO/IEC WG14 N896
Status: Fixed
Fixed in: C99 TC1
Converted from: summary-c99.htm, dr_209.htm

Summary

The requirements of subclause 7.18.4.1 may be impossible to satisfy (for N = 8 or 16, typically) unless an implementation has special (non-standard) support for integer constants of types char and short:

The macro INTN_C(value ) shall expand to a signed integer constant with the specified value and type int_leastN_t.

(Similarly for UINTN_C.) The paragraph preceding this overly restrictive specification reflects the actual intent:

... a type with at least the specified width.

Possible Solutions

1. Change "integer constant" to "integer constant expression". While this still does not reflect the original intent, at least it permits accurate implementation without special support from the compiler.
2. Specify that the type shall be the promoted type corresponding to int_leastN_t.
3. Specify that the type shall be any appropriately signed integer type of sufficient width.

Suggested Technical Correction
In subclause 7.18.4.1 paragraph 2, change the two occurrences of "and type" to "and [un]signed integer type at least as wide as".

Comment from WG14 on 2000-11-02:

Technical Corrigendum

7.18.4 Macros for integer constants

[#1] The following function-like macros²²⁰ expand to integer constant expressions suitable for initializing objects that have integer types corresponding to types defined in <stdint.h>. Each macro name corresponds to a similar type name in 7.18.1.2 or 7.18.1.5.

[#2] The argument in any instance of these macros shall be a decimal, octal, or hexadecimal constant (as defined in 6.4.4.1) with a value that does not exceed the limits for the corresponding type.

Add:

[#3] Each invocation of one of these macros shall expand to an integer constant expression suitable for use in #if preprocessing directives. The type of the expression shall have the same type as would an expression that is an object of the corresponding type converted according to the integer promotions. The value of the expression shall be that of the argument.

Most of the following wording is taken almost exactly from <limits.h>

7.18.4.1 Macros for minimum-width integer constants

Remove:

[#1] Each of the following macros expands to an integer constant having the value specified by its argument and a type with at least the specified width.²²¹)

²²¹ For each name described in 7.18.1.2 that the implementation provides, the corresponding macro in this subclause is required.

Change [#2] to:

[#2] The macro INTN_C(value ) shall expand to an integer constant expression corresponding to the type int_leastN_t. The macro UINTN_C(value ) shall expand to an integer constant expression corresponding to the type uint_leastN_t. For example, if uint_least64_t is a name for the type unsigned long long int, then UINT64_C(0x123) might expand to the integer constant 0x123ULL.

7.18.4.2 Macros for greatest-width integer constants

[#1] The following macro expands to an integer constant expression having the value specified by its argument and the type intmax_t:

INTMAX_C(value)

The following macro expands to an integer constant expression having the value specified by its argument and the type uintmax_t:

UINTMAX_C(value)

Issue 0210: fprintf %a and %A conversions recommended practice

Authors: WG 14, Fred Tydeman (US)
Date: 1999-10-20
Status: Fixed
Fixed in: C99 TC1
Converted from: summary-c99.htm, dr_210.htm

Summary

What should fprintf do when it is printing a floating-point number using %a and %A conversions and it is exactly representable in the given precision? That is, what is the result of: fprintf("%a", 1.0);? The current wording appears to say that it be converted into either 0x1.0p0+DBL_EPSILON or 0x1.0p0-DBL_EPSILON/FLT_RADIX, instead of the correct value 0x1.0p0 (this appears to be an oversight that forgot about exactly representable values).

What should the strtod family of functions do when converting a hexadecimal form of input and the result is exactly representable? That is, what is the result of: strtod("0x1.0p0", (char **)NULL);? The current wording appears to say that it be converted into either 1.0+DBL_EPSILON or 1.0-DBL_EPSILON/FLT_RADIX, instead of the correct value 1.0 (this appears to be an oversight that forgot about exactly representable values).

Comment from WG14 on 2001-01-22:

Technical Corrigendum

7.19.6.1 The fprintf function:

Page 279, Paragraph 12 should be changed from:

If FLT_RADIX is not a power of 2, the result should be one of the two adjacent numbers in hexadecimal floating style with the given precision, with the extra stipulation that the error should have a correct sign for the current rounding direction.

to:

For a and A conversions, if FLT_RADIX is not a power of 2 and the result is not exactly representable in the given precision, the result should be one of the two adjacent numbers in hexadecimal floating style with the given precision, with the extra stipulation that the error should have a correct sign for the current rounding direction.

7.20.1.3 The strtod ... functions:

Page 308, paragraph 8 should be changed from:

If the subject sequence has the hexadecimal form and FLT_RADIX is not a power of 2, the result should be one of the two numbers in the appropriate internal format that are adjacent to the hexadecimal floating source value, with the extra stipulation that the error should have a correct sign for the current rounding direction.

to:

If the subject sequence has the hexadecimal form, FLT_RADIX is not a power of 2 and the result is not exactly representable, the result should be one of the two numbers in the appropriate internal format that are adjacent to the hexadecimal floating source value, with the extra stipulation that the error should have a correct sign for the current rounding direction.

7.24.2.1 The fwprintf function:

Page 354, Paragraph 12 should be changed from:

If FLT_RADIX is not a power of 2, the result should be one of the two adjacent numbers in hexadecimal floating style with the given precision, with the extra stipulation that the error should have a correct sign for the current rounding direction.

to:

For a and A conversions, if FLT_RADIX is not a power of 2 and the result is not exactly representable in the given precision, the result should be one of the two adjacent numbers in hexadecimal floating style with the given precision, with the extra stipulation that the error should have a correct sign for the current rounding direction.

7.24.4.1.1 The wcstod ... functions:

Page 372, paragraph 8 should be changed from:

If the subject sequence has the hexadecimal form and FLT_RADIX is not a power of 2, the result should be one of the two numbers in the appropriate internal format that are adjacent to the hexadecimal floating source value, with the extra stipulation that the error should have a correct sign for the current rounding direction.

to:

If the subject sequence has the hexadecimal form, FLT_RADIX is not a power of 2 and the result is not exactly representable, the result should be one of the two numbers in the appropriate internal format that are adjacent to the hexadecimal floating source value, with the extra stipulation that the error should have a correct sign for the current rounding direction.

Issue 0211: Accuracy of decimal string to/from "binary" (non-decimal) floating-point conversions

Authors: NCITS J11, Fred Tydeman (US)
Date: 1999-10-20
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_211.htm

Summary

What is the accuracy of decimal string to/from "binary" (non-decimal) floating-point conversions?

What is the accuracy of hexadecimal string to/from "decimal" (non-power-of-2) floating-point conversions?

In the following, the phrase "decimal to binary" shall cover any pair of bases that are not both a power of the same number. It also shall cover both the string to internal floating-point and internal floating-point to string conversions.

There are two basic cases to consider at run-time:

• decimal string to internal binary (scanf family, strtod family)
• internal binary to decimal string (printf family)

For each of those basic cases, there are two generic sub-cases: base 10 to base 2 and base 2 to base 10.

Background
7.19.6.1 The fprintf function:

Paragraph 8 on "f,F" and "e,E" conversion specifiers says: The value is rounded to the appropriate number of digits.

Does that mean round to nearest, round by truncating, round by add 0.5 and truncate, round as per the current rounding direction, or something else? Must the rounding used for f,F match the rounding used for e,E? Since there is no explicit allowance for multiple values (as there is in 6.4.4.2 Floating constants), must the value produced be as if the infinitely precise value were rounded (and the rounding produce an error less than or equal to 0.5 units in the last place (ulp) for nearest and less than 1.0 ulp otherwise)?

For round to nearest, IEEE-754 (IEC-60559) requires that the maximum error be 0.5 ulp for a large subset of its values and 0.97 ulp for all values. For the other roundings, the maximum error allowed by IEEE-754 is 1.47 ulp. The fourth committee draft (1999-09-30) of ISO/IEC 10967-2 (LIA-2) appears to require the maximum error be in the range 0.5 to 0.75 ulp. These bounds appear to apply to both directions of conversions.

7.19.6.2 The fscanf function:

Paragraph 10 discusses conversion. Paragraph 12 on "a,e,f,g" conversion specifiers discusses format. Neither discuss accuracy of the decimal to binary conversion, e.g., it is not specified.

What is the accuracy of floating-point string to internal representation conversions? Is it the same as translation time? Is it the same as strtod? Is it undefined behavior if the value is not exactly representable? Is it round to nearest? Is it affected by the current rounding mode, e.g., correctly rounded?

7.20.1.3 The strtod ... functions:

What is the required accuracy of strtod family functions? It appears to be either not specified or the same as 6.4.4.2. It appears to depend upon what paragraph 4 "interpreted as a floating constant according to the rules of 6.4.4.2" means.

Suggested Changes

Changes to 7.19.6.1 The fprintf function:

Add near paragraph 11 before Recommended practice:

The roundings used by %f, %F, %e, and %E shall be the same and shall have an accuracy of better than 1 ulp in round to nearest and better than 2 ulp in other roundings.

Changes to 7.19.6.2 The fscanf function:

In paragraph 12, "a,e,f,g" conversion specifier, add the sentence:

The accuracy of this conversion shall be no worse than that of strtold for the same subject.

Change 7.20.1.3 The strtod ... functions:

In paragraph 4, change "rules of 6.4.4.2" to "rules of 6.4.4.2 (including accuracy requirements)"

Add a third recommended practice paragraph:

Conversions done by strtod family functions and fscanf family functions of the same valid floating-point subject string shall produce the same value.

An alternative (not liked by this author) to all of the above is to add to 5.2.4.2.2 Characteristics of floating types <float.h> in paragraph 4 before "and": ", binary-decimal conversions(footnote),".

footnote: binary-decimal covers both string to internal representations and internal to string representations, and covers any pair of bases.

Comment from WG14 on 2001-09-18:

Committee Discussion

5.2.4.2.2 paragraph 4 (which covers the accuracy of +, -, *, /, and math library functions) does not cover decimal <--> binary conversions. Therefore, the rest of 5.2.4.2.2 covers these conversions (F.P. characteristics must meet the minimum-maximum requirements for the <float.h> parameters (even though the exact model need not be followed)). That appears to require that the actual representation be able to express >= FLT/DBL/LDBL_DIG digits precise to the last of those digits (for decimal to binary conversions) and >= DECIMAL_DIG digits (for binary to decimal conversions).

6.3.1.5 para. 1 implies that the different widths of F.P. types must have similar representations differing only in number of bits in exponent, mantissa, and padding.

In 7.19.6.1 f,F format, the value is rounded to the appropriate number of digits, which indicates that the displayed value differs from the "numerical" value only with regard to that rounding. (Of course, all the fprintf conversions of numeric values to display form are on the assumption that what is displayed is the same value as the numeric value, but in human-comprehensible form and subject to specified rounding etc.)

7.20.1.3 says that the numeric string is interpreted as a value according to the rules in 6.4.4.2 for floating constants.

Details of rounding are not specified, although certain modes are described in 5.2.4.2.2.

The latitude allowed for inexactness by the standard applies only to precision of representation and to rounding mode.

Comment from WG14 on 2001-09-18:

Technical Corrigendum

Change 5.2.4.2.2 paragraph #4 to:

The accuracy of the floating-point operations ( +, -, *, /) and of the library functions in <math.h> and <complex.h> that return floating-point results is implementation defined, as is the accuracy of the conversion between floating-point internal representations and string representations performed by the libray routine in <stdio.h>, <stdlib.h> and <wchar.h>. The implementation may state that the accuracy is unknown.

Issue 0212: Binding of multibyte conversion state objects

Authors: Clive Feather (UK)
Date: 1999-10-20
Reference document: ISO/IEC WG14 N898
Status: Closed
Converted from: summary-c99.htm, dr_212.htm

Summary

At present an mbstate_t object can only ever be used to make one conversion. This is not desirable, and changes are proposed in this area.

Discussion
Clause 7.24.6 paragraph 3 reads, in part:

If an mbstate_t object has been altered by any of the functions described in this subclause, and is then used with a different multibyte character sequence, or in the other conversion direction, or with a different LC_CTYPE category setting than on earlier function calls, the behavior is undefined.

Put another way, each mbstate_t object is initially "unbound" (if it is initialized to zero) and then becomes "bound" by any call to a function such as mbrtowc or wcrtomb. When "bound" it can only be used in the same direction with the same string as originally bound, and only when the LC_CTYPE category is that in effect when it was bound. With ordinary mbstate_t objects this is a annoyance; one implication is that a new object must be created every single time a new string is to be converted (the Standard does not provide any way to "unbind" the object). With the mbstate_t object inside a FILE structure it is even worse, because it makes it impossible to (for example) write to a file, rewind it, and then read the same file. Similarly, the internal mbstate_t objects used when the mbstate_t pointer argument is set to NULL can be used for only one string in the entire program !

Users of mbstate_t objects (including those in FILE structures) expect to be able to use them for more than a single purpose.

Proposed solution
The changes introduce the concept that an mbstate_t object is either "unbound" or "bound". When set to an all-zero value (which can be at initialization or explicitly later on) it is unbound. As soon as the object is used for a conversion it becomes bound to that string, locale, and direction. Returning to the initial state does not unbind the object (in other words, while all unbound objects are in the initial state the converse is not necessarily true).

The special cases of mbrtowc and wcrtomb are defined to always result in an unbound state. This both provides more consistent behaviour (the special case resets everything to a known state) and also allows the internal mbstate_t objects associated with these functions to be unbound.

The mbstate_t object hidden in a file is returned to the unbound state whenever end of file is reached on input, and by any call to fseek (these choices were made to correspond with the requirements of 7.19.5.3 paragraph 6 for changing I/O direction).

The internal mbstate_t objects associated with the mbrlen, mbrtowc, wcrtomb, mbsrtowcs, and wcsrtombs functions can only be used with the locale they initially bind to. Other changes deal with the first three; a previously impossible case is used for the last two to force the object to the unbound state.

Suggested Technical Corrigendum

(Changes concerning explicit mbstate_t objects.)
Change 7.24.6 paragraph 3 to:

[#3] The initial conversion state corresponds, for a conversion in either direction, to the beginning of a new multibyte character in the initial shift state. An mbstate_t object may be "unbound" or "bound". A zero-valued mbstate_t object is (at least) one way to describe an unbound object, and if an mbstate_t object is assigned such a value it it becomes unbound. All unbound mbstate_t objects are in the initial conversion state (but the converse is not necessarily true).

[#3a] An unbound object can be used to initiate conversion involving any multibyte character sequence, in any LC_CTYPE category setting, in either direction; once used for a conversion, it becomes bound to that sequence, category setting, and direction. If a bound mbstate_t object is used with a different multibyte character sequence, a different LC_CTYPE category setting, or in the other conversion direction to that it is bound to, the behavior is undefined.²⁹⁰)

Append to footnote 290:

Furthermore, provided that the object is unbound, and thus in the initial conversion state, it can then be used in converting a new string, a new locale, or in the other direction.

Change 7.24.6.3 paragraph 1 and 7.24.6.4 paragraph 1 from:

[...] which is initialized at program startup to the initial conversion state. [...]

to:

[...] which is initialized at program startup to the unbound state. [...]

Change 7.24.6.3.2 paragraph 2 to:

[#2] If s is a null pointer, the mbrtowc function is equivalent to the call:

mbrtowc(NULL, "", 1, ps)

except that the resulting state described is unbound even if an encoding error occurred.

In this case, the values of the parameters pwc and n are ignored.

Change 7.24.6.3.3 paragraph 2 to:

[#2] If s is a null pointer, the wcrtomb function is equivalent to the call

wcrtomb(buf, L'\0',ps)

where buf is an internal buffer except that the resulting state described is always unbound even if an encoding error occurred ^291a; the value of wc is ignored.

291a) The effect is reliably to make *ps unbound.

Append to 7.24.6.4 paragraph 2:

As a special case, if src is a null pointer then the normal behaviour of the function is ignored and instead ps becomes unbound irrespective of its previous state; an unspecified value is returned.

(Changes associated with streams.)
Append to 7.19.2 paragraph 6:

If a wide character input function encounters end-of-file, or after a successful call to the fseek function, thembstate_t object associated with the stream is unbound.

Append to the last sentence of 7.19.9.2 paragraph 5:

and if the stream is wide-oriented the associated mbstate_t object shall be unbound.

In 7.24.3.1 paragraph 2, change: to:

[...] If the stream is at end-of-file, the end-of-file indicator for the stream is set, the mbstate_t object associated with the stream is unbound, and fgetwc returns WEOF. [...]

Comment from WG14 on 2001-09-18:

Committee Response

The consensus is that a programmer can put an mbstate_t object in the initial conversion state for any sequence by the assignment:

static mbstate_t init_state = {0};

...

mbstate_t mystate = init_state;

This technique is used and is believed it to be portable.

There is concern about over specifying the behavior of streams. The Committee believes that to say that the state becomes unbound at EOF, would cause problems with a read/write stream that later gets extended. The Committee could not find a valid reason to hamstring the reader just because it reached an interim EOF. Moreover, is is unlikely one can portably fsetpos() in a wide stream except to the beginning or to a point that was earlier memorized with an fgetpos(). In either case, there is an obvious state to restore. Old fashioned seek()/tell() logic just doesn't full fill the requirements for a wide stream.

The Committee believes that real implementations and real applications do in fact support streams that do not begin in the initial state, as well as streams that do not end in the initial state.

It was also pointed out that even with the suggested text that required a file to begin in the initial shift state, there was no stated requirement that fopen initialize the associated mbstate_t object to have the initial shift state (which again, would break existing implementations that support files that do not begin in the initial shift state).

There is no consensus to make this change or any change along this line.

Issue 0213: Lacuna in mbrtowc

Authors: Clive Feather
Date: 1999-10-20
Reference document: ISO/IEC WG14 N900
Status: Fixed
Fixed in: C99 TC1
Converted from: summary-c99.htm, dr_213.htm

Summary

The description of the result of mbrtowc uses the term "positive" to distinguish one case from others. Unfortunately some of the other cases are also positive, because they are negative numbers cast to the (unsigned) type size_t.

The actual return value in this case is always between 1 and the value of the parameter n (inclusive): positive if the next n or fewer bytes complete a valid multibyte character (which is the value stored); the value returned is the number of bytes that complete the multibyte character.

Comment from WG14 on 2000-11-02:

Technical Corrigendum

In 7.24.6.3.2 paragraph 4, change the label of the case "positive" to "between 1 and n inclusive".

Issue 0214: atexit function registration

Authors: Clive Feather (UK)
Date: 2000-04-04
Status: Closed
Converted from: summary-c99.htm, dr_214.htm

Summary

7.20.4.2 reads:

[#3] The implementation shall support the registration of at least 32 functions.

This does not require registration of a valid function to succeed. The implementation could fail the first 420 times atexit() is called, and then succeed 32 times. It also does not require atexit() to accept any function of the correct type; theoretically an implementation could reject (say) a function in a different translation unit.

Suggested Technical Corrigendum

Change the cited wording to:

[#3] The implementation shall not reject the registration of a valid function if less than 32 functions are already registered (multiple registrations of the same function counting multiple times).

or add the following words:

If less than this number are already registered, a call with a valid argument shall succeed.

Comment from WG14 on 2001-09-18:

Committee Response

There are many conditions under which any library function or language feature may fail or behave in an undefined manner. Some examples:

• All of memory has been allocated
• The stack has overflowed

As such, it is a quality of implementation issue under what conditions any library function, including atexit(), may fail.

There is no consensus to make the suggested change or any change along this line.

Issue 0215: Equality operators

Authors: Clive Feather (UK)
Date: 2000-04-04
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_215.htm

Summary

When discussing the comparison operators, 6.5.8 says:

[#4] For the purposes of these operators, a pointer to an object that is not an element of an array behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type.

Given that the restrictions on the arguments for pointer comparison and pointer equality are very different, it would be advisable to repeat this wording in 6.5.9. The only wording that implies that this applies to equality operators is the bit about "analogous" in 6.5.9#3. Since other restrictions (e.g. that the pointers must be in the same array) do not apply to equality operators, it is at best ambiguous whether this text applies. Therefore for clarity it should be repeated.

Comment from WG14 on 2001-09-18:

Technical Corrigendum

Paragraph 4 from 6.5.8 should be duplicated in the Semantics section of 6.5.9.

Issue 0216: Source character encodings

Authors: Clive Feather (UK)
Date: 2000-04-04
Status: Fixed
Fixed in: C99 TC1
Converted from: summary-c99.htm, dr_216.htm

Summary

The Standard is clear that the basic source character set need not have the same encoding as the basic execution character set, and that while the latter must be all positive, there is no such requirement on the former:

6.2.5:

[#3] [...] If a member of the basic execution character set is stored in a char object, its value is guaranteed to be positive.

6.10.1:

[#3] [...] Whether the numeric value for these character constants matches the value obtained when an identical character constant occurs in an expression (other than within a #if or #elif directive) is implementation-defined.¹⁴¹⁾ Also, whether a single-character character constant may have a negative value is implementation-defined.

However, there are two problems with this. Firstly, the cited wording in 6.2.5 conflicts with the definition of the basic execution character set:

5.2.1:

[#2] [...] A byte with all bits set to 0, called the null character, shall exist in the basic execution character set; it is used to terminate a character string.

in that zero is not positive. Secondly, it is not clear whether a source character constant can have the value zero; in other words, can:

  #if !'A'
    #error Character A is zero
    #endif

reach the #error directive ?

Suggested Technical Corrigendum

Change the cited wording in 6.2.5 to:

#3] [...] If a member of the basic execution character set (other than the null character) is stored in a char object, its value is guaranteed to be positive.

and the last part of the cited wording in 6.10.1 to:

[#3] [...] Also, whether a single-character character constant may have a negative value is implementation-defined (nevertheless, it may not be zero).

Comment from WG14 on 2000-11-02:

Committee Response

Regarding the #error directive, 6.10.1 paragraph 3 states:

The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6, except that all signed integer types and all unsigned integer types act as if they have the same representation as, respectively, the types intmax_t and uintmax_t defined in the header <stdint.h>. This includes interpreting character constants, which may involve converting escape sequences into execution character set members. Whether the numeric value for these character constants matches the value obtained when an identical character constant occurs in an expression (other than within a #if or #elif directive) is implementation-defined.

The evaluation of the controlling constant expression according to the rules of 6.6 implies that character constants are converted into an execution character set (translation phase 5) just as it also implies that preprocessor tokens representing integer constants are translated into integer constants (translation phase 7).

Thus, all character constants operated upon by #if have been translated to some execution character set. The liberty given by 6.10.1 paragraph 3 that allows the value of character constants to differ in preprocessor versus non-preprocessor expressions exists to allow cross-compilers to use a standalone "native" preprocessor that is unaware of the cross-compiled target and its execution character set.

Thus, in your example, the #error directive can never be reached on a conforming implementation.

Technical Corrigendum

Change the cited wording in 6.2.5 to:

[#3] [...] If a member of the basic execution character set is stored in a char object, its value is guaranteed to be non-negative.

Issue 0217: asctime limits

Authors: Clive Feather (UK)
Date: 2000-04-04
Status: Closed
Cross-references: 0326
Converted from: summary-c99.htm, dr_217.htm

Summary

The definition of the asctime function involves a sprintf call writing into a buffer of size 26. This call will have undefined behaviour if the year being represented falls outside the range [-999, 9999]. Since applications may have relied on the size of 26, this should not be corrected by allowing the implementation to generate a longer string. This is a defect because the specification is not self-consistent and does not restrict the domain of the argument.

Suggested Technical Corrigendum

Append to 7.23.3.1[#2]:

except that if the value of timeptr->tm_year is outside the range [-2899, 8099] (and thus the represented year will not fit into four characters) it is replaced by up to 4 implementation-defined characters.

Comment from WG14 on 2001-09-18:

Committee Response

From 7.1.4 paragraph 1:

If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.

Thus, asctime() may exhibit undefined behavior if any of the members of timeptr produce undefined behavior in the sample algorithm (for example, if the timeptr->tm_wday is outside the range 0 to 6 the function may index beyond the end of an array).

As always, the range of undefined behavior permitted includes:

• Corrupting memory
• Aborting the program
• Range checking the argument and returning a failure indicator (e.g., a null pointer)
• Returning truncated results within the traditional 26 byte buffer.

There is no consensus to make the suggested change or any change along this line.

Issue 0218: Signs of non-numeric floating point values

Authors: Clive Feather (UK)
Date: 2000-04-04
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_218.htm

Summary

There is an implication at various points in the standard, notably the copysign function, that infinities and NaNs have signs. This is not the case in all implementations, and this needs to be allowed for.

Suggested Technical Corrigendum

Add a new paragraph to 5.2.4.2.2, preferably after [#3]:

[#3a] An implementation may give zero and non-numeric values (such as infinities and NaNs) a sign or may leave them unsigned. Wherever such values are unsigned, any requirement in this International Standard to retrieve the sign shall act as if the value were positive, and any requirement to set the sign shall be ignored.

or:

[...]
to retrieve the sign shall produce an unspecified sign, and any requirement to set the sign shall be ignored.

Comment from WG14 on 2001-09-18:

Committee Response

In addition to the following Technical Corrigendum, add to the Rationale section that discusses 5.2.4.2.2 of the C Standard:

The committee has been made aware of at least one implementation (VAX and Alpha in VAX mode) whose floating-point format does not support signed zeros. The hardware representation that one thinks would represent -0.0 is in fact treated as a non-numeric value similar to a NaN. Therefore, copysign(+0.0,-1.0) returns +0.0, not the expected -0.0, on this implementation. Some places that mention (or might have) signed zero results and the sign might be different than you expect:

The complex functions, in particular with branch cuts;

ceil()
conj()
copysign()
fmod()
modf()
fprintf() (Footnote 233 is OK)fwprintf() (Footnote 273 is OK)nearbyint()
nextafter()
nexttoward()
remainder() (Footnote 201 does not need to be changed)remquo()
rint()
round()
signbit()
strtod() (Footnote 249 is OK)trunc()
wcstod() (Footnote 285 is OK)

Underflow: In particular: ldexp(), scalbn(), scalbln().

Technical Corrigendum

Add a new paragraph to 5.2.4.2.2, after [#3]:

[#3a] An implementation may give zero and non-numeric values (such as infinities and NaNs) a sign or may leave them unsigned. Wherever such values are unsigned, any requirement in this International Standard to retrieve the sign shall produce an unspecified sign, and any requirement to set the sign shall be ignored.

Issue 0219: Effective types

Authors: Clive Feather (UK)
Date: 2000-04-04
Status: Closed
Converted from: summary-c99.htm, dr_219.htm

Summary

6.5 reads:

[#6] [...] If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access.

Now consider the code extract:

 struct s { char c; int i; long l; double d; } s = { 1, 2, 3, 4 };
     size_t len1 = sizeof (int);
     size_t len2 = offsetof (s, d) - offsetof (s, i));
     void *p1 = malloc (len1); assert (p1);
     void *p2 = malloc (len2); assert (p2);
     memcpy (p1, (char *)&s + offsetof (s, i), len1);
     memcpy (p2, (char *)&s + offsetof (s, i), len2);

What are the effective types of p1 and p2 ? The cited text would imply that they are both struct s, even though this is patently nonsense.

Comment from WG14 on 2006-04-04:

Committee Discussion

Consider:

1. struct s { char c; int i; long l; double d; } s = { 1, 2, 3, 4 };
2. size_t len1 = sizeof (int);
3. size_t len2 = offsetof (s, d) - offsetof (s, i));
4. void *p1 = malloc (len1); assert (p1);
5. void *p2 = malloc (len2); assert (p2);
6. memcpy (p1, (char *)&s + offsetof (s, i), len1);
7. memcpy (p2, (char *)&s + offsetof (s, i), len2);

In lines 6 and 7, the type of the source object in the memcpy is an array of char because the dereference of (char *)&s + ... is a char. This is inferred by:

- "(some_type*)x" has the type "pointer to some_type"
- the dereference of "pointer to some_type" has the type "some_type"

In other words, "(char *)&s + offsetof (s,i)" has type "pointer to char" and its dereference has type "char", i.e., the type of the source object. In the following examples:

8. memcpy (p1, &s.i, len1);
9. memcpy (p1, (char *) &s.i, len1);
10. memcpy (p1, (float *) &s.i, len1);

the source types are, respectively, array of int, char, and float.

In lines 6 and 7, the effective type of the source arguments to memcpy is an array of char, based on the following sentence from 6.5P6:

"For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access."

Based on the following sentence again from 6.5P6:

"If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one."

The object being copied into has no declared type (because it was an allocated object), thus "the effective type of the modified object for that access ... is the effective type of the object from which the value is copied ...". The object from which it was copied is array of char. The effective type for p1 and p2 in lines 6 and 7 is: array of char.

Committee Response

The effective types of *p1 and *p2 are not struct S because not all of the bytes of struct S are copied.

However, the memcpy calls do copy pieces of s. Those pieces contain objects with declared types.

memcpy (p1, (char *)&s + offsetof (s, i), len1); copies all of the bytes of s.i to an alignment suitable for an object of type int. The effective type of the resulting copy can be treated as having effective type int.

memcpy (p2, (char *)&s + offsetof (s, i), len2); copies all of the bytes of s.i and s.l. The memcpy also might copy bytes corresponding to padding before and after s.l.

The int object from s.i is copied to an alignment suitable for an object of type int. The object starting at *p2 extending for sizeof (int) bytes can be treated as having effective type int.

Because of alignment requirements and padding rules that vary from implementation to implementation, the long object from s.l might or might not be copied to an alignment suitable for an object of type long. If it is aligned properly, the object starting at *((char *) p2 + (offsetof (s, l) - offsetof (s, i))) extending for sizeof (long) bytes can be treated as having effective type long.

The objects resulting from the calls to memcpy may also be accessed by other types (primarily given by Subclause 6.5 paragraph 7).

Issue 0220: Definition of "decimal integer"

Authors: Clive Feather (UK)
Date: 2000-04-04
Status: Fixed
Fixed in: C99 TC1
Converted from: summary-c99.htm, dr_220.htm

Summary

7.19.6.1[#4] reads in part:

• An optional minimum field width. [...] The field width takes the form of an asterisk * (described later) or a decimal integer^.232)
• An optional precision [...] The precision takes the form of a period . followed either by an asterisk * (described later) or by an optional decimal integer; [...]

7.19.6.2 #3 reads in part:

• An optional nonzero decimal integer that specifies the maximum field width (in characters).

7.24.2.1 and 7.24.2.2 have essentially the same wording.

The term "decimal integer" is defined neither in the Standard nor in ISO 2382-1. Therefore it is not possible to tell whether, in each case:

• the value may be zero
• a non-significant leading zero digit may be used
• the value may be negative.

Suggested Technical Corrigendum

Add a new paragraph to 7.1.1:

[#x] A decimal integer is a sequence of digits which may begin with one or more zeros, but is nonetheless interpreted as decimal, not octal.

Append to the first cited text in 7.19.6.1:

(A leading zero will be interpreted as a flag, not as part of the width).

Comment from WG14 on 2000-11-02:

Technical Corrigendum

In 7.19.6.1P4, which reads in part:

An optional minimum field width. [...] The field width takes the form of an asterisk * (described later) or a decimal integer.[232] An optional precision [...] The precision takes the form of a period . followed either by an asterisk * (described later) or by an optional decimal integer; [...]

change "decimal integer" to "non-negative decimal integer".

In 7.19.6.2P3, which reads in part:

An optional nonzero decimal integer that specifies the maximum field width (in characters).

change "non-zero decimal integer" to "decimal integer greater than zero".

In 7.24.2.1P4, make similar changes of "decimal integer" to "non-negative decimal integer".

In 7.24.2.2P3, make similar changes of "non-zero decimal integer" to "decimal integer greater than zero".

Issue 0221: Lacuna in pointer arithmetic

Authors: Clive Feather (UK)
Date: 2000-04-04
Status: Closed
Converted from: summary-c99.htm, dr_221.htm

Summary

Consider the code extract:

int v [10]; int *p = (v + 9) + 1; int *q = v + 10;

The relevant part of 6.5.6 paragraph 8 reads:

If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integer expression. In other words, if the expression P points to the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n) point to, respectively, the i+n-th and i-n-th elements of the array object, provided they exist. Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object, the expression (Q)-1 points to the last element of the array object. If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.

There is a problem with this wording in that it defines arithmetic of pointers within the array object properly, but it only defines arithmetic to "one past the end" when the pointer was previously to the last object. In other words, the initialization of p is correct because (v + 9) points to the last element of an array, but the initialization of q is not because the "i+n-th" element does not exist.

This problem also makes common idioms like:

for (p = v; p < v + 10; p++)

undefined.

It is clear that these constructs are supposed to work, and that the relevant wording just needs to be adjusted.

Suggested Technical Corrigendum

Change the cited text to:

If the pointer operand points to an element of an array object or to one past the last element of the array object, and if the array is large enough, the result points to an element, or to the location one past the last element, offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integer expression. In other words, if the expression P points to the i-th element of an array object with k elements, or to one past the last element (in which case i equals k), then the expressions (P)+N and N+(P), (where N has the value n which may be positive, zero, or negative) both point to the i+n-th elements of the array object, provided it exists, or if i+n equals k, to one past the last element of the array object. If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object (that is, both i and i+n lie between 0 and k inclusive), the evaluation shall not produce an overflow; otherwise, the behavior is undefined.

Similarly, change the following text in paragraph 9:

In other words, if the expressions P and Q point to, respectively, the i-th and j- th elements of an array object, the expression (P)-(Q) has the value i-j provided the value fits in an object of type ptrdiff_t. Moreover, if the expression P points either to an element of an array object or one past the last element of an array object, and the expression Q points to the last element of the same array object, the expression ((Q)+1)-(P) has the same value as ((Q)-(P))+1 and as -((P)-((Q)+1)), and has the value zero if the expression P points one past the last element of the array object, even though the expression (Q)+1 does not point to an element of the array object.⁸⁸⁾

to:

In other words, if the expressions P and Q point to, respectively, the i-th and j-th elements of an array object with k elements, or to one past the last element (in which case i or j, or both, equals k), the expression (P)-(Q) has the value i-j provided the value fits in an object of type ptrdiff_t.⁸⁸⁾

Comment from WG14 on 2001-09-18:

Committee Response

1. int v[10];
2. int *p = (v + 9) + 1;
3. int *q = v + 10;

Simply put, 10 == 9+1. Based on the "as-if" rule, there is no semantic distinction among any of the following:

v+9+1
(v+9)+1
v+(9+1)
v+10

and that v+x is equivalent to (v+x-1)+1 and (v+x+1)-1, assuming that x>=1 and x<=9.

Furthermore, the following wording from 6.5.6P8 confirms this equivalence:

"Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object, the expression (Q)-1 points to the last element of the array object."

The first part of the sentence states that (v+9)+1 "points to one past the last element of the array object".

The second part of the sentence states that v+10 "points to one past the last element of the array object", which equates it to (v+9)+1 because it also "points to one past the last element of the array object".

The third part of the sentence states that v+10-1 "points to the last element of the array object" which is v+9.

Additionally, the expression (v+11)-2 need not be valid because constants might not be folded and the expression (v+11) is invalid.

There are no surprising results in any of the above conclusions, even if the above constants are replaced with variables. The committee believes the current specification is clear and is unlikely to be misinterpreted.

There is no consensus to make the requested changes or any changes along these lines.

Issue 0222: Partially initialized structures

Authors: Clive Feather (UK)
Date: 2000-04-04
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_222.htm

Summary

Consider the code extract:

   struct listheader
     {
         struct item *head;
         struct item *tail;
     };
     // The following is at block scope    struct listheader h1;
     h1.head = NULL;
     struct listheader h2;
     h2 = h1;

The value of h1.tail is indeterminate throughout, but provided that the code never accesses it this is not a problem. However, if it holds a trap representation, the assignment to h2 involves assigning a trap representation, which is undefined behaviour.

There are two possible resolutions I can think of:

1. Say that the code is defined. Any implementation that uses memberwise copying of structures now has to explicitly disable detection of trap values.
2. Say that the code is undefined. This is going to surprise a number of people. In particular, it becomes impossible to assign any structure where the complete list of fields is unknown (e.g. any structure defined in a Standard header).

Comment from WG14 on 2001-09-18:

Committee Discussion (for history only)

A TC should remove the notion of objects of struct or union type having a trap representation. Changes need to be made to 6.2.6.1 paragraphs 6 and 7, and footnote 42. It was observed that the point of the original footnote was primarily to illustrate one reason why padding bits might not be copied: because member-by-member assignment might be performed. But member-by-member assignment would imply that struct assignment could produce undefined behavior if a member of the struct had a value that was a trap representation. Instead of adding further text explaining that member values that were trap representations were not permitted to render assignment of a containing struct or union object undefined (e.g. if member-by-member copying were used), it was decided that the footnote should simply clarify the issue of padding bits directly.

Comment from WG14 on 2001-09-18:

Technical Corrigendum

Change 6.2.6.1 paragraph #6 to:

When a value is stored in an object of structure or union type, including in a member object, the bytes of the object representation that correspond to any padding bytes take unspecified value.⁴²⁾ The value of a struct or union object is never a trap representation, even though the value of a member of a struct or union object may be a trap representation.

Change footnote 42 to:

42) Thus, for example, structure assignment need not copy any padding bits.

Change 6.2.6.1 paragraph #7 to:

When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values.

Issue 0223: FP_FAST_FMAF and FP_FAST_FMAL should be integer constant

Authors: Bill Plauger (US)
Date: 2000-04-10
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_223.htm

Summary

In the standard header <math.h>, FP_FAST_FMAF and FP_FAST_FMAL should be required to be integer constant expressions.

Comment from WG14 on 2000-04-18:

Technical Corrigendum

FP_FAST_FMAF and FP_FAST_FMAL should be defined as integer constant 1.

Issue 0224: fpclassify return is not defined

Authors: Bill Plauger (US)
Date: 2000-04-10
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_224.htm

Summary

The standard header <math.h> does not define a use for FP_INFINITE and does not define what the function fpclassify returns.

Comment from WG14 on 2002-03-06:

Committee Discussion

This seems clear from a combination of 7.12.3.1 paragraph 2 and 7.12 paragraph 6.

Don't see what Plauger's comments in regard to FP_INFINITE is, and didn't consider that there is any problem.

Technical Corrigendum

In 7.12 paragraph #6 a new term "number classification macro" should be introduced, and the reword the first sentence to:

The number classification macros are:

FP_INFINITE
FP_NAN
FP_NORMAL
FP_SUBNORMAL
FP_ZERO

Issue 0225: strtod, strtof and strtold expected form of the subject sequence

Authors: Bill Plauger (US)
Date: 2000-04-10
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_225.htm

Summary

In <stdlib.h>, functions strtod, strtof, and strtold should permit an implementation to recognize either inf or infinity, and either nan or nan(n-char-sequence_opt ), not just one of each.

Suggested Technical Corrigendum

In 7.20.1.3 replace:

• one of INF or INFINITY, ignoring case
• one of NAN or NAN(n-char-sequence_opt ), ignoring case in the NAN part, where:

with:

• either INF not followed by I, or INFINITY, ignoring case
• either NAN not followed by a left parenthesis, or NAN(n-char-sequence_opt ), ignoring case in the NAN part, where:

Comment from WG14 on 2001-09-18:

Committee Discussion (for history only)

For the functions strtod, strtof and strtold, should the implementation allow INFI to work as INF and leave the pointer at the next I, or should it reject a sequence such as INFINF as an invalid sequence, that failed at the second F.

The issue concerns what degree of pushback is necessary. But these are string functions, not input functions, so they do not need push back. Furthermore, 7.19.6.2¶9 and the associated footnote, clearly indicates that there is no requirement for the strto* functions to retain symmetric functionality with fscanf, indeed that is noted as being explicitly different.

It was noted that while symmetry with scanf may have some attractiveness, that the strto* functions cannot report that the input string did not match (no error mechanism exists) and that it would just return ZERO. With scanf the error is reported.

However, the issue in the DR really reduces to the use of the term one of on the bullets in 7.20.1.3¶3. The discussion indicated we were in agreement with Clive Feather's comments on this DR.

It was also observed that these changes also apply to the wcsto* functions in 7.24.4.1

Comment from WG14 on 2001-09-18:

Technical Corrigendum

Remove the words 'one of' from the third and fourth bullets of 7.20.1.3¶3.

Remove the words 'one of' from the third and fourth bullets of 7.24.4.1¶3.

Issue 0226: strftime references

Authors: Bill Plauger (US)
Date: 2000-04-10
Status: Closed
Converted from: summary-c99.htm, dr_226.htm

Summary

In <time.h>, strftime references 7.23.1, but the reference should be 7.23.3.1.

Comment from WG14 on 2001-09-18:

Committee Response

The Standard is correct, the reference should be 7.23.1.

Issue 0227: strftime %U, %V, and %W conversion specifiers

Authors: Bill Plauger (US)
Date: 2000-04-10
Status: Closed
Converted from: summary-c99.htm, dr_227.htm

Summary

In <time.h>, strftime conversion specifiers %U, %W, and %V do not need tm_year.

Comment from WG14 on 2001-09-18:

Committee Response

The Standard is correct. tm_year is provided in the case %U and %W, to give freedom to choose the implementation (the output can be determinded using either tm_year or tm_wday, along with tm_yday). For %V it is definitely required as the computation cannot be made without tm_year.

Issue 0228: wmemcmp declaration in Annex B

Authors: Bill Plauger (US)
Date: 2000-04-10
Status: Fixed
Fixed in: C99 TC1
Converted from: summary-c99.htm, dr_228.htm

Summary

The wmemcmp declaration in Annex B should not have restrict for the arguments, and the first argument should be a const.

Comment from WG14 on 2000-11-02:

Technical Corrigendum

In Annex B, change:

int wmemcmp(wchar_t * restrict s1, const wchar_t * restrict s2, size_t n);

to:

int wmemcmp(const wchar_t *s1, const wchar_t *s2, size_t n);

Also, wmemcmp should follow wcsncpy, wmemcpy and wmemmove should follow wcsxfrm, and wcslen should follow wmemchr.

Issue 0229: localeconv() *_sep_by_space table entries issues

Authors: Project Editor (Larry Jones)
Date: 2000-04-10
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_229.htm

Summary

The int_n_sep_by_space and int_p_sep_by_space table entries in 7.11.1.1#10 are incorrect.

The n_sep_by_space entry for the Netherlands should be a 2.

Comment from WG14 on 2001-09-18:

Technical Corrigendum

In 7.11.2.1 paragraph 9:

• remove the word "the" from the first sentence (to indicate that the example is not definitive)
• replace the names of the countries Finland, Italy, Netherlands and Switzerland with Country1, Country2, Country3 and Country4 respectively.

In 7.11.2.1 paragraph 10:

• replace the word "are" with the words "could be" in the first sentence
• replace the names of the countries Finland, Italy, Netherlands and Switzerland with Country1, Country2, Country3 and Country4 respectively
• change the n_sep_by_space table entry for Country3 from 1 to 2
• change all the int_p_sep_by_space table entries from 0 to 1
• Change the int_n_sep_by_space table entries for Country1 and Country3 from 0 to 2 and for Country2 and Country3 from 0 to 1.

Issue 0230: Enumerated type rank

Authors: Derek Jones (UK)
Date: 2000-04-11
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_230.htm

Summary

Clause 6.3.1.1p2:

An enumerated type may have a rank equal to that of int, or even greater than int.

The wording in this paragraph does not allow an object having an enumerated type equal to that of int to appear wherever an object of type int or unsigned int may appear.

Suggested Technical Corrigendum

Changing the existing wording to:

An object or expression with an integer type whose integer conversion rank is less than or equal to the rank of int and unsigned int.

solves the issue, for enumerators, at this point.

A more general solution for enumerations is to add the wording:

An enumerated type with integer conversion rank not less than the rank of int and unsigned int may be used in an expression wherever the compatible signed or unsigned integer may be; the enumerated type is converted to the compatible type. These conversions are also called integer promotions.

Comment from WG14 on 2001-01-29:

Committee Discussion

Integer conversion rank does not address enums that rank equal to int.

The words "or equal to" should be added, but there is another issue regarding enum and whether or not it can ever be greater in rank than int (or unsigned int) since the constant-expressions for the initializers are constrained to the range of values that may be expressed by an int. The words of the simple proposed change are good. The more general proposal doesn't seem to fix anything else.

Technical Corrigendum

In 6.3.1.1 paragraph 2, change the first bullet to:

An object or expression with an integer type whose integer conversion rank is less than or equal to the rank of int and unsigned int.

Issue 0231: Semantics of text-line and non-directive

Authors: Makoto Noda (Japan)
Date: 2000-04-14
Status: Closed
Cross-references: 0448
Converted from: summary-c99.htm, dr_231.htm

Summary

The semantics of text-line and non-directive are not specified in the C99 Standard.

Question
Are text-line and non-directive implementation-defined ?

Comment from WG14 on 2001-09-18:

Committee Response

The standard is correct, but provide the following words with the response, and include them in the Rationale document:

Neither text-line nor non-directive is implementation defined. They are strictly defined as sequences of pp-tokens followed by new-line. Each of these rules represents a placeholder for an intermediate state in the phases of translation, and is expressed as a non-terminal since it has no associated semantics at this phase.

However, these sequences of pp-tokens are still subject to normal processing in the subsequent phases of translation.

Issue 0232: Typo in Annex I

Authors: Makoto Noda (Japan)
Date: 2000-04-14
Status: Fixed
Fixed in: C99 TC1
Converted from: summary-c99.htm, dr_232.htm

Summary

In Annex I Common warnings the text:

• A value is given to an object of an enumeration type other than by assignment of an enumeration constant that is a member of that type, or an enumeration variable that has the same type, or the value of a function that returns the same enumeration type (6.7.2.2).

the "enumeration type" should be "enumerated type".

Comment from WG14 on 2000-11-02:

Technical Corrigendum

Change "enumeration type" to "enumerated type".

Issue 0233: %g, %G precision specification

Authors: Chris Torek, Project Editor (Larry Jones)
Date: 2000-04-24
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_233.htm

Summary

7.19.6.1 (and similarly in 7.24.2.1):

g,G

A double argument representing a floating-point number is converted in style f or e (or in style F or E in the case of a G conversion specifier), with the precision specifying the number of significant digits. If the precision is zero, it is taken as 1. The style used depends on the value converted; style e (or E) is used only if the exponent resulting from such a conversion is less than -4 or greater than or equal to the precision. Trailing zeros are removed from the fractional portion of the result unless the # flag is specified; a decimal-point character appears only if it is followed by a digit.

A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier.

Assuming "significant digits" is being used in the scientific-notation sense. This means that, for instance, the number "12.34" has four significant digits. So does "0.1234", and so does "0.001234". A value like "1.200" also has four significant digits, counting trailing zeros, but not leading zeros.

Now, %g normally suppresses trailing zeros (as described above), so applying %.4g to the value 1.2 produces not "1.200" but rather just "1.2". The # modifier, however, stops the trailing-zero suppression, and:

printf("%#.4g\n", 1.2);

must produce "1.200", four significant digits.

The problem occurs when we go to print the value 0.0. No matter how many digits we tack on the end, we still have no significant digits. So what should:

printf("%#.4g\n", 0.0);

print? "0.0000" has no significant digits. "0.0" has no significant digits. "0.000000000000000000000000000000000000000" still has no significant digits. Which of these, if any, is correct output? Which of these is desirable output?

The only way this wording makes any sense is if "significant digits" means something else entirely, but then what does it mean?

Comment from WG14 on 2007-09-07:

Committee Discussion (for history only)

There seemed to be some uncertainty about whether (for the %.4g example) the exponent would be 0 or 1. This could yield different results.

Some Committee members wondered whether the exponent would be 1 or 0 for ZERO. The bullet describing e, E is clear on this though "If the value is zero, the exponent is zero".

If there is no implementation representation of ZERO, but rather a very small number. In this case, we generally thought that this was a user problem, that they could not rely on a true ZERO having a representation, in which case, they would need to place their own checks for what approximations were acceptable as ZERO and print a literal instead.

Some pathological cases were checked, and appeared to work correctly.

NOTE: In discussion, the original bullets were:

• if X < -4 or X >= P, the conversion is with style e (or E) and precision P - 1
• otherwise the conversion is with style f (or F) and precision P - ( X + 1 )

But these were changed to:

• if P > X >= -4, the conversion is with style f (or F) and precision P - ( X + 1 )
• otherwise the conversion is with style e (or E) and precision P - 1

During discussion, as it was considered to be the more pure form.

Comment from WG14 on 2007-09-07:

Technical Corrigendum

Change 7.19.6.1 paragraph 8 and 7.24.2.1 paragraph 8 to:

g,G

A double argument representing a floating-point number is converted in style f or e (or in style F or E in the case of a G conversion specifier), depending on the value converted and the precision. Let P equal the precision if non-zero, 6 if the precision is omitted, or 1 if the precision is zero. Then, if a conversion with style E would have an exponent of X:

• if P > X >= -4, the conversion is with style f (or F) and precision P - (X + 1).
• otherwise the conversion is with style e (or E) and precision P - 1.

Finally, unless the # flag is used, any trailing zeroes are removed from the fractional portion of the result and the decimal-point character is removed if there is no fractional portion remaining.

Issue 0234: Miscellaneous Typos

Authors: WG14 Convener (John Benito)
Date: 2000-09-26
Status: Fixed
Fixed in: C99 TC1
Converted from: summary-c99.htm, dr_234.htm

Summary #1

In 6.10.3 Macro Replacement the text:

[#5] The identifier __VA_ARGS__ shall occur only in the replacement-list of a function-like macro that uses the ellipsis notation in the arguments.

The word "arguments" should be "parameters".

Summary #2
In the Foreword under major changes, VA_COPY should be va_copy .

Summary #3
In 7.11.2.1, in the description of the lconv members int_p_cs_precedes, int_n_cs_precedes, int_p_sep_by_space, and int_n_sep_by_space, the reference to int_currency_symbol should be int_curr_symbol.

Summary #4
In 7.19.6.14 The vsscanf function:

The vsscanf function returns the value of the macro EOF if an input failure occurs before any conversion. Otherwise, the vscanf function ...

The reference to vscanf should be vsscanf.

Summary #5
In 7.19.6.12 The vsnprintf function is misspelled in the synopsis.

Summary #6
In 7.4.1.12, paragraph #2, "as defined in 6.4.4.2" should be "as defined in 6.4.4.1".

Comment from WG14 on 2001-01-22:

Technical Corrigendum

In the cited text in 6.10.3, change "arguments" to "parameters"

In the Foreword, change VA_COPY to va_copy.

In 7.11.2.1, change all occurrences of int_currency_symbol to int_curr_symbol. Also, append to paragraph 5:

For int_p_sep_by_space and int_n_sep_by_space, the fourth character of int_curr_symbol is used instead of a space.

In 7.19.6.14, change the reference from vscanf to vsscanf.

In 7.19.6.12, change vsprintf to vsnprintf in the synopsis.

In 7.4.1.12, change "(as defined in 6.4.4.2)" to "(as defined in 6.4.4.1)".

Issue 0235: "C" locale collating behaviour not defined

Authors: AFNOR (Antoine Leca)
Date: 2000-10-18
Status: Closed
Converted from: summary-c99.htm, dr_235.htm

Summary

Usually, the locale-specific behaviour for the library functions is specified when it comes to the "C" locale. A noteworthy and well-known exception to that the set of printing characters is not restricted. However, other points that may be seen as overviews. In 7.21.4.3 (strcoll), 7.24.4.4.2 (wcscoll), 7.21.4.5 (strxfrm) and 7.24.4.4.4 (wcsxfrm), no behaviour is specified in the case of the "C" locale.

It is customary to default to respectively strcmp for strcoll, wcscmp for wcscoll, and the identity function for the latter two, but this is not presently required.

Suggested responses

There are basically two choices:

• left things as they are, since use of strcoll and alii in the "C" locale is not expected to be a noteworthy situation
• correct the Standard along the customary way

Suggested Technical Corrigendum

In 7.21.4.3, add a new sentence (or a new paragraph) under Description which says:

In the "C" locale, this function operates in the same way as strcmp does.

In 7.24.4.4.2, add a new sentence in paragraph 2 (or a new paragraph) which says:

In the "C" locale, this function operates in the same way as wcscmp does.

In 7.21.4.5, add a new sentence in paragraph 2 (or a new paragraph) which says:

In the "C" locale, this function copies at most n characters from the string pointed by s2 to s1.

In 7.24.4.4.4, add a new sentence in paragraph 2 (or a new paragraph) which says:

In the "C" locale, this function copies at most n wide characters from the string pointed by s2 to s1.

Comment from WG14 on 2002-03-03:

Committee Response

The committee decided to make no change. The standard does not require that strcoll() and strcmp() perform the same in the C locale.

Issue 0236: The interpretation of type based aliasing rule when applied to union objects or allocated objects

Authors: NCITS J11, Raymond Mak
Date: 2000-10-18
Status: Closed
Cross-references: 0257
Converted from: summary-c99.htm, dr_236.htm

Question

This concerns 6.5 paragraph 6 and 7. Consider the following two pieces of code :

Example 1
#define N ? // optimization opportunities if "qi" does not alias "qd"
   void f(int *qi, double *qd) {
        int i = *qi + 2;
        *qd = 3.1;       // hoist this assignment to top of function???
     *qd *= i;
     return;
   }
   main() {
      void *vp;
      int *pi;
      double *pd;
      vp = malloc(N);
      pi = vp;
      *pi = 7;    // assignment to allocated space thru "p"
      pd = vp;    // "pi" and "pd" are aliases
      f(pi, pd);
      free(vp);
    }
Example 2
// optimization opportunities if "qi" does not alias "qd"
    void f(int *qi, double *qd) {
      int i = *qi + 2;
      *qd = 3.1;       // hoist this assignment to top of function???
      *qd *= i;
      return;
   }
   main() {
     union tag {
       int mi;
       double md;
     } u;
     u.mi = 7;
     f(&u.mi, &u.md);
   }

The two pieces of code are basically the same except that one uses an union object and the other an allocated object. The question is whether these are conforming programs.

At issue here is the pointers within the function f. (This function can be in translation unit of its own and have no knowledge about the union or the allocated object.)

The spirit of the type-based aliasing rule is to help the optimizer to compute aliasing relationship without knowledge about the rest of the program. In this particular case, the type-based aliasing rule is meant to allow the optimizer to hoist the assignment *qd = 3.1 to the top of the function. But this transformation changes the computation.

6.5 paragraph 6 allows example 1. It is not clear if 6.5 paragraph 7 allows example 2. The spirit of type-based aliasing rule is violated.

Discussion:

In the second code example above.

Note that 6.5 paragraph 7 states:

"an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union)."

Arguably this can be read such that the access through u.mi in the above causes u.md to become undefined. If it were the case that u.mi was the active union member then the assignment:

*qd = 3.1;

is an error since the the store is done using an lvalue of type double and the active member has type int. However, an expression such as:

u.md = 3.14;

is legitimate because the union object is used to modify one of it's members and (in this case) changes the active member.

Similarly:

pu->md = 1.1;

changes the active member.

Turning to the first code example above.

Here again the active effective type of the allocated space starts out as type int and the desired semantics are that the assignment:

*qd = 3.1;

is an error because the expression *qd has type double.

The char type should have special privileges. Programs should be able to erase the active effective type via:

memset(vp, 0, sizeof(int));
memset(&u, 0, sizeof(union tag));

or possible change the active effective type via:

memcpy(&u, &u2, sizeof(union tag)};

or even:

char *p1 = (char *) &u;
char *p2 = (char *) &u2;
for (int i = 0; i < sizeof(union tag); i++) {
   p1[i] = p2[i];
}

That is, the char types have special alias privileges that let them scribble on an object that already has an effective type.

Suggested change:

(We offer the following as a starting point for further discussion.)

To tackle the first code example, change 6.5 paragraph 6, second sentence,

From:

If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value.

to:

If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses.

That is, the last phrase "that do not modify the stored value" is removed.

To tackle the second code example, use the concept of the effective type of an union object (i.e. use it to track the active member). Either describe it in the rationale, or formally introduce it in the standard.

Effective type of an union object.

The type of the last member accessed within an union object is the effective type of the union object. For members with types not compatible with the effective type of the union object, the lvalue used for the store shall be the result of member selection from the union.

Note that this forces the union declaration to be visible in the translation unit.

If we add this to the standard, add it immediately before 6.5p7.

Comment from WG14 on 2006-05-08:

Committee Discussion

Committee believes that Example 2 violates the aliasing rules in 6.5 paragraph 7:

"an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union)."

In order to not violate the rules, function f in example should be written as:

   union tag {
                int mi;
                double md;
        } u;
        void f(int *qi, double *qd) {
                int i = *qi + 2;
                u.md = 3.1;   // union type must be used when changing effective type
                *qd *= i;
        return;
        }

Example 1 is still open. The committee does not think that the suggested wording is acceptable.

More discussion is found in reflector message #9337, and in the Curacao meeting minutes N973 and in the Santa Cruz meeting minutes N987.
The current situation requires more consideration, but general consensus seems to be;

• Limit the use of pointers to union members,
• Consensus for the visible alias rule exists,
• The requirement of global knowledge is problematic,
• Common understanding is that the union declaration must be visible in the translation unit.

Committee Response

Both programs invoke undefined behavior, by calling function f with pointers qi and qd that have different types but designate the same region of storage. The translator has every right to rearrange accesses to *qi and *qd by the usual aliasing rules.

Issue 0237: Declarations using [static]

Authors: WG14 Convener (J. Benito)
Date: 2001-04-25
Status: Closed
Converted from: summary-c99.htm, dr_237.htm

Summary Given the following declarations:

  void f(int n, int x[static n]);
   void f(int n, int x[n]) {}

An example at the end of 6.7.5.3 (p21) indicates that these declarations are compatible, but it seems like there should also be something about this in composite types.

1. If some declarations include "static" and some don't, what is the effect?
2. Does static only count if it is on the definition?
3. Does it count if it is on the declaration visible for a given call?

Comment from WG14 on 2003-10-23:

Committee Discussion

The Committee discussed adding a footnote to 6.7.5.3 paragraph 7 along the lines of item 1.

Committee Response

The Committee believe the specification about composite types is clear enough; the composite type will be based on "qualified pointer to type", and the static keyword (and any size values) are not used.

1. The effect is as if all of the declarations had used static and the largest size value used by any of them. Each declaration imposes requirements on all calls to the function in the program; the only way to meet all of these requirements is to always provide pointers to as many objects as the largest such value requires.
2. No.
3. Yes. Visibility is not relevant.

Issue 0238: Decriptions of fma() overflow and underflow errors are missing

Authors: Fred Tydeman (US)
Date: 2001-02-25
Reference document: ISO/IEC WG14 N943
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_238.htm

Summary

The description section for fma() needs to mention possible overflow and underflow errors.

Details

All, but one, of the math functions that can overflow have as part of their description, a phrase about range error. The one function that is missing it is fma().

All, but one, of the math functions that can underflow have as part of their description, a phrase about range error. The one function that is missing it is fma().

Suggested Technical Corrigendum

In 7.12.13.1 fma add to description:

A range error may occur.

Comment from WG14 on 2003-10-23:

Technical Corrigendum

In 7.12.13.1 fma add to description:

A range error may occur.

Issue 0239: Annex F nexttoward description is inconsistent with 7.12.11.4. and F.9.8.3

Authors: Fred Tydeman (US)
Date: 2001-02-25
Reference document: ISO/IEC WG14 N943
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_239.htm

Summary

The description for nexttoward() in Annex F should be changed to reference nextafter to be consistent with 7.12.11.4. and F.9.8.3.

Details

Currently, F.9.8.4 has: No additional requirements. From that, one could conclude that there is no required underflow or overflow for nexttoward by annex F. But, F.9.8.3 has two explicit error conditions on nextafter and 7.12.11.4 says nexttoward is similar to nextafter. We need to make it clear that nextafter and nexttoward have the same requirements with respect to range errors in annex F.

Suggested Technical Corrigendum

In F.9.8.4 nexttoward change:

No additional requirements.

to

No additional requirements beyond nextafter.

Comment from WG14 on 2001-10-16:

Technical Corrigendum

In F.9.8.4 nexttoward change:

No additional requirements.

to

No additional requirements beyond those on nextafter.

Issue 0240: lrint, llrint, lround, llround, and ilogb descriptions are not consistent for unrepresentable results

Authors: Fred Tydeman (US)
Date: 2001-02-25
Reference document: ISO/IEC WG14 N943
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_240.htm

Summary

lrint, llrint, lround, llround, and ilogb need to have consistent and explicit descriptions when results are too big to represent in an integer type. Also, that case should be treated as a domain error.

Details

IEC 60559 requires that when a large floating-point value, an infinity, or a NaN is converted to an integer, and the result cannot be represented as an integer in the result's format, an invalid operation has occurred. This is currently mostly reflected in C99's Annex F. This condition corresponds to C's domain error.

ilogb does not discuss (in either 7.12.6.5 or annex F) what should happen if the expected result cannot be represented as an int. It should be treated as a domain error (because it is an invalid operation to IEC 60559). The "correct" result of ilogb(0) is -infinity (which cannot be represented as an int, so should be treated as a domain error). ilogb(NaN) does not follow the normal convention of NaN in implies NaN out, so this unusual case needs to be discussed.

lrint and llrint are inconsistent on how large arguments are treated between 7.12.9.5 (range error) and Annex F (domain error).

lround and llround are inconsistent on how large arguments are treated between 7.12.9.7 (range error) and Annex F (domain error).

Suggested Technical Corrigendum

In 7.12.6.5 ilogb:

Change:

A range error may occur if x is 0.

to

A domain error occurs if x is 0, infinite, or NaN.

Add:

If the correct value is outside the range of the return type, the numeric result is unspecified, and a domain error occurs.

In 7.12.9.5 lrint llrint:

Change:

If the rounded value is outside the range of the return type, the numeric result is unspecified. A range error may occur if the magnitude of x is too large.

to

If the rounded value is outside the range of the return type, the numeric result is unspecified, and a domain error occurs.

In 7.12.9.7 lround llround:

Change:

If the rounded value is outside the range of the return type, the numeric result is unspecified. A range error may occur if the magnitude of x is too large.

to

If the rounded value is outside the range of the return type, the numeric result is unspecified, and a domain error occurs.

Comment from WG14 on 2004-03-16:

Technical Corrigendum

In 7.12.6.5 ilogb:

Change:

A range error may occur if x is 0.

to

A domain error or range error may occur if x is 0, infinite, or NaN.

Add:

If the correct value is outside the range of the return type, the numeric result is unspecified.

In F.9.3.5 ilogb:

Change:

No additional requirements.

to

If the correct result is outside the range of the return type, the numeric result is unspecified and the "invalid" floating-point exception is raised.

In 7.12.9.5 lrint and llrint:

Change:

If the rounded value is outside the range of the return type, the numeric result is unspecified. A range error may occur if the magnitude of x is too large.

to

If the rounded value is outside the range of the return type, the numeric result is unspecified, and a domain error or range error may occur.

In 7.12.9.7 lround and llround:

Change:

If the rounded value is outside the range of the return type, the numeric result is unspecified. A range error may occur if the magnitude of x is too large.

to

If the rounded value is outside the range of the return type, the numeric result is unspecified, and a domain error or range error may occur.

Issue 0241: Make the base standard and Annex F consistent for pow(0, <0)

Authors: Fred Tydeman (US)
Date: 2001-02-25
Reference document: ISO/IEC WG14 N943
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_241.htm

Summary

pow(0, <0) should be considered a pole error (result is an exact infinity) in the base standard (it already is in Annex F).

Details

pow(0, <0) is inconsistent between 7.12.7.4 (domain error) and Annex F (range error via divide-by-zero).

pow(0, <0) is effectively 1/0, which is a pole or singularity error, which is a divide-by-zero exception to Annex F and a range error to 7.12.

Counter-argument: The domain error for this case is a may, not a shall. In addition, 7.12.7.4 has

A range error may occur

without any qualifications. So, an implementation is allowed to treat this case as a range error.

Suggested Technical Corrigendum

In 7.12.7.4 pow:

Split:

A domain error may occur if x is zero and y is less than or equal to zero.

into

A domain error may occur if x is zero and y is zero.

and

A range error may occur if x is zero and y is less than zero.

Comment from WG14 on 2001-10-16:

Technical Corrigendum

In 7.12.7.4 pow:

Split:

A domain error may occur if x is zero and y is less than or equal to zero.

into:

A domain error may occur if x is zero and y is zero.

and

A domain error or range error may occur if x is zero and y is less than zero.

Issue 0242: Make the base standard and Annex F consistent for logb(0)

Authors: Fred Tydeman (US)
Date: 2001-02-25
Reference document: ISO/IEC WG14 N943
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_242.htm

Summary

logb(0) should be considered a pole error in the base standard (it already is in Annex F).

Details

logb(0) is inconsistent between 7.12.6.11 (domain error) and Annex F (range error via divide-by-zero).

logb(0) is effectively the same as log(0), log2(0), or log10(0), all of which are a pole or singularity error, which is a divide-by-zero exception to Annex F and a range error to 7.12. But, logb treats it as a domain error in 7.12.6.11.

Suggested Technical Corrigendum

In 7.12.6.11 logb:

Change:

A domain error may occur if the argument is zero.

to

A range error may occur if the argument is zero.

Comment from WG14 on 2001-10-16:

Technical Corrigendum

In 7.12.6.11 logb:

Change:

A domain error may occur if the argument is zero.

to

A domain error or range error may occur if the argument is zero.

Issue 0243: Make the base standard and Annex F consistent for fmod(), remainder(), and remquo() for a zero divisor

Authors: Fred Tydeman (US)
Date: 2001-02-25
Reference document: ISO/IEC WG14 N943
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_243.htm

Summary

fmod(), remainder(), and remquo() should be made consistent with each other when the divisor is zero. There are two "correct" behaviours when the divisor is zero: Treat it as a domain error (cannot divide by zero), or, based upon limits, compute a zero remainder. This series of changes may also require that IEEE-754 be changed (to allow a zero result in addition to the currently required invalid operation). Assuming that fmod(), remainder(), and remquo() should be consistent with each other, the following needs to be done.

An alternative is to do some of these changes, or changes along these lines.

It is assumed that requiring just the return of zero behaviour is too drastic as there are many millions of chips already doing the invalid operation behaviour.

Details

For a fixed x, as one takes the limit as y approaches zero, the remainder of x/y approaches zero (0 <= |result| < |y|) and the quotient is unspecified.

IEC 60559 requires that x REM y, when y is zero, be an invalid operation, e.g., a domain error.

fmod(x,0) is currently allowed to be either 0 or a domain error by 7.12.10.1, while Annex F requires it to be an invalid exception, e.g., domain error.

remainder(x,0) is currently unspecified by 7.12.10.2, while Annex F requires it to be an invalid exception, e.g., domain error.

remquo(x,0) is currently unspecified by 7.12.10.3, while Annex F requires it to be an invalid exception, e.g., domain error. In addition, nothing is said about the quotient that is stored for this case.

Counter-argument: These functions are discontinuous along the lines y = mx or y = (m+1/2)x for integers m. We see no reason to "take the limit as y approaches zero".

Allowing two different behaviours for these functions for the same arguments, will cause applications to be more complicated, with no real added benefit.

Counter-counter-argument: By discontinuous, I assume you mean that they are like saw-tooth shaped functions, e.g., a linear rise and a vertical fall. I agree with that, but, as one approaches the line y=0, the height of the teeth gets smaller and smaller.

Suggested Technical Corrigendum

In 7.12.10.1 fmod:

No change needed.

In 7.12.10.2 remainder:

Add to Returns:

If y is zero, whether a domain error occurs or the remainder functions return zero is implementation defined.

In 7.12.10.3 remquo:

Add to Returns:

If y is zero, whether a domain error occurs or the remquo functions return zero is implementation defined.

If y is zero, the quotient stored is unspecified.

In F.9.7.1 fmod:

Change

fmod(x,y) returns a NaN and raises the "invalid" floating-point exception for x infinite or y zero.

to two items:

fmod(x,y) returns a NaN and raises the "invalid" floating-point exception for x infinite.

and

For y zero, fmod(x,y) either returns a zero (with sign of x), or returns a NaN and raises the "invalid" floating-point exception.

In F.9.7.2 remainder:

Add:

For y zero, remainder(x,y) either returns a zero (with sign of x), or returns a NaN and raises the "invalid" floating-point exception.

In F.9.7.3 remquo:

Add:

For y zero, remquo(x,y) either returns a zero (with sign of x), or returns a NaN and raises the "invalid" floating-point exception; and, in both cases, has an unspecified quotient stored.

Also add,

When remquo returns a NaN, the quotient stored is unspecified.

Comment from WG14 on 2001-10-16:

Technical Corrigendum

In 7.12.10.2 remainder:

Add to Returns:

If y is zero, whether a domain error occurs or the remainder functions return zero is implementation defined.

In 7.12.10.3 remquo:

Add to Returns:

If y is zero, whether a domain error occurs or the remquo functions return zero is implementation defined.

If y is zero, the quotient stored is unspecified.

In J.3.12 Library functions:

Add (after fmod):

Whether a domain error occurs or zero is returned when an remainder function has a second argument of zero (7.12.10.2).

Whether a domain error occurs or zero is returned when an remquo function has a second argument of zero (7.12.10.3).

Issue 0244: tgamma(zero or negative integer) should be considered a pole error

Authors: Fred Tydeman (US)
Date: 2001-02-25
Reference document: ISO/IEC WG14 N943
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_244.htm

Summary

tgamma(zero or negative integer)should be considered a pole error since the correct mathematical result is an exact infinity (whose sign depends upon the side that the limit is taken from). Annex F already does this for the zero argument case.

Details

When the correct mathematical result is an exact infinity (from finite arguments), it is considered a pole or singularity error. This is true if the result's sign is independent of the direction of the limit. It is believed to be true that it still is a pole error if the sign of the infinite result depends upon the direction of the limit.

Some symbolic math packages support the concept of +/-infinity in addition to +infinity and -infinity, and in those, tgamma(zero or negative integer) is +/-infinity.

Since +/-infinity cannot be represented in most (all?) floating-point formats, return +infinity for that value.

LIA-2 treats similar cases (math function with exact non-zero integer argument and a result of +/-infinity, such as tan(90 degrees)) as a pole error with the result of signed infinity.

Counter-argument: For 0.0 we have the luxury of +0.0 and -0.0. Non-zero integers don't have "sides". There is no concept of +/-infinity in IEC 60559 (nor any other hardware floating-point representation), just +infinity and -infinity. If there is no one correct result for a given argument, then that case must be considered an invalid operation or a domain error. tgamma(negative integer) has two results (+infinity or -infinity), so must be considered invalid. tgamma(x), as x approaches -infinity, has no unique limit, so must also be considered invalid.

Suggested Technical Corrigendum

In 7.12.8.4 tgamma:

Change:

A domain error occurs if x is a negative integer or if the result cannot be represented when x is zero.

to

A range error may occur if x is a negative integer or zero.

In F.9.5.4 tgamma:

Change:

tgamma(x) returns a NaN and raises the "invalid" floating-point exception for x a negative integer.

to

tgamma(x) returns +INF and raises the "divide-by-zero" floating-point exception for x a negative integer.

Change:

tgamma(-INF) returns a NaN and raises the "invalid" floating-point exception.

to

tgamma(-INF) returns +INF and raises the "divide-by-zero" floating-point exception.

Comment from WG14 on 2001-10-16:

Technical Corrigendum

In 7.12.8.4 tgamma:

Change:

A domain error occurs if x is a negative integer or if the result cannot be represented when x is zero.

to

A domain error or range error may occur if x is a negative integer or zero.

Issue 0245: Missing paragraph numbers

Authors: WG14
Date: 2001-09-21
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_245.htm

Summary

1. In F.9.8.4, the second paragraph is missing a paragraph number.
2. In 7.20.7.2, the first paragraph of the Returns section is missing a paragraph number.
3. In 7.18.2.1, the first paragraph is missing a paragraph number.
4. In 7.18.2.2, the first paragraph is missing a paragraph number.
5. In 7.18.2.3, the first paragraph is missing a paragraph number.
6. In 7.18.2.4, the first paragraph is missing a paragraph number.
7. In 7.18.2.5, the first paragraph is missing a paragraph number.
8. In 7.19.4.3 Recommended Practice, the first paragraph is missing a paragraph number.
9. In 7.21.4.3 Description, the first paragraph is missing a paragraph number.
10. In G.3, the first paragraph is missing a paragraph number.
11. In G.6.2.2, the first paragraph is missing a paragraph number.

Suggested Technical Corrigendum

Add the missing paragraph number in F.9.8.4, 7.20.7.2, 7.18.2.1, 7.18.2.2, 7.18.2.3, 7.18.2.4, 7.18.2.5, 7.19.4.3, 7.21.4.3, G.3 and G.6.2.2

Comment from WG14 on 2003-03-06:

Technical Corrigendum

Add the missing paragraph number in F.9.8.4, 7.20.7.2, 7.18.2.1, 7.18.2.2, 7.18.2.3, 7.18.2.4, 7.18.2.5, 7.19.4.3, 7.21.4.3, G.3 and G.6.2.2

Issue 0246: completion of declarators

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Converted from: summary-c99.htm, dr_246.htm

Problem

6.2.1#7 reads in part:

Any other identifier has scope that begins just after the completion of its declarator.

However, nothing says when a declarator is completed. While it seems obvious to experienced people that this means the syntactic end of the declarator, the term "complete" has other meanings when discussing declarations and objects, and therefore it's a bad term to use.

Suggested Technical Corrigendum

Change the quoted text to:

Any other identifier has scope that begins just after the end of the full declarator it appears in.

Comment from WG14 on 2002-03-06:

Committee Response

The suggested words don't appear to be an improvement; the current phrasing is clear enough.

Issue 0247: are values a form of behaviour ?

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_247.htm

Problem

I can see nothing that says or implies that production of an unspecified value is a form of unspecified behaviour, and similarly for implementation-defined values. It is therefore arguable that a program is strictly-conforming even if its output depends on an unspecified value.

Suggested Technical Corrigendum

Add a new paragraph 4#2a after 4#2:

[#2a] An evaluation that makes use of an unspecified or implementation-defined value is a form of unspecified or implementation-defined behaviour respectively.

Comment from WG14 on 2002-03-06:

Technical Corrigendum

In section 3.4.4, prepend

"Use of an unspecified value, or other ..." before "behavior where".

Issue 0248: limits are required for optional types

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_248.htm

Problem

The types sig_atomic_t and wchar_t are optional on freestanding implementations, since they don't have to provide the relevant headers. But the limits SIG_ATOMIC_MIN, SIG_ATOMIC_MAX, WINT_MIN, and WINT_MAX are in <stdint.h>, which all implementations must provide. So a freestanding implementation must provide limits for types which it doesn't implement.

Suggested Technical Corrigendum

Append to 7.18.3#2:

A freestanding implementation shall only define the symbols corresponding to those typedef names it actually provides.

Comment from WG14 on 2002-03-06:

Technical Corrigendum

Append to 7.18.3#2:

An implementation shall define only the macros corresponding to those typedef names it actually provides.

Add a footnote to the last sentence of 7.18.3#2 to read:

A freestanding implementation need not provide all of these types.

Issue 0249: Lacuna applying C89:TC1 to C99

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_249.htm

Problem

Defect Report 009 made a change to the text concerning function declarators. This text seems not have made it into C99, even though the issue remains valid. The change should be reinstated.

Suggested Technical Corrigendum

Change 6.7.5.3#11 to:

[#11] If, in a parameter declaration, an identifier can be treated as a typedef name or as a parameter name, it shall be taken as a typedef name.

Comment from WG14 on 2002-03-06:

Technical Corrigendum

Change 6.7.5.3#11 to:

If, in a parameter declaration, an identifier can be treated as a typedef name or as a parameter name, it shall be taken as a typedef name.

Issue 0250: non-directives within macro arguments

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC2
Cross-references: 0303, 0448
Converted from: summary-c99.htm, dr_250.htm

Problem

Consider the code:

  #define nothing(x) // Nothing    /* Case 1 */
    nothing (
    #include <stdio.h>
    )
    /* Case 2 */
    nothing (
    #nonstandard
    )

6.10.3#11 reads in part:

If there are sequences of preprocessing tokens within the list of arguments that would otherwise act as preprocessing directives, the behavior is undefined.

This clearly covers case 1. However, it is not clear whether or not case 2 is a preprocessing directive. It is a "non-directive", but is that also a directive ? If case 2 is a directive, it is undefined behaviour. If it is not, then case 2 is strictly-conforming and macro-expands to nothing.

Since non-directives are only valid as extensions, it might be more sensible for them to behave as directives do and make the behaviour undefined in this case.

Suggested Technical Corrigendum

In 6.10.3#11, change the last sentence to:

If there are sequences of preprocessing tokens within the list of arguments that would otherwise act as preprocessing directives or as non-directives (that is, the first pre-processing token on a line is a #), the behavior is undefined.

Comment from WG14 on 2002-03-06:

Committee Response

The Committee believes the Standard is correct (preprocessing directive includes non-directive), therefore, the anwser to the question on this is yes.

Technical Corrigendum

In 6.10 #2, italicize the term "preprocessing directive".

In 6.10.3 paragraph 11, last sentence. After "preprocessing directives", add the following footnote.

Despite the name, a non-directive is a preprocessing directive.

Issue 0251: are struct fred and union fred the same type ?

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC3
Converted from: summary-c99.htm, dr_251.htm

Problem

Consider the code:

 union fred { int a; }
    int main (void)
    {
        struct fred *ptr;  /* Line X */
        // ...

I can see nothing that forbids this code. In particular, 6.7.2.3#8 reads:

[#8] If a type specifier of the form

        struct-or-union identifier

or

        enum identifier

occurs other than as part of one of the above forms, and a declaration of the identifier as a tag is visible, then it specifies the same type as that other declaration, and does not redeclare the tag.

At line X a declaration of fred as a tag is visible, so this line specifies the same type as that other declaration, even though this uses struct and that uses union !

It has been further pointed out to me that nothing in the Standard actually says that union x is a union type as opposed to a structure type, and vice versa.

Suggested Technical Corrigendum

Append to 6.7.2.1#6:

The keywords struct and union indicate that the type being specified is, respectively, a structure type or a union type.

Add a new paragraph following 6.7.2.3#1:

[#1a] Where two declarations that use the same tag declare the same type, they shall both use the same choice of struct, union, or enum.

Comment from WG14 on 2006-03-29:

Committee Discussion

The Committee is inclined to accept the suggested TC, but the issue is still being debated.

Technical Corrigendum

Append to 6.7.2.1#6:

The keywords struct and union indicate that the type being specified is, respectively, a structure type or a union type.

Add a new paragraph following 6.7.2.3#1:

[#1a] Where two declarations that use the same tag declare the same type, they shall both use the same choice of struct, union, or enum.

Issue 0252: incomplete argument types when calling non-prototyped functions

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC3
Converted from: summary-c99.htm, dr_252.htm

Problem

Consider the code:

   void jim ();
    void sheila (void);
    // ...   sheila (jim ());   /* Line A */
    jim (sheila ());   /* Line B */

Line A violates the constraint of 6.5.2.2#2, that requires the argument to have a type that can be assigned to the parameter type. But line B doesn't because that constraint only applies to prototyped functions. 6.5.2.2#4 reads in part:

[#4] An argument may be an expression of any object type.

but this is not a constraint. Should it not be ? After all, the compiler has to know the type of the argument in order to compile the function call, so it can check at that point that the argument has a complete object type.

Suggested Technical Corrigendum

Add a new paragraph #1a following 6.5.2.2#1:

[#1a] Each argument shall have a type which is a completed object type.

Comment from WG14 on 2002-03-06:

Committee Response

This should not be a constraint.

Issue 0253: "overriding" in designated initializers

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Cross-references: 0413
Converted from: summary-c99.htm, dr_253.htm

Problem

Consider the code:

   struct fred
    {
        char s [6];
        int n;
    };
    struct fred x [] = { { { "abc" }, 1 }, [0].s[0] = 'q'        };
    struct fred y [] = { { { "abc" }, 1 }, [0] = { .s[0] = 'q' } };

Both x and y will contain one element of type struct fred, which will be initialized by the initializer { { "abc" }, 1 } and then modified in some way. The question is exactly how it is modified.

6.7.8#19 reads:

[#19] The initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject; all subobjects that are not initialized explicitly shall be initialized implicitly the same as objects that have static storage duration.

In the case of x, it is fairly clear that the first initializer sets:

   x [0].s [0] = 'a'
    x [0].s [1] = 'b'
    x [0].s [2] = 'c'
    x [0].s [3] = '\0'
    x [0].n     = 1

and the second one sets:

   x [0].s [0] = 'q'

Finally, the remaining subobjects are initialized implicitly:

   x [0].s [4] = 0
    x [0].s [5] = 0

Now consider the second initializer for y. One point of view says that this behaves the same as for x: it specifies a value for y [0].s [0], after which the two remaining elements of y [0].s are still uninitialized and so are set to zero. The other point of view says that this sets:

   y [0] = (struct fred) { .s[0] = 'q' }

and that the rule concerning "all subobjects that are not initialized explicitly" applies recursively. If so, the effect is to set:

   x [0].s [0] = 'q'
    x [0].s [1] = 0
    x [0].s [2] = 0
    x [0].s [3] = 0
    x [0].s [4] = 0
    x [0].s [5] = 0
    x [0].n     = 0

Which of these is correct ?

Suggested Technical Corrigendum 1

If x and y are supposed to have the same effect, change 6.7.8#19 to:

[#19] The initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject. When all initializers have been applied, any subobjects of the overall object being initialized that have not been initialized explicitly shall be initialized implicitly the same as objects that have static storage duration.

and add a new paragraph at the end:

[#39] To illustrate the rules for implicit initialization, in:

       struct fred
        {
            char s [6];
            int n;
        };
        struct fred x [] = { { { "abc" }, 1 }, [0].s[0] = 'q'        };
        struct fred y [] = { { { "abc" }, 1 }, [0] = { .s[0] = 'q' } };

the definitions of x and y result in identical objects. Each will be an array with one element; within that element, the members s[4] and s[5] are implicitly initialized to zero.

Suggested Technical Corrigendum 2

If x and y are supposed to be different, change 6.7.8#19 to:

[#19] The initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject; for each brace-enclosed list, all subobjects within the object that that list initializes that are not initialized explicitly shall be initialized implicitly the same as objects that have static storage duration.

and add a new paragraph at the end:

[#39] To illustrate the rules for implicit initialization, in:

       struct fred
        {
            char s [6];
            int n;
        };
        struct fred x [] = { { { "abc" }, 1 }, [0] = { .s[0] = 'q' } };
        struct fred y [] = { { .s[0] = 'q' } };

the definitions of x and y result in identical objects. Each will be an array with one element; within that element, all the members are implicitly initialized to zero except for s[0]. In the definition of x the first initializer has no effect, since the second one initializes the same subobject (x[0]).

Comment from WG14 on 2002-05-15:

Committee Response

Given the example

   struct fred
    {
        char s [6];
        int n;
    };
    struct fred y [] = { { { "abc" }, 1 }, [0] = { .s[0] = 'q' } };

6.7.8#21 makes it clear already that { .s[0] = 'q' } initializes a whole object of type "struct fred" whose members (other than s[0]) are initialized as though they were static storage, so this initialization of y[0] overrides the previous one. Thus, all subobjects of y[0] other than s[0] are zeroed. Paragraph #21 of 6.7.8 also makes it clear that the initializations for x and y are different.

Committee Discussion

The tem "designated initializer" is never mentioned in the Standard though it appears in the index and new features section (the Standard uses the term "designation initializer" in the text).

Issue 0254: mbtowc and partial characters

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Converted from: summary-c99.htm, dr_254.htm

Problem

If mbtowc() is given a partial character (or an escape sequence that isn't a complete character), it returns -1. However, is it supposed to remember the relevant state information or should it ignore it ?

Consider an implementation where the character '\xE' starts an alternate shift state and '\xF' returns to the initial shift state. The wide character encodings are:

Starting in the initial shift state,

   mbtowc (&wc, "\xEZ", 2);

should return 2 and set wc to 0x15A. However, starting in the initial shift state, consider:

   mbtowc (&wc1, "\xE", 1);
    mbtowc (&wc2, "Z",   1);

I would expect that the first call returns -1, leaving wc1 unaltered, while the second returns 1 and sets wc2 to 0x5A. However, is it permitted for the second to set wc2 to 0x15A ? If so, how is an application meant to use mbtowc ?

[The newer function mbrtowc does not have this problem.]

Suggested Technical Corrigendum

The UK C Panel prefers to add a new return value for this case. To do so, change the main part (see the previous DR) of 7.20.7.2#3 to read:

If s is a null pointer, the mbtowc function returns a nonzero or zero value, if multibyte character encodings, respectively, do or do not have state-dependent encodings. If s is not a null pointer, the mbtowc function returns the first of the following that applies (given the current conversion state):

0	if s points to the null character
between 1 and n inclusive	if the next n or fewer bytes complete a valid multibyte character (which is the value stored); the value returned is the number of bytes that complete the multibyte character. The value returned will not be greater than that of the MB_CUR_MAX macro.
(size_t)(-2)	if the next n bytes contribute to an incomplete (but potentially valid) multibyte character, and all n bytes have been processed (no value is stored).
(size_t)(-1)	if an encoding error occurs, in which case the next n or fewer bytes do not contribute to a complete and valid multibyte character (no value is stored); the value of the macro EILSEQ is stored in errno, and the conversion state is unspecified.

(note that most of this wording comes from mbrtowc) and delete #4.

If this option is unacceptable, then append to 7.20.7.2#2:

If the next multibyte character is incomplete or invalid, the shift state is unaffected and nothing is stored.

Comment from WG14 on 2002-03-06:

Committee Response

The Committee believe the behavior of this example is unspecified. The mbrtowc() function provides a superior migration path, so we are leaving this alone.

Issue 0255: non-prototyped function calls and argument mismatches

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Cross-references: 0316
Converted from: summary-c99.htm, dr_255.htm

Problem

Consider the code:

   #include <stdio.h>
    int f ();
    int main (void)
    {
        return f (0);
    }
    #ifdef PROTO
    int f (unsigned int x)
    #else
    int f (x) unsigned int x;
    #endif
    {
        return printf ("%u\n", x);
    }

Now, 6.5.2.2#6 reads:

[#6] If the expression that denotes the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and arguments that have type float are promoted to double. These are called the default argument promotions.
[...]
If the function is defined with a type that includes a prototype, and either the prototype ends with an ellipsis (, ...) or the types of the arguments after promotion are not compatible with the types of the parameters, the behavior is undefined. If the function is defined with a type that does not include a prototype, and the types of the arguments after promotion are not compatible with those of the parameters after promotion, the behavior is undefined, except for the following cases:

• one promoted type is a signed integer type, the other promoted type is the corresponding unsigned integer type, and the value is representable in both types;
• both types are pointers to qualified or unqualified versions of a character type or void.

So the above code is undefined if PROTO is defined, but is legitimate if it is not. This seems inconsistent.

Traditionally, when a function is called and no prototype is in scope, the implementation applies the default argument promotions to the argument value and then assumes that is the parameter type. If it isn't, this can cause all kinds of problems, which is why the undefined behaviour. However, if it is known that the argument value will be correctly handled by the parameter type, there is no problem; this is the rationale behind the exceptions.

The exceptions should apply to both cases, no matter how the function is eventually defined.

Suggested Technical Corrigendum

Change the part of 6.5.2.2#6 after the omission to:

If the types of the arguments after promotion are not compatible with those of the parameters after promotion 78A), the behavior is undefined, except for the following cases:

• one promoted type is a signed integer type, the other promoted type is the corresponding unsigned integer type, and the value is representable in both types;
• both types are pointers to qualified or unqualified versions of a character type or void.

If the function is defined with a type that includes a prototype, and either any parameter has a type which is altered by the default argument promotions or the prototype ends with an ellipsis (, ...), the behavior is undefined.

78A) Because of the rule later in this paragraph, it is only necessary to check whether the parameter type undergoes promotion when the function is not defined using a prototype.

Comment from WG14 on 2002-05-15:

Committee Response

The Committee does not wish to further refine the behavior of calls not in the scope of prototypes. In practice, this will not be a problem, and the Committee does not wish to define the behavior.

Issue 0256: multiple inclusion of headers

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Converted from: summary-c99.htm, dr_256.htm

Problem

Consider the code:

   #include <stdio.h>     // Line 1
    #undef FOPEN_MAX       // Line 2, permitted by 7.1.3#3    #include <stdio.h>     // Line 3    #ifdef FOPEN_MAX       // Line 4

7.1.2 says:

[#4] Standard headers may be included in any order; each may be included more than once in a given scope, with no effect different from being included only once, except that the effect of including <assert.h> depends on the definition of NDEBUG (see 7.2).

Does "with no effect different" mean:

1. the includes on lines 1 and 3 have the same effect, so at line 4 the macro FOPEN_MAX is defined;
2. the include on line 3 has no effect, so that at line 4 the macro FOPEN_MAX is undefined;
3. something else ?

Most current implementations wrap the contents of headers with an "idempotent guard", such as:

   #ifndef _STDIO_H_INCLUDED_
    #define _STDIO_H_INCLUDED_
    // Real contents go here   #endif

This will provide behaviour (2), which I would suggest is the most desirable.

Furthermore, the concept of scope doesn't apply here, both because includes happen during preprocessing and because there is a requirement in the same paragraph that:

If used, a header shall be included outside of any external declaration or definition,

If the wording is being altered, this would be a good opportunity to fix this as well.

Suggested Technical Corrigendum

Change the first sentence of 7.1.2#4 to:

[#4] Standard headers may be included in any order; each may be included any number of times in a preprocessing translation unit. The second and subsequent occurrences of a given header shall be ignored, except in the case of <assert.h> (where the behaviour is defined in subclause 7.2).

Comment from WG14 on 2002-03-06:

Committee Response

The Committee believe that both answer 1 and 2 are allowed, and does not see a compelling reason to change this.

Issue 0257: common initial sequences and related issues with unions

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Cross-references: 0236, 0283
Converted from: summary-c99.htm, dr_257.htm

Problem

6.5.2.3#5 reads:

[#5] One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the complete type of the union is visible. Two structures share a common initial sequence if corresponding members have compatible types (and, for bit-fields, the same widths) for a sequence of one or more initial members.

Two possible reasons have been suggested for this rule.

1. The implementation may put padding between structure members. This rule is necessary to ensure that the common initial sequence uses the same padding in both places, so that the corresponding members occupy the same location.

2. If we consider part of the second example in 6.5.2.3#8:

      struct t1 { int m; };
       struct t2 { int m; };
       int f(struct t1 * p1, struct t2 * p2)
       {
           if (p1->m < 0)
               p2->m = -p2->m;
           return p1->m;
       }
   

   the rule is necessary for an implementation to realize that p1 and p2 might refer the same location.

If (1) is the reason, then the example is a bad one because the two members are both at the start of their respective structures, and therefore are required to be at an offset of 0 from the start of the structure (and therefore of the union). It should be changed to use a member further along a common initial sequence.

On the other hand, the requirement is not actually very suitable. Consider the code:

   struct t1 { int x; double y; char z; } s1;
    struct t2 { int i; double q; unsigned long u; } s2;
    void f1 (struct t1 *p) { p->y = sqrt ((double) p->x); }
    void f2 (struct t2 *p) { p->q = sqrt ((double) p->i); }

    union { struct t1 t1; struct t2 t2; } u;
    // Followed by code using the common initial sequence property

The implementation might wish to use different padding in structures t1 and t2. It is prevented from doing so by the existence of the union, but a one-pass compilation will not become aware of this until after compiling f1 and f2. Therefore it will have to assume, when deciding the layout of the structures, that there might be a union. Therefore the rule about a union type being visible is useless.

If, on the other hand, (2) is the reason, then the wording does not address enough cases. For example, consider a version of the example in 6.5.2.3#8 where one member is signed and the other is unsigned.

   struct t1 { signed   int m; };
    struct t2 { unsigned int m; };
    int f(struct t1 * p1, struct t2 * p2)
    {
        if (p1->m > 0)
            p2->m = p2->m * 2;
        return p1->m;
    }

There is no common initial sequence but nevertheless many of the same issues apply. On the other hand, the correct way for a function such as f to protect itself against such aliasing is not to rely on the rule in 6.5.2.3#8, but rather to use the restrict qualifier.

I would suggest, therefore, that (2) is not a valid reason for the rule. As stated above, a corollary of this discussion is that the "union type must be visible" rule is useless.

Finally, one of the changes from C90 to C99 was to remove any restriction on accessing one member of a union when the last store was to a different one. The rationale was that the behaviour would then depend on the representations of the values. Since this point is often misunderstood, it might well be worth making it clear in the Standard.

Suggested Technical Corrigendum

To address point (1), in 6.5.2.3#8, second example, change the two structures to:

           struct t1 { double d; int m; };
            struct t2 { double d; int m; };

To address the wider point about visibility, change the first part of 6.5.2.3#5 to read:

[#5] One special guarantee is made in order to simplify the use of unions: if several structure types share a common initial sequence (see below), then corresponding members are required to lie at the same offset from the start of the union. Therefore if a union contains two or more such structures, the common initial part may be inspected using any of them, no matter which one was used to store the value.

To address issues about "similar" types raised in point (2) above, change the second part of #5 to read:

Two structures share a common initial sequence if corresponding members have matching types for a sequence of one or more initial members. Two types, in turn, are matching if they are

• compatible types (and, for bit-fields, the same widths)
• signed and unsigned versions of the same integer type
• qualified or unqualified versions of matching types, or
• pointers to matching types.

To address the issue about "type punning", attach a new footnote 78a to the words "named member" in 6.5.2.3#3:

78a If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning"). This might be a trap representation.

Note: all the above changes are independent of one another, depending on the committee's view of the issues.

Comment from WG14 on 2002-10-17:

Committee Response

The current rules are the result of extensive previous deliberations. The Committee does not see a defect here.

Committee Discussion

1. The Committee agrees, but does not believe that this is a defect in the Standard (or a substantive problem). There is some support for changing the example.
2. This takes away the "visibility rule" and the Committee does not want to do that; this is related to DR 236.
3. The Committee agrees, but does not believe a change is warranted at this time. This should be considered for a future revision of the Standard.
4. The Committee believes this is a separate issue, and should be a defect report (and possibly a new footnote). The defect report generated is DR 283, also see N980.

Issue 0258: ordering of "defined" and macro replacement

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Converted from: summary-c99.htm, dr_258.htm

Problem

Consider the code:

  #define repeat(x) x && x    // Line 1   #if repeat(defined fred)    // Line 2

and the code:

  #define forget(x) 0         // Line 3   #if forget(defined fred)    // Line 4

6.10.1#3 says:

[#3] Prior to evaluation, macro invocations in the list of preprocessing tokens that will become the controlling constant expression are replaced (except for those macro names modified by the defined unary operator), just as in normal text. If the token defined is generated as a result of this replacement process or use of the defined unary operator does not match one of the two specified forms prior to macro replacement, the behavior is undefined.

Does line 2 "generate" a defined operator ? Is line 4 strictly conforming code, or does the fact that macro expansion "forgets" the defined operator cause a problem ?

The restriction was clearly intended to make code like the following undefined:

   #define jim defined
    #if jim loves sheila

I would guess that the original intention was that any defined X pair in the original source worked correctly. The proposed change would resolve this.

In addition, given the order of events, it is unsuitable to say that a defined X expression is "evaluated". Rather it should be described as a textual substitution.

Suggested Technical Corrigendum

Change 6.10.1#1 to read:

[...]

     defined identifier

or

     defined ( identifier )

which are replaced by the token 1 if the identifier is currently
[...]
subject identifier), or the token 0 if it is not.

and #3 to read:

[#3] Prior to evaluation, the list of preprocessing tokens that will become the controlling constant expression is examined. Firstly all expressions using the defined operator are replaced as described above, and then macro invocations are replaced, just as in normal text. If the token defined appears in the list after the replacement process, or the use of the defined unary operator does not match one of the two specified forms prior to macro replacement, the behavior is undefined. After all [...]

Comment from WG14 on 2002-03-06:

Committee Response

The standard does not clearly specify what happens in this case, so portable programs should not use these sorts of constructs.

Issue 0259: macro invocations with no arguments

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Converted from: summary-c99.htm, dr_259.htm

Problem

Consider the code:

   #define m0()  replacement
    #define m1(x) begin x end
    m0() m1()

The number of arguments in a macro invocation is defined by 6.10.3#11:

[#11] The sequence of preprocessing tokens bounded by the outside-most matching parentheses forms the list of arguments for the function-like macro. The individual arguments within the list are separated by comma preprocessing tokens, but comma preprocessing tokens between matching inner parentheses do not separate arguments.

while 6.10.3#4 reads:

[#4] If the identifier-list in the macro definition does not end with an ellipsis, the number of arguments (including those arguments consisting of no preprocessing tokens) in an invocation of a function-like macro shall equal the number of parameters in the macro definition. Otherwise, there shall be more arguments in the invocation than there are parameters in the macro definition (excluding the ...). There shall exist a ) preprocessing token that terminates the invocation.

Now:

and in either case the requirement of 6.10.3#4 is violated.

This is clearly not the intent.

Suggested Technical Corrigendum

Append to 6.10.3#4:

If the invocation has no preprocessing tokens between the parentheses, this shall count as one argument unless the macro definition has neither an identifier list nor an ellipsis, in which case it shall count as no arguments.

Comment from WG14 on 2002-03-06:

Committee Response

The standard is clear enough, and no change is needed.

Issue 0260: indeterminate values and identical representations

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Cross-references: 0451
Converted from: summary-c99.htm, dr_260.htm

Problem

This is an intermingling of something that started out as two separate questions:

1. if an object holds an indeterminate value, can that value change other than by an explicit action of the program ?
2. if two objects hold identical representations derived from different sources, can they be used exchangeably ?

However, after much discussion the UK C Panel decided that they were better treated together. Both involve the concept of the "provenance" of a value.

Consider the code:

 char *p;
    unsigned char cp [sizeof p];
    p = malloc (SOME_VALUE);
    // Assume the allocation succeeds
    // Other code omitted that does not alter p.  memcpy (cp, &p, sizeof p);
    (free)(p); // Point X
               // ...
               // Point Y  if (memcmp (cp, &p, sizeof p))
              // ...

After the call to free the value of p is indeterminate. Is the implementation allowed, at this point (point X), to change this indeterminate value (presumably through compiler magic) so that the memcmp function sees a difference, or must the value remain constant ? Can it make the change later, between points X and Y ?

It is suggested that this is implied by 6.2.4#2:

An object [...] retains its last-stored value throughout its lifetime.

particularly if each byte of an object is also an object.

On the other hand, such a requirement would eliminate useful optimisation and debugging opportunities. (As an example of an optimisation, if p has been loaded into a register and then modified, it need not be written back to memory; as an example of a debugging opportunity, p could be set to a null pointer or to a detectable value).

[Note that where an object contains padding, 6.2.6.1#6 and #7 allows the value of padding bits and bytes to change whenever the object changes.]

If an implementation is allowed to change the value of p, then consider the code:

 char *p, *q, *r;
    p = malloc (SOME_VALUE);
    // Assume the allocation succeeds  q = p;
    r = p + 1;
    // Other code omitted that does not alter p, q, or r  (free)(p);
    // Point Z

Can it change the value of q or r at point Z ? What about later ?

Now consider the code:

 int *p, *q;
    p = malloc (sizeof (int)); assert (p != NULL);
    (free)(p);
    q = malloc (sizeof (int)); assert (q != NULL);
    if (memcmp (&p, &q, sizeof p) == 0)
    {
        // Assume this point is reached
        *p = 42;  // Line A

Is the assignment valid (because an assignment using *q would have been, and the two variables hold identical values) ? Or is it invalid because the last-stored value of p is now indeterminate (because of the free) ?

Similarly, consider the code:

 int x, y;
    int *p, *q;
    p = &x + 1;
    q = &y;
    if (memcmp (&p, &q, sizeof p) == 0)
    {
        // Assume this point is reached     *q = 42; p [-1] = 42;   // Line B     *p = 42; q [-1] = 42;   // Line C

The assignments on line B are clearly valid, but what about those on line C ? After all, p and q are identical, even in their hidden bits. What if we then add:

     int *r;
        remote_memcpy (&r, &p, sizeof p);   // See note      *r = 42;      // Line D      r [-1] = 42;  // Line E

(The function remote_memcpy is identical to memcpy, but it is done in another translation unit so that the compiler cannot associate special semantics with it.) Which, if either, of the assignments is allowed ?

Another example is the program:

 static int *p;
    void f (int n)
    {
        int sum = 0;
        int *q = &n;
        if (memcmp (&p, &q, sizeof p) == 0)
            for (int i = 0; i < n; i++)
                sum += i, p [i] = 0;
        p = &n;
    }
    int main (void)
    {
        int x;
        p = &x;
        f (1);
        f (6);
        return 0;
    }

On the first call to f the test is false. Therefore p is set to point to n. The value of p becomes indeterminate at the end of the call, but on most implementations this will have no effect. On the second call the test is true. Therefore the first time round the loop p [0], which is n, will be set to 0 and the loop will terminate.

However, most implementations would reasonably assume that n is not changed by anything in the loop and generate code accordingly. If the behaviour were undefined for some reason, such an implementation would be conforming. But is it strictly-conforming or is it undefined ?

Finally, note that we can generate a similar situation without giving the compiler any clue in advance:

 void f (int vec [], int n)
    {
        void *vp;
        int *p;
        printf ("%p or %p", (void *) vec, (void *) &n);    // Line Q      scanf ("%p", &vp); p = vp;
        for (int i = 0; i < n; i++)
            p [i] = 0;
    }

The user could ensure that p is set to either of the values printed. If a debugger is used, it isn't even necessary to retain line Q to determine the value to enter on stdin, and therefore the compiler has no warning that the address of n is being taken.

Resolution

After much discussion, the UK C Panel came to a number of conclusions as to what it would be desirable for the Standard to mean. These can be expressed as three requirements.

1. The implementation is entitled to take account of the provenance of a pointer value when determining what actions are and are not defined. Thus the assignments on lines A and C involve undefined behaviour. Similarly line D would be undefined and line E valid, though in practice a compiler would probably assume that p could point anywhere.
2. Where a pointer value becomes indeterminate because the object pointed to has reached the end of its lifetime, all objects whose effective type is a pointer and that point to the same object acquire an indeterminate value. Thus p at point X, and p, q, and r at point Z, can all change their value.
3. At any time that the compiler can determine that an object contains an indeterminate value, even if the type of the object does not have trap representations, the object may change value arbitrarily. Thus p need not have the same values at lines X and Y. As soon as the object is given an explicit value, this behaviour stops.

Suggested Technical Corrigendum

Change 3.17.2 to:

[#1] indeterminate value
a value which, at any given moment, could be either an unspecified value or a trap representation.

[#2] While an object holds an indeterminate value it is indeterminate. Successive reads from an object that is indeterminate might return different results. Storing a value in an object, other than an indeterminate value, means that the object is no longer indeterminate.

Change the last sentence of 6.2.4#2 from:

The value of a pointer becomes indeterminate when the object it points to reaches the end of its lifetime.

to:

When an object reaches the end of its lifetime, any object with an effective type that is a pointer type and that points to that object becomes indeterminate.

[Various uses of the word "indeterminate" could be tidied up, but this is the only one where the meaning needs to change.]

Add a new paragraph to 6.5.3.2:

[#5] The implementation is permitted to use the derivation of a pointer value in determining whether or not access through that pointer is undefined behaviour, even if the pointer compares equal to, or has the same representation as, a different pointer for which the access would be permitted. For example, if two objects with the same type have non-overlapping lifetimes and happened to occupy the same address, a pointer to one cannot be used to access the other.

[The * operator seems a reasonable place to put this. However, it could equally be elsewhere.]

Comment from WG14 on 2004-09-28:

Committee Discussion (for history only)

Result does not mean the same as value. This is undefined because 6.5.6#8 has a 'shall' in it. The bits have to stay the same. 6.4.2 applies.

A bit pattern + type does not imply a unique value. There can be more than one bit pattern that represents the same value. C only requires that an object with a determinate value retain that value during its lifetime unless a an explicit action (assignment, increment, decrement or through such functions as memcpy and memmove) change that value to another one or renders the value indeterminate.

An indeterminate value may be represented by any bit pattern. The C Standard lays down no requirement that two inspections of the bits representing a given value will observe the same bit-pattern only that the observed pattern on each occasion will be a valid representation of the value.

In addition the C Standard does not prohibit an implementation from tracking the provenance of the bit-pattern representing a value. An indeterminate value happening to have a bit pattern that is identical to a bit pattern representing a determinate value is not sufficient to allow access to the indeterminate value free from undefined behavior.

In reaching our response we noted that requiring immutable bit patterns for indeterminate values would reduce optimization opportunities. For example, it would require tracking of the actual bit-patterns of indeterminate values if the memory containing them were paged out. That seems an unnecessary constraint on optimizers with no compensatory benefit to programmers.

Committee Response

Question 1:

Values may have any bit-pattern that validly represents them and the implementation is free to move between alternate representations (for example, it may normalize pointers, floating-point representations etc.). In the case of an indeterminate value all bit-patterns are valid representations and the actual bit-pattern may change without direct action of the program.

Question 2:

If two objects have identical bit-pattern representations and their types are the same they may still compare as unequal (for example if one object has an indeterminate value) and if one is an indeterminate value attempting to read such an object invokes undefined behavior. Implementations are permitted to track the origins of a bit-pattern and treat those representing an indeterminate value as distinct from those representing a determined value. They may also treat pointers based on different origins as distinct even though they are bitwise identical.

Note that using assignment or bitwise copying via memcpy or memmove of a determinate value makes the destination acquire the same determinate value.

Issue 0261: constant expressions

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Converted from: summary-c99.htm, dr_261.htm

Problem

When is an expression a constant expression ?

Consider the code (at block scope):

 enum e1 { ex1 = INT_MAX + 1 };        // Line E1  enum e2 { ex2 = INT_MAX + (0, 1) };   // Line E2  char *p1 = (1 - 1);                   // Line P1  char *p2 = (42, 1 - 1);               // Line P2  short s1 = 42 + (0, 1);               // Line S1  p1 = (42, 1 - 1);                     // Line X1  s1 = (42, 69);                        // Line X2  p2 = 0;                               // Line X3  p2 = 1 - 1;                           // Line X4

On line E1 the syntax says that INT_MAX + 1 is a constant-expr. Therefore this is a constant expression, the requirements of 6.6 apply, and line E2 violates the constraint in 6.6#3.

On the remaining lines the syntax says that the code following the = sign is an assignment-expr; at no point in the parse does a constant-expr occur. So are these constant expressions ?

For line P1 to be legitimate, the expression (1 - 1) must be an integer constant expression (6.3.2.3#3). This implies that any expression comprised entirely of constants is an integer constant expression. So line P2 violates the constraint in 6.6#3 and, rather more worryingly, so does line S1.

If a generic initializer can be a constant expression, then, surely, so can any other expression. This means that lines X1 and X2 violate the constraint in 6.6#3. On the other hand, if they are not constant expressions, then the right hand sides on lines X3 and X4 do not include a null pointer constant; nor does line P1.

Consider also:

static int v = sizeof (int [(2, 2)]);

This is legitimate if, and only if, (2, 2) is a constant expression.

It would appear that the term "constant expression" actually has four subtly different meanings.

1. An object in the syntax. Where the syntax tree contains constant-expr the resulting code must meet the constraints and semantics of 6.6. An example is 6.7.2.2, where explicit values for enumeration constants must be constant-exprs.
2. A requirement on the program that a given construct must, in context, be a constant expression even though in other contexts the expression need not be constant. An example is 6.7.8#4: if the object has static storage duration, the initializer is subject to the constraints and semantics of 6.6, but if it has automatic storage duration there is no such requirement.
3. A requirement on the implementation that an entity must be a constant expression. For example, this applies to macros in standard headers. The implementation is not conforming if the definition does not meet the syntax, constraints, and semantic requirements of 6.6.
4. A test that distinguishes two cases. An example is 6.3.2.3#3, where a certain subset of integer expressions (those that are constant-exprs and have a value of 0) are also null pointer constants. It is not clear whether expressions that break the constraints or semantic requirements are erroneous or are simply not constant expressions.

The Standard needs to make clear when each of these four cases applies.

On further examination, cases (1) and (2) appear to always be obvious from the text of the Standard. Case (3) appears only to apply to macros defined in standard headers or predefined. Case (4) is harder to identify, but I believe that there are only two situations:

- null pointer constants;
- determining whether a type is variably modified.

Suggested Technical Corrigendum

Replace 6.6#2 with the following:

[#2] A constant expression is one which is evaluated during translation rather than runtime, usually because the precise value will affect the translation in some way.

[#2a] Where the implementation is required to provide a constant expression, that expression shall be one that, if included in the appropriate context, would meet the requirements of this subclause and whose evaluation would not involve undefined behaviour.

[#2b] An expression has a translation-time value if it meets the requirements of this subclause and evaluation would not involve undefined behaviour. If the expression fails to meet these requirements (for example, an integer expression includes a comma operator or a cast to a floating type), the expression does not have a translation-time value but nevertheless is not necessarily invalid.

Change 6.3.2.3#3 to begin:

[#3] An integer expression with the translation-time value 0, or such an expression cast to type void *, is called a null pointer constant.55)

Change 6.7.5.2#1 to read, in part:

[...] an integer type. If the expression has a translation-time value, it shall be greater than zero. The element type [...]

the last part of #4 to read:

If the size is an integer expression with a translation-time value and the element type has a known constant size, the array type is not a variable length array type; otherwise, the array type is a variable length array type.

#5 to begin:

[#5] If the size is an expression that does not have a translation-time value: if it occurs [...]

#6 to begin:

[#6] For two array types to be compatible, both shall have compatible element types, and if both size specifiers are present and have translation-time values, then both size specifiers shall have the same value.

and add a new example:

[#11] EXAMPLE 5: an expression that contains only constants but breaks one or more of the rules of 6.6 does not have a translation-time value. Therefore, in:

     int fla [5];       // not a VLA, "5" has a translation-time value      int vla [(0, 5)];  // VLA, 6.6 forbids comma operators

This can be used to force an array to have a constant size but still be variably modified.

Comment from WG14 on 2003-10-06:

Committee Discussion (for history only)
The semantics and grammar overlap.
The grammar says "this is an expression".
The semantics says "this is a constant expression"

Committee Response

The Committee agrees with your analysis of "constant expression" and the division into four categories.

We agree that line P1 is legitimate because "(1-1)" is a constant expression. Lines P2 and S1 do not include constant expressions because:

• they contain a comma operator (forbidden by 6.6#3)
• there is a valid interpretation of the code that uses a non-constant expression.

Line S1 is legitimate, while line P2 violates the constraints of 6.5.16.1#3 (the right hand side must either have pointer to character or pointer to void type, or must be a null pointer constant). Line X1 violates the same constraint for the same reason (this was also addressed in DR 064).

Line X2 is legitimate because there is no requirement for the right hand side to be a constant expression. Lines X3 and X4 are legitimate because the expressions are constant expressions with value 0 and therefore null pointer constants.

The Committee also agrees that:

    int fla [(0+5)];     // is a normal array, not variably modified
    int vla [(0,5)];     // is a variable length array

In general, the interpretation of an expression for constantness is context sensitive. For any expression which contains only constants:

• If the syntax or context only permits a constant expression, the constraints of 6.6#3 and 6.6#4 shall apply.
• Otherwise, if the expression meets the requirements of 6.6 (including any form accepted in accordance with 6.6#10), it is a constant expression.
• Otherwise it is not a constant expression.

In summary, provided the above points are taken account of, the Committee does not believe the Standard is ambiguous nor that it is necessary to modify it to make this clearer.

Issue 0262: maximum size of bit fields

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC2
Cross-references: 0335
Converted from: summary-c99.htm, dr_262.htm

Problem

6.7.2.1#3 reads, in part:

[#3] The expression that specifies the width of a bit-field shall be an integer constant expression that has nonnegative value that shall not exceed the number of bits in an object of the type that is specified if the colon and expression are omitted.

Is "the number of bits of the type ..." the width or is it the number of bits in the object representation ?

Since it might not be practical to make use of padding bits in such an object, the former would be more sensible.

Suggested Technical Corrigendum

Change the cited text to read:

[#3] The expression that specifies the width of a bit-field shall be an integer constant expression that has nonnegative value that shall not exceed the width of an object of the type that is specified if the colon and expression are omitted.

(bold type shows the changed words)

Comment from WG14 on 2002-03-07:

Technical Corrigendum

Change 6.7.2.1#3 to read:

The expression that specifies the width of a bit-field shall be an integer constant expression that has nonnegative value that shall not exceed the width of an object of the type that is specified if the colon and expression are omitted.

Issue 0263: all-zero bits representations

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_263.htm

Problem

Consider the code:

   int v [10];
    memset (v, 0, sizeof v);

Most programmers would expect this code to set all the elements of v to zero. However, the code is actually undefined: it is possible for int to have a representation in which all-bits-zero is a trap representation (for example, if there is an odd-parity bit in the value).

Consider also:

   int *p;
    p = calloc (n_members, sizeof (int));

This problem applies to all integer types except for unsigned char. I believe that the idiom is well-enough known that it should be made a part of the Standard.

Suggested Technical Corrigendum

Append to 6.2.6.2#5:

For any integer type, the object representation where all the bits are zero shall be a representation of the value zero in that type.

Comment from WG14 on 2002-03-07:

Technical Corrigendum

Append to 6.2.6.2#5:

For any integer type, the object representation where all the bits are zero shall be a representation of the value zero in that type.

Issue 0264: graphic characters

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Converted from: summary-c99.htm, dr_264.htm

Problem

The Standard uses the terms "printing character", "graphic character", and "nongraphic character". The first is discussed in 5.2.2#1 and defined formally in 7.4#3:

[#3] The term printing character refers to a member of a locale-specific set of characters, each of which occupies one printing position on a display device;

A "nongraphic character" is clearly a character which is not a graphic character, but "graphic character" is nowhere defined. It is used only in 5.2.1#3, which requires "the following 29 graphic characters" to be part of the basic character sets, while "nongraphic character" is used in 5.2.2#2 and 6.4.4.4#8 when discussing the \a \b \f \n \r \t and \v escape sequences.

The key questions are:

1. Are the 29 enumerated graphic characters required to be printing characters ?
2. Are isalnum() and isspace() required to be false for them ?
3. Is ispunct() required to be true for them ?

In addition, given that the seven characters corresponding to the escape sequences above are required to be control characters (see 5.2.1#3):

4. Should "nongraphic character" be replaced by "control character" ?

I believe that the answers should be:

1. yes
2. yes;
3. yes in the C locale, but not otherwise;
4. yes.

However, it is not clear that these answers can be derived from the Standard (though if (1) and (2) are "yes", (3) must at least be "yes in the C locale").

Suggested Technical Corrigendum

To address (1): in 5.2.1#3, replace "29 graphic characters" with "29 printing characters".

To address (4): in 5.2.2#2 and 6.4.4.4#8 replace "nongraphic" with "control".

To address (2): append to 5.2.1#4:

A graphical mark character is one of the 29 other printing characters listed above.

in 7.4.1.2#2, insert between the two sentences:

The isalpha function returns false for all graphical mark characters.

and in 7.4.1.10#2, change "characters for which" to "characters which are not graphical mark characters and for which".

Given the above changes, (3) can be derived from the modified Standard.

Comment from WG14 on 2002-03-07:

Committee Response

The referenced sections in the standard only use the term "non-graphic character" in the context of backslash-escape sequences, for which the standard is clear enough, and no changes are needed.

Issue 0265: preprocessor arithmetic

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_265.htm

Problem

Assume that both compile-time and run-time arithmetic have 2's complement, no trap representations, 8/16/32/48/64 bit integer types. Consider the code:

  #if -0xFFFFFFFF < 0

Is this expression true or false ? 6.10.1#3 reads, in part:

and then each preprocessing token is converted into a token. The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6, except that all signed integer types and all unsigned integer types act as if they have the same representation as, respectively, the types intmax_t and uintmax_t defined in the header <stdint.h>.

Does the "except" wording apply to the conversion to a token, or only to the evaluation of the expression ? If the former, then 0xFFFFFFFF can be represented in an int (intmax_t), it has a signed type, and the expression is true. If the latter, 0xFFFFFFFF cannot be represented in an int but can be represented in an unsigned int, so it has unsigned type and the expression is false.

I believe that the former was intended, with the preprocessor only having to consider one pair of integer types.

Suggested Technical Corrigendum

Change the cited text to:

and then each preprocessing token is converted into a token. The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6. For the purposes of the conversion and evaluation all signed integer types and all unsigned integer types act as if they have the same representation as, respectively, the types intmax_t and uintmax_t defined in the header <stdint.h>.

(bold type shows the changed words)

Add a footnote reference to the end of this text, and add the footnote:

140a Thus on an implementation where INT_MAX is 0x7FFF and UINT_MAX is 0xFFFF, the constant 0x8000 is signed within a #if expression even though it is unsigned in translation phase 7.

Comment from WG14 on 2002-05-15:

Technical Corrigendum

Change 6.10.1#3 to read:

...

and then each preprocessing token is converted into a token. The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6. For the purposes of this token conversion and evaluation all signed integer types and all unsigned integer types act as if they have the same representation as, respectively, the types intmax_t and uintmax_t defined in the header <stdint.h>.

Add a footnote to the end of 6.10.1#3 to read:

Thus on an implementation where INT_MAX is 0x7FFF and UINT_MAX is 0xFFFF, the constant 0x8000 is signed and positive within a #if expression even though it is unsigned in translation phase 7.

Issue 0266: overflow of sizeof

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Converted from: summary-c99.htm, dr_266.htm

Problem

Consider the following code:

  char x [SIZE_MAX / 2][SIZE_MAX / 2];
    size_t s = sizeof x;

The size of x cannot be fitted into an object of type size_t. Assuming that SIZE_MAX is 65535, what is the value of s ? More generally, which of the following is, or should be, the case ?

1. The value is reduced modulo (SIZE_MAX + 1).
2. The behaviour is undefined (or perhaps implementation-defined).
3. The program is forbidden to use sizeof with such a large argument.
4. The implementation must ensure that no object can be larger than SIZE_MAX bytes.

6.5.3.4#2 says in part:

[#2] The sizeof operator yields the size (in bytes) of its operand, which may be an expression or the parenthesized name of a type. The size is determined from the type of the operand. The result is an integer.

Note that there is no indication that the result may be other than the correct size.

Suggested Technical Corrigendum

One of:

1. Append to 6.5.3.4#4:

   If the size is too large to fit in an object of type size_t, it is converted to that type in the manner described in subclause 6.3.1.3.

2. Append to 6.5.3.4#4:

   If the size is too large to fit in an object of type size_t, it is replaced by an implementation-defined value.

3. Add a new constraint paragraph after 6.5.3.4#1:

   [#1a] The sizeof operator shall not be applied to an operand whose size, in bytes, is larger than the maximum value of the type size_t.

4. Append to 6.5.3.4#4:

   The implementation shall ensure that the type size_t is large enough to hold the result of all uses of the sizeof operator.

[Some of these are less than wonderful, and consideration should also be given to the interaction with VLAs.]

Comment from WG14 on 2004-03-06:

Committee Discussion

The committee has deliberated and decided that more than one interpretation is reasonable. Translation limits do not apply to objects whose size is determined at runtime.

sizeof(a[SIZE_MAX/2][SIZE_MAX/2]);

The program is not strictly conforming because it exceeds an environmental limit.
If the implementation generates code, there is no requirement for a diagnostic. In the event that sizeof is called on the object, a diagnostic should be issued, but not required.
VLAs are a special case.

Committee Response

The program is not strictly conforming because it exceeds an environmental limit. If the implementation generates code, there is no requirement for a diagnostic. In the event that sizeof is called on the object, a diagnostic can be issued, but is not required.

Issue 0267: Typos in 5.1.2.3, 7.24.4.4.5, 7.24.6.1, 7.24.6.1

Authors: WG14 Convener (J. Benito)
Date: 2001-09-21
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_267.htm

Summary

1. 5.1.2.3p12, example 4, expressions should be expression.
2. 7.24.4.4.5p1 * s1 and * s2 should not have spaces following the *s.
3. 7.24.6.1.1p3 "The btowc returns" should read "The btowc function returns".
4. 7.24.6.1.2p3 "The wctob returns" should read "The wctob function returns".

Suggested Technical Corrigendum

1. In 5.1.2.3, paragraph #12 change last line of code fragment expressions to expression.

2. In 7.24.4.4.5, paragraph #1 remove the space following the * for s1 and s2.

3. In 7.24.6.1.1, paragraph #3 change:

   "The btowc returns"

   to

   "The btowc function returns"

4. In 7.24.6.1.2, paragraph #3 change:

   "The wctob returns"

   to

   The wctob function returns"

Comment from WG14 on 2003-10-06:

Technical Corrigendum

1. In 5.1.2.3, paragraph #12 change expressions to expression in last line of code fragment.

2. In 7.24.4.4.5, paragraph #1 remove the space following the * for s1 and s2.

3. In 7.24.6.1.1, paragraph #3 change:

   "The btowc returns"

   to

   "The btowc function returns"

4. In 7.24.6.1.2, paragraph #3 change:

   "The wctob returns"

   to

   The wctob function returns"

Issue 0268: jumps into iteration statements

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC3
Converted from: summary-c99.htm, dr_268.htm

Problem

Consider the code:

int x = 0;
    goto centre;
    while (++x < 10)
    {
        // Some code centre:
        // More code }

"Everyone knows" that, when the end of the block is reached, the loop test is evaluated in the normal way. Nevertheless, I can find nothing in the Standard that says so (it is implied by the example in 6.8.6.1#3, but that is all). Note that in:

int x;
    // ... if (condition) { x = -1; goto true_case; }
    // ... if (x > 0)
      true_case:
        do_something ();
    else
        do_something_else ();

the else case is not executed after a jump to true_case, even though the condition x > 0 is false. Therefore it is not possible to argue from analogy; note also that this latter case is spelled out in the Standard. Since this technique is well-known, it ought to be well-defined.

Suggested Technical Corrigendum

Add a new paragraph after 6.8.5#4:

[#4a] If the loop body is reached by a jump from outside the iteration statement, the behavior is as if the body were entered in the normal way. That is, when the end of the body is reached the controlling expression is evaluated (and, in the case of a for statement, expr-3 is evaluated first) and the body re-executed if it is not 0. Similarly, a break or continue statement has the appropriate effect. However, the code jumped over - including the controlling expressions in the case of a while or for statement - is not evaluated when the jump happens.

Possibly also add an example either as 6.8.5#6 or 6.8.6.1#5 (with appropriate editorial changes):

[#6] EXAMPLE: A jump into a for statement does not execute clause-1 at all or expr-2 during the jump:

  int i = 5;
        if (condition) goto body;
        for (i = 0; i < 10; i++)
        {
            if (i > 2) i++;
        body:
            printf (" %d", i);
        }
        printf ("\n");

If condition is true, this prints:

  5 7 9

while if it is false it prints:

  0 1 2 4 6 8 10

Comment from WG14 on 2006-03-29:

Committee Discussion

While we agree that this may be a defect, we are not happy with the proposed words, and processing this defect is postponed pending improved wording. Specifically, "as if the body were entered in the normal way" raises a few new questions.

Technical Corrigendum

Append to 6.8.5#4:

The repetition occurs regardless of whether the loop body is entered from the iteration statement or by a jump.^*

^* Code jumped over is not executed. In particular, the controlling expression of a for or while statement is not evaluated before entering the loop body, nor is clause-1 of a for statement.

Issue 0269: lacunae in exact-width integer types

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_269.htm

Problem 7.18.1.1 reads:

[#1] The typedef name intN_t designates a signed integer type with width N, no padding bits, and a two's complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits.

[#2] The typedef name uintN_t designates an unsigned integer type with width N. Thus, uint24_t denotes an unsigned integer type with a width of exactly 24 bits.

[#3] These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, it shall define the corresponding typedef names.

The requirements for no padding bits and two's complement were added at a late stage, and the implications to the text weren't fully thought through. In particular:

• the second sentence of #1 is inconsistent with the first;
• the unsigned types should also have the "no padding bits" requirement (it can be derived from the requirement to provide both or neither of these types and the requirement that they have the same size, but it ought to be spelled out);
• the requirements in #3 aren't the same as those in #1, so an implementation can't have 8 bit types with padding bits or a sign-and-magnitude representation.

Suggested Technical Corrigendum

Change this section to read:

[#1] The typedef name intN_t designates a signed integer type with width N, no padding bits, and a two's complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits and those other properties.

[#2] The typedef name uintN_t designates an unsigned integer type with width N and no padding bits. Thus, uint24_t denotes an unsigned integer type with a width of exactly 24 bits and no padding bits.

[#3] These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two's complement representation, it shall define the corresponding typedef names.

Or, alternatively:

[#3] These types are optional. However, if an implementation has a type with width 8, 16, 32, or 64 bits that meet the above requirements, it shall define the corresponding typedef names.

Comment from WG14 on 2002-05-15:

Committee Response

The first bullet point is false; while the second sentence is not a complete specification, it does not contradict the first sentence.

Technical Corrigendum

Change 7.18.1.1#3 to read:

These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two's complement representation, it shall define the corresponding typedef names.

Committee Discussion

The Committee believes that suggestion 2 (about unsigned types) should be considered for a future revision of the Standard.

Issue 0270: wint_t is not the promoted version of wchar_t

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_270.htm

Problem

In the fprintf conversion specifier "%lc", the corresponding argument is of type wint_t, but is then treated as if it contained a wchar_t value. In 7.19.6.1#18, the last call is:

  fprintf(stdout, "|%13lc|\n", wstr[5]);

This argument has the type wchar_t.

There is no requirement in the Standard that the default argument promotions convert wchar_t to wint_t. Therefore this example exhibits undefined behaviour on some implementations. Nonetheless, the code looks like it ought to work, and WG14 should consider changing the definition of wint_t to force it.

The current definition of wint_t is in 7.24.1#2:

wint_t

which is an integer type unchanged by default argument promotions that can hold any value corresponding to members of the extended character set, as well as at least one value that does not correspond to any member of the extended character set (see WEOF below);²⁶⁹⁾ and

²⁶⁹wchar_t and wint_t can be the same integer type.

Three possible solutions are:

1. Fix the example.
2. Change the definition of wint_t to be the promoted version of wchar_t.
3. Change the definition of %lc to take promoted wchar_t rather than wint_t.

Suggested Technical Corrigendum 1

Change the quoted line of 7.19.6.1#18 to:

  fprintf(stdout, "|%13lc|\n", (wint_t) wstr[5]);

Suggested Technical Corrigendum 2

Change the cited portion of 7.24.1#2 to:

wint_t which is the integer type resulting when the default argument promotions are applied to the type wchar_t;269) and

Suggested Technical Corrigendum 3

[Italics are used to show the changed text.]

Change 7.19.6.1#7 and 7.24.2.1#7, l modifier, to:

l (ell)

Specifies that a following d, i, o, u, x, or X conversion specifier applies to a long int or unsigned long int argument; that a following n conversion specifier applies to a pointer to a long int argument; that a following c conversion specifier applies to an argument whose type is that resulting when the default argument conversions are applied to the type wchar_t; that a following s conversion specifier applies to a pointer to a wchar_t argument; or has no effect on a following a, A, e, E, f, F, g, or G conversion specifier.

Change 7.19.6.1#8, c specifier, second paragraph, to:

If an l length modifier is present*, the argument - whose type is that resulting when the default argument conversions are applied to the type wchar_t* - is converted as if by an ls conversion specification with no precision and an argument that points to the initial element of a two-element array of wchar_t, the first element containing the argument to the lc conversion specification and the second a null wide character.

Change 7.24.2.1#8, c specifier, second paragraph, to:

If an l length modifier is present, the argument is converted to wchar_t and written.

Comment from WG14 on 2002-03-07:

Technical Corrigendum

Change the quoted line of 7.19.6.1#18 to:

  fprintf(stdout, "|%13lc|\n", (wint_t) wstr[5]);

Issue 0271: lacuna in iswctype and towctrans

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Closed
Converted from: summary-c99.htm, dr_271.htm

Problem

Consider the calls:

   iswctype (c, wctype (property))
    towctrans (c, wctrans (property))

where property is not valid in the current locale. The wctype and wctrans functions return zero, but the behaviour of iswctype and towctrans is not specified.

I believe it would be useful - and considered natural - for them to return 0 ("c does not have this property") and c ("c is unaffected by this mapping") respectively.

Suggested Technical Corrigendum

Append to 7.25.2.2.1#4:

If desc is zero, the iswctype function returns zero (false).

Append to 7.25.3.2.1#4:

If desc is zero, the towctrans function returns the value of wc.

Comment from WG14 on 2002-05-15:

Committee Response

Since no behavior is specified when desc is zero, for either iswctype() or towctrans(), the behavior is undefined. We do not believe it would be appropriate to add new requirements here.

Committee Discussion

The Committee believes this should be considered for a future revision of the Standard.

Issue 0272: type category

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_272.htm

Problem

The concept of "type category" is defined but is never used in a useful way; it is also used inconsistently. The term and its cognates appear in only six places:

Note how the use in footnote 93 conflicts with that in #25, and that the use in footnote 137 remains less than clear.

Having an unnecessary term defined leaves the reader confused to no benefit. The term should be removed and the remaining wording changed.

Even if the other changes described here are foregone, footnote 93 is in error and should be changed.

Suggested Technical Corrigendum

Delete 6.2.5#24.

In 6.2.5#25, delete "belong to the same type category and".

In 6.2.5#27, change "Its type category is pointer" to "It is a pointer type".

In 6.2.5#28, change "Its type category is array" to "It is an array type".

In footnote 93 change "which removes any type qualifiers from the type category of the expression" to "which removes any type qualifiers from the outermost component of the type of the expression (for example, it removes const but not volatile from the type int volatile *const)".

In footnote 137 change the first part to:

The intent is that the fact that the identifier designates a function is shown explicitly and cannot be inherited from a typedef:

leaving the examples unchanged.

Comment from WG14 on 2003-10-06:

Committee Discussion (for history only)

The committee wishes to keep the term "type category" for now, removing the term "type category" from the next revision of the standard should be considered at that time. The text of footnote 93 does use the term incorrectly, but the wording can be changed to use the term correctly - and the parenthetical example provided in the DR can also be incorporated to make the intent even clearer.

Technical Corrigendum

Change footnote 93.

"...which removes any type qualifiers that were applied to the type category of the expression (for example, it removes const but not volatile from the type int volatile * const)."

Issue 0273: meaning of __STDC_ISO_10646__

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_273.htm

Problem

6.10.8 reads in part:

__STDC_ISO_10646__

An integer constant of the form yyyymmL (for example, 199712L), intended to indicate that values of type wchar_t are the coded representations of the characters defined by ISO/IEC 10646, along with all amendments and technical corrigenda as of the specified year and month.

Firstly, this wording is less than optimal, in that it could be read as making an implementation non-conforming if wchar_t has a value that does not correspond to an ISO 10646 (Unicode) character. Since Unicode has gaps in the encoding tables, this would mean that no implementation could define this symbol.

Secondly, is this wording meant to put a lower bound on the size of wchar_t, or does the (wchar_t = = Unicode) mapping only apply to those values that wchar_t can take. In other words, if a given version of Unicode defines characters up to U+12345, can WCHAR_MAX be less than 0x12345 on a system that defines this symbol ?

Suggested Technical Corrigendum

Replace the cited text by:

__STDC_ISO_10646__

An integer constant of the form yyyymmL (for example, 199712L). If this symbol is defined, then every character in the "Unicode required set", when stored in an object of type wchar_t, has the same value as the short identifier of that character.

and then either:

The "Unicode required set" consists of all the characters that are defined by ISO/IEC 10646, along with all amendments and technical corrigenda, as of the specified year and month.

if the intent is to put a minimum on the value of WCHAR_MAX, or then:

The "Unicode required set" consists of all the characters that:

• are defined by ISO/IEC 10646, along with all amendments and technical corrigenda, as of the specified year and month; and
• have short identifiers that lie within the range of values that can be represented by the type wchar_t.

Comment from WG14 on 2002-03-07:

Technical Corrigendum

Replace the relevant part of 6.10.8 with:

__STDC_ISO_10646__

An integer constant of the form yyyymmL (for example, 199712L). If this symbol is defined, then every character in the "Unicode required set", when stored in an object of type wchar_t, has the same value as the short identifier of that character. The "Unicode required set" consists of all the characters that are defined by ISO/IEC 10646, along with all amendments and technical corrigenda, as of the specified year and month.

Issue 0274: meaning of "character" in <string,h> functions

Authors: Clive D.W. Feather <clive@demon.net>, UK C Panel
Date: 2001-09-07
Status: Fixed
Fixed in: C99 TC2
Converted from: summary-c99.htm, dr_274.htm

Problem

7.21.2.1#2 defines the operation of memcpy as:

[#2] The memcpy function copies n characters from the object pointed to by s2 into the object pointed to by s1.

7.21.2.3#2 defines the operation of strcpy as:

[#2] The strcpy function copies the string pointed to by s2 (including the terminating null character) into the array pointed to by s1.

Other functions in 7.21 refer to either a string or a set of characters in the same way. The definition of "string" is in 7.1.1#1:

[#1] A string is a contiguous sequence of characters terminated by and including the first null character.

and that of "character" is in 3.7:

3.7 [#1] character
<abstract> member of a set of elements used for the organization, control, or representation of data

3.7.1 [#1] character single-byte character
<C> bit representation that fits in a byte