WG 14 Standing Document 3
Partial list of proposals not covered by DRs for C11
|Doc No:||WG 14 N 2182|
|Reply To:||David Keaton|
|Convener, WG 14
848 N. Rainbow Blvd. #4499
Las Vegas, NV 89107
|Phone:||+1 702 518 8192|
|Fax:||+1 702 852 0248|
This document contains a partial list of proposals that could not be dealt with by a C11 Defect Report. Most originated as potential Defect Reports but could not be handled via that process. Each should be reviewed when the time comes to start the process to republish the C Standard.
Except where noted, this document is not intended to indicate the direction WG 14 will take for the development of the C Standard. This is just a list of proposals that were not addressed by the WG 14 Defect Report process. It is also not meant to be a complete list of items to be considered for the next revision of the C standard.
To do as suggested in this defect report, distinguish whether the
long doubletypes are IEC compliant or not, requires the addition of new feature test macros. This is a new feature, and is not allowed by the mechanism of the defect report process.
This is a request to align C with C++14, C++14 has defined the shifting of a bit into the sign bit, again this is a feature that can not be addressed by the defect report process. The following change was proposed in the defect report.6.5.7p4 should be modified to read:The result of
E1 << E2is
E2bit positions; vacated bits are filled with zeros. If
E1has an unsigned type, the value of the result is
E1 x 2E2, reduced modulo one more than the maximum value representable in the result type. If
E1has a signed type and nonnegative value, and
E1 x 2E2is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.
The issue about indeterminate values (wobbly bits) will possibly need to be clarified. Wobbly bits were not considered during the development of C11.
The portion of this defect report that requests allowing
constqualified objects in signal handlers is considered a new feature. The implications of the following suggested change from the defect report should be studied carefully before adopting any change.
In section 220.127.116.11, modify the first sentence of paragraph 5 as indicated below:If the signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler
refers toany object with static or thread storage duration that is not a lock-free atomic object other than by...
In addition, make the corresponding change to section J.2 Undefined behavior.
This defect report requests a local change to a globally-used term. A comprehensive review of all uses would be required, which is outside the scope of this defect report.
This defect report requests a harmonization with C++, which is often grounds for making a change. However, this particular change would invalidate existing code and should not be done using the defect report process. The following change was proposed in the defect report.
Align the C rules with those of C++ by adding a new paragraph to section 6.2.1 Scopes of identifiers as follows.
This proposal for integer width macros should be considered for adoption with the caveat that the widths suggested for 18.104.22.168 should be equal to N, not <= N.
This proposal requests a new feature,
_Alignofon incomplete array types, for harmonization with C++.
The committee decided that the preprocessor behavior addressed in this document should be considered for potential unspecified behavior, rather than undefined behavior as suggested in the document.
This is a proposal for a new feature, allowing qualified doubly-dimensioned array parameters to be compatible with unqualified arguments.
New feature request: consider adding to the standard the macros
LDBL_TRUE_MAXfrom this DR.
TR 24731-1, which eventually became Annex K, was written before threads existed in the C language. Then Annex K and threads were separately added to the C standard. Their effects on each other were overlooked, leading to runtime constraint handlers not integrating well with threads. This urgently needs to be addressed, and requires changes beyond what a technical corrigendum can do.
Feature removal request: consider removing from the standard the ability for macro invocations to span an include file boundary.
New feature request: consider allowing the programmer to specify the type used to represent an enum.
New feature request: consider adding a mechanism to prevent trailing commas in the expansion of variadic macros.
Track what C++ does with this issue (WG 21 P0306R0).
New feature request: consider adding parallelism TS 21938-1 into the C standard.
New feature request: consider changing the definition of out-of-bounds store in Annex L.
New feature request: consider adding attributes to C.
New feature request: consider adding a constraint to make
[static n]declarations of the same array parameter match.
Add floating-point TS 18661 parts 1 and 2 into the C standard. The committee has decided to pursue this for C2x.
New feature request: consider allowing a structure with a flexible array member to be nested inside another structure.
Technical change request: consider changing the specification of unspecified values, pointer provenance, and trap representations.
Technical change request: consider changing the specification of the number of fractional digits in
printf %aoutput. The committee prefers an option that is similar to #3 in the paper, or that goes beyond the first two options.
New feature request: consider adding the C++
__has_includefeature to C.
Consider adding the following floating-point items to the C standard. Committee deliberations revealed a medium level of committment to pursue these (more committed than most items, though less committed than TS 18661 parts 1 and 2, which are already decided).
- TS 18661-3 - entire part
- TS 18661-4 - mathematical functions
- TS 18661-4 - reduction functions
- TS 18661-5 - evaluation format pragmas
- TS 18661-5 - optimization control pragmas
- TS 18661-5 - reproducible results
- TS 18661-5 - rounding direction macro
Consider adding something along the lines of TS 18661-5 - alternate exception handling pragma to the C standard. The committee may be interested in the general idea but is not sure of the specifics.
Consider whether the following C++ changes should be made in C. Note that these items need proposals submitted as WG 14 papers to progress further.
- Drop trigraphs (C++17)
- Add u8'x' literals (C++17)