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.

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.