I am a member of the UK C panel (BSI IST/5/-/14), which deals in the UK with issues associated with the development of the C standard (ISO/IEC 9899) and submits Defect Reports relating to it to WG14.
I have some pre-DRs (discussions of issues in ISO 9899 that might or might not be defects) for consideration for possible future Defect Reports. They will not necessarily become DRs; that depends on the outcome of consideration of whether they do represent defects. Some of the pre-DRs discuss multiple related issues, of which some may be defects and some not. Some of the pre-DRs which were here have been revised and split into multiple separate issues; to avoid confusion, the original pre-DRs remain available unchanged at their original URLs, although not linked to, in addition to the new versions. Those pre-DRs which have been submitted as DRs and published as WG14 documents are also no longer linked to here.
I also have a discussion of issues with constant expressions (not in the form of the pre-DRs above; parts may become DRs following implementation experience).
I have submitted DRs 311, 312, 313, 314, 315, 316, 317, 339, 340, 341, 342, 343.
Several previous DRs (248, 249, 251, 265, 270, 277, 278), written by Clive Feather, relate to problems I found in the C standard, as does 318, written by Fred Tydeman.
Constant expressions (C90 subclause 6.4, C99 subclause 6.6) are one of the more obscure areas of the C standards that hitherto GCC has not made a serious attempt to implement properly. The standards are also unclear in this area; see my discussion of issues with constant expressions mentioned above (which specifically deals with C99 as the current standard, but much the same problems arise with C90, apart from those depending on VLAs).
The following discussions present models of the constant expression rules in terms of synthesised attributes of syntax productions, for C90, C99 and GNU C. Because the standard is in places unclear, they do not describe a unique possible interpretation, but they are intended to describe plausible interpretations that are suitable for implementation in GCC. These models may be affected by the resolution of any DRs filed relating to the problems with constant expressions.
The GNU C model only roughly approximates what is currently accepted, tending to err on the side of not accepting some form of expression as constant if in doubt, but it is hoped that it will adequately cover most user expectations. Bug 16711, relating to the implementation of constant expression rules for C++, shows that some very strange undocumented extensions to constant expression rules are used by some users, but such cases as that are expected to be rare. The GNU C rules will generally be laxer about extensions to constant expressions in initializers than to extensions to integer constant expressions.
Apart from improved conformance, the benefits of implementation of
proper constant expression rules in GCC (as opposed to the present
‘whatever happens to be folded’) would include the
replacement of various unnecessary uses of trees with more specialised
datastructures that are allocated and deallocated separately, as a
preliminary, general cleanup of the handling of expressions in the C
front end, and removal of various kludged uses of trees to wrap
constants in an attempt to mark them nonconstant. In turn this would
open the way to removal of NON_LVALUE_EXPR.
Implementation following such models would also provide a proper
reference to turn to for resolution of such disputes as that
over the validity of
gcc.c-torture/compile/20010327-1.c. It is also
clearly beneficial for the code accepted by GCC to be well-defined
rather than depending on what that day’s compiler happens to
fold.
These models are models of the interpretation of C code and do not require a particular implementation.
I co-maintain the C front end of GCC, as well the documentation of GCC as a whole and its i18n support (and have done GCC development in many other areas). Since 4 October 2004 I have been doing GCC development for CodeSourcery. More recently, I have also been maintaining EGLIBC.
Return to my home page
Return to SRCF home page