This section includes specific mention of the future direction in which the Committee intends to extend and/or restrict the language. The contents of this section should be considered as quite likely to become a part of the next version of the Standard. Implementors are advised that failure to take heed of the points mentioned herein is considered undesirable for a conforming hosted or freestanding implementation. Users are advised that failure to take heed of the points mentioned herein is considered undesirable for a conforming program.
See §3.5.1.
The characterization as obsolescent of the use of the ``old style'' function declarations and definitions --- that is, the traditional style not using prototypes --- signals the Committee's intent that the new prototype style should eventually replace the old style.
The case for the prototype style is presented in §3.3.2.2 and §3.5.4.3. The gist of this case is that the new syntax addresses some of the most glaring weaknesses of the language defined in the Base Document, that the new style is superior to the old style on every count.
It was obviously out of the question to remove syntax used in the overwhelming majority of extant C code, so the Standard specifies two ways of writing function declarations and function definitions. Characterizing the old style as obsolescent is meant to discourage its use, and to serve as a strong endorsement by the Committee of the new style. It confidently expects that approval and adoption of the prototype style will make it feasible for some future C Standard to remove the old style syntax.
As vector and parallel hardware, and numeric applications in C, become more common, the aliasing semantics of C have been a source of frustration for implementors wanting to make optimum use of such hardware. If arrays are known not to overlap, certain optimizations become possible, but C currently provides no way to specify to a translator that argument arrays indeed do not overlap. The Committee, in adopting this future direction, hopes to provide common ground for implementors and users concerned with this problem, so that some future C Standard can adopt this non-overlapping rule on the basis of widespread experience.