Criticism of the C programming language: Difference between revisions

Revision as of 21:07, 8 January 2007

Revision as of 01:36, 14 January 2007

Line 113:

Some features of C, its preprocessor, and/or implementation are inconsistent. One of C's features is three distinct classes of non-wide string literals. One is for run-time data, another is for include files with quotation marks around the filename, and the third is for include filenames in angle brackets. The allowed symbol set, and the interpretation of them, is not consistent between the three. To some extent this arose from the need to accommodate a wide variety of file naming conventions, such as [[MS-DOS]]'s use of backslash as a path separator.

Another consistency problem stems from shortcomings in C's preprocessor, which was originally implemented as a separate, relatively simple, process only loosely connected with the semantics of the rest of the language. The following code is not legal Standard C:

int sixteen = 0x3e-0x2e;

Unfortunately,The areason Standardis Cthat preprocessor<code>0x3e-0x2e</code> willmatches convertthe form of a "0x3e-0x2epreprocessing number", and, since token-matching is greedy, is converted to a single preprocessing token,. and theThe subsequent conversion of that to a token in a later phase of translation is ill-defined, so the compiler mightwill not obtain the intended tokenization of

int sixteen = 0x3e - 0x2e ;

Line 126:

The C programming language was standardized by [[ANSI]] in 1989 and adopted as an [[ISO]] standard in 1990; the standard has subsequently been extended twice. Some features of the C standard, such as [[C trigraph|trigraphs]] and [[Complex number|complex arithmetic]], have been challenged on the ground of questionable user demand. Some major C compilers have not yet become fully conformant to later versions of the C standard.

The C standards have been accompanied by Rationale documents which describe the considerations behind many of the choices made by the standards committee. Frequently there were trade-offs among competing requirements, and not everybody weightsweighs the factors the same as did the C standards committee.

As well, the C standard leaves some codebehavior fragments undefinedunspcecified, such as the order of evaluation of arguments to a function, to allow compilers to compilehave them evaluated in whatever way they believe will be optimal. However, this can result in code fragments which behave differently when compiled by different compilers, by different versions of the same compiler, or on different architectures.

==Maintenance==