Token pasting in #include directive [repost]

Doug Gwyn gwyn at smoke.BRL.MIL
Fri Nov 24 02:45:25 AEST 1989


In article <1989Nov22.222413.3874 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>In article <11160 at riks.csl.sony.co.jp> diamond at ws.sony.junet (Norman Diamond) writes:
>>I must ask again which carries more weight, the stated rules or the
>>examples.
>I must reply again :-), if you read section 1.4 very carefully, you will
>discover that the examples are technically not part of the standard.

But that's beside the point.  The preprocessing examples were reviewed
VERY carefully by numerous implementors, and we do not believe there
are any errors in them in the final draft.  Therefore if you think the
actual specification conflicts with the examples, the odds are good
that you're not interpreting the specification correctly.  The use of
a natural language (such as English) for such a technical specification
always opens up the possibility of misinterpretation, because words
denote concepts and there is no direct way to transfer a concept from
one human being to another; independent parallel conceptualization
must be performed by the recipient.  The best the communicator can do
is to attempt to guide the recipient's thought processes, but there is
no way to guarantee the result.

We just had another example of this in the comp.std.unix newsgroup,
where someone was attempting to read IEEE Std 1003.1-1988 like an
unthinking automaton and blindly apply what he thought it literally
said to arrive at erroneous conclusions.  Of course, he had to
apply some degree of interpretation even to get that far, but he
argued that no interpretation should be required.  I think that
represents a misunderstanding of how to read technical information.



More information about the Comp.std.c mailing list