Only reserve names of optional functions if necessary

Revision history

Introduction

C23 in its current form adds a large number of functions (in the order of some hundred) for decimal floating point types (DFP) or binary floating points (BFP) without following any naming scheme that the standard established. This is particularly disturbing, because as of now external names are reserved regardles if the corresponding header is included.

By that, currently valid programs for C17 may become invalid even if they don’t use the decimal or binary floating point options. Even worse, because this implies linking (and thus for example link order) violations of the use of the names of these functions could go undetected for a long time and even result in programs with undefined behavior.

Generally, we have now several sets of external identifiers that are optional, but for which the names are nevertheless reserved. In view of the recent progress for C23 to distinguish potentially reserved identifiers from that set, it seems in order relax our constraints when either the implementation does not implement the option, or when the program doesn’t use it at all. We identified the following sets of external identifiers that are optional:

• All the functions with complex parameters, <complex.h>
• All the functions with decimal floating point arguments, <fenv.h>,<math.h> and <stdlib.h>
• All the functions of the atomics option, <stdatomic.h>
• All the functions of the threads option, <threads.h>
• All the functions using the binary floating point optional types, Annex F

Similar to the additions in Annex K, we propose to break this monolithicity of the C library, and to only reserve those identifiers if a programs actively refers to at least one of these sets. We primarily propose wording for complex, DFP and BFP functions, in their main headers since these follow no naming scheme of the standard, and for Annex K since it already follows such a scheme. Optionally WG14 could also take the same approach for atomics and for threads.

When discussing this paper on the WG14 reflector, some found that the proposal was not sufficiently constraining programs. In particular, it was asked to prohibit the redeclaration of identifiers with linkage in block scope, unless all declarations of that identifier (whence they have linkage) were compatible. We think that this goes beyond what this paper wants to achieve, but nevertheless we include two such possible changes as optional, below.

Changes

Addition to the end of 6.10.8.3 (Conditional feature test macros)

NOTE

3 Some of these macros also define groups of optional identifiers with external linkage, see 7.1.3.

Change in 7.1.3 (Reserved identifiers) p1

Remove the third bullet point. The footnote ²⁰⁰⁾ is attached to the following new paragraph.

• All identifiers with external linkage in any of the following subclauses (including the future library directions) and errno are always reserved for use as identifiers with external linkage.²⁰⁰⁾

Add to the end of 7.1.3 (Reserved identifiers)

2 Additionally, for a hosted implementation all identifiers with external linkage in any of the following subclauses, including the future library directions and (if applicable) in Annex F and K, that do not fall under an exception as follows and errno are always reserved for use as identifiers with external linkage.²⁰⁰⁾ Excepted are identifiers that are marked as being optional by depending on one the conditional feature test macros (6.10.8.3)

__STDC_NO_COMPLEX__ __STDC_IEC_60559_DFP__ __STDC_IEC_60559_BFP__  __STDC_LIB_EXT1__

Identifiers that depend on the same conditional feature test macro form a seperate group; for each group all identifiers are reserved if any of them is used to refer to the external definition as specified in this document and none of them is reserved if none of them is such used.^FNT0)

^FNT0) See Annex B for lists of declarations of these identifiers.

3 For freestanding implementations, identifiers with external linkage are reserved as specified in Clause 4.

Change in 7.25 (Type-generic math <tgmath.h>) p2

3 This clause specifies a many-to-one correspondence of functions in <math.h> and <complex.h> with type-generic macros.³³⁸⁾ Use of a type-generic macro invokes a corresponding function whose type is determined by the types of the arguments for particular parameters called the generic parameters.³³⁹⁾ An implicit use of such a function through the corresponding type-generic macro constitutes a usage of the external name as if explicit.

Change in K.3.1.2 (Reserved identifiers)

1 Each macro name in any of the following subclauses is reserved for use as specified if it is defined by any of its associated headers when included; unless explicitly stated otherwise (see 7.1.4).^FNT1)

2^FNT1) All identifiers with external linkage in any of the following subclauses are reserved for use as identifiers with external linkage if any of them are used by the program. None of them are reserved if none of them are used as one group as specified in 7.1.3.

32 Each identifier with file scope listed in any of the following subclauses is reserved for use as a macro name and as an identifier with file scope in the same name space if it is defined by any of its associated headers when included.

Optional addition to 6.2.2 p7 (Linkage of identifiers)

7 If, within a translation unit, the same identifier appears with both internal and external linkage or with linkage but incompatible types, the behavior is undefined.

Optional addition to the end of 6.2.2 (Linkage of identifiers)

Recommended Practice

8 If a translation unit provides incompatible declarations with linkage for the same identifier, a diagnostic is recommended.

Optional addition to the end of 7.1.3 (Reserved identifiers)

4 A translation unit that includes a header of this clause shall not provide an incompatible declaration with linkage for any identifier that is declared in that header.

Impact

These changes do not invalidate user code. They maintain validity of user code written for C17 and that does not use decimal or binary floating point options, even if they coincidentaly define identifiers of the incriminated sets as external symbols.

Implemenations that start to offer the decimal floating point option or the binary floating point option of Annex F, have to ensure that they protect user code that does not use these options from naming clashes for these symbols. This can be achieved for example by shipping these options as separate library objects or by definining the symbols as “weak”.

Questions for WG14

1. Shall we integrate Changes 3.1 to 3.5 into C23?

2. Shall we add __STDC_NO_ATOMICS__ to the list of feature test macros in the new paragraph 7.1.3 p2?

3. Shall we add __STDC_NO_THREADS__ to the list of feature test macros in the new paragraph 7.1.3 p2?

4. Shall we integrate Change 3.6 (interdiction of incompatible declaratations) into C23?

5. Shall we integrate Change 3.7 (recommended practice) into C23?

6. Shall we integrate Change 3.8 (C library restriction) into C23?

Note to the editors

The formulation for the WANT macros in Annex F is quite strange. It refers to several such macros where there actually is only one.

Acknowledgement

Thanks go to Joseph Myers for prompt feedback on the initial version of this paper.