ANSI standard and cpp
jim at ism780b.UUCP
jim at ism780b.UUCP
Mon Oct 8 14:17:47 AEST 1984
> 1. some implementations "tokenize" the file BEFORE preprocessing. It
> makes it very difficult to tell if the macro definition is identical
> to a previous definition.
Why? The comparison should only be on the tokens. The SysV and later cpp
strip leading and trailing blanks, strip comments, compress multiple blanks
to a single blank, and then do the comparison. How is that different from
"tokenizing"?
> 2. several committee members felt that if you were defining a macro more
> than once, your source has gotten out of control and it would be
> benificial to know if your macro has been defined more than once.
I wish the committee members would stop "feeling" and start standardizing.
The vast majority of C programs pass through some flavor of the Reiser cpp.
The first priority of the committee should be to establish the behavior of
that cpp as a standard when it is not clearly buggy or semantically obtuse
(expanding formals within strings is arguably semantically obtuse,
but not very, and compatibility should take precedence over the committee's
tendency to want to do language design).
Had that been done from the beginning, implementations that cannot do x
would never have been written, because they would have violated the
standard. The only reason such implementations are being taken into
consideration is because of vested interests of some members of the committee,
not because of the interests of the C community at large.
If 2. is really an issue, then the committee can recommend that an option
be available which warns about identical repeated definitions.
It should not be an error; it should not be the default.
-- Jim Balter, INTERACTIVE Systems (ima!jim)
More information about the Comp.lang.c
mailing list