What's implementation defined?

[Doug Gwyn]

In article <1988Dec5.181753.1961 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>	#define x <
>	#define y stdio.h
>	#define z >
>	#include x y z
>Since the combination mechanism in the #include is implementation-defined,
>this might turn into any of the following:
>	#include <stdio.h>
>	#include < stdio . h >
>	#include <\stdio\.\h>
>	#include <forget.it>
>(The last is arguably unreasonable, but it is not *clear* that the standard
>actually forbids it.)  The point is, the construct is required to be legal
>but is not required to be useful, which makes it pretty, uh, useless in
>portable programs.  This is actually a bit curious, since elsewhere (the
># operator, and arguably the ## operator), exact preservation of the
>original spelling of tokens is in fact demanded.  Was there a reason why
>a similar demand was considered impractical or undesirable here?

This facility (parameterization of header file names) is not meant
to be used portably; in fact it is specifically a hook for porters
to use to insert system-specific header file names.  The basic
problem is that the maximal subspace of possible file names that
ALL implementations would support is so small as to be of little
practical value.

The mapping is intended to be "reasonable", but that is a so-called
"quality of implementation" issue.  A porter will have to know the
specific names to supply for each target environment, which is why
the implementation is required to document the mapping.

Personally I'm not convinced of the necessity for this, but there
were X3J11 members who deal with many exceedingly strange systems
who claimed that such a facility was needed.

Don't use it unless you have to.