Re: Mistaken change in GCC (fwd)

["Zack Weinberg" <zackw at Stanford dot EDU>]

I have strong opinions on this issue.  They are:

1. The purpose of -traditional is exactly to simulate the limitations
   of the historic pre-standard C compiler and preprocessor, and
   therefore to make it possible to compile pre-standard C code on
   modern systems.  Ignore for the moment the fact that this is
   impossible anyway because modern system headers won't cooperate.
   If the behavior of the compiler in -traditional mode fails to match
   the behavior of a genuine K+R compiler in all respects, that is a
   bug.  (Many such bugs exist.  Fixing them is more trouble than it
   is worth.)

   I seriously considered removing support for #elif from tradcpp for
   this reason.  In the end, the amount of pain that would have caused
   was not worth it, especially since there were K+R preprocessors
   that understood #elif.

   When the feature under discussion is a little-used extension that
   was invented by SVR4, years after the promulgation of the C
   standard, then it will be supported in -traditional mode over my
   dead body.

2. Support for preprocessing things which are not C is much lower
   priority than support for preprocessing C.  I do not care about
   historical precedent.  The Unix tradition has plenty of historical
   precedents that were bad ideas when they were invented, are still
   bad ideas now, and the sooner they go away the better.  This is one
   of them.

   However, since part of the historic behavior of the traditional
   preprocessor was its predictable and useful output when fed non-C
   code, and there is a large body of existing software that expects
   it, I am prepared to continue to support feeding such things to the
   traditional preprocessor.  This license extends only so far as such
   code can be reasonably expected to work with the traditional
   preprocessor.  In particular, it is not reasonable to expect it to
   support assertions, since they were never supported by any actual
   K+R preprocessor.

3. The specific extension under discussion, #assert, is an abomination
   upon the face of the earth.  The documentation makes grandiose
   claims about the wonderful consistency and reliability of the
   assertion namespace, but those claims are not matched by the
   implementation.  In practice the predefined assertions are just as
   unpredictable as the predefined macros, if not more so.  Further,
   the vast majority of compilers do not support #assert.  Therefore
   there is no justifiable reason to use assertions.

I am working on a revision to the cpp manual which will clarify the
questions about what -traditional does or does not do.  It will also
change the documentation of assertions to match reality.  In addition
I will consider adding a mandatory warning to all uses of assertions
stating that the feature is unportable and deprecated.  (We can't
remove it because it is used by the Solaris system headers.)

In my opinion, these changes are sufficient response by the GCC team
to this complaint.  If he would like, I will personally assist the
Emacs maintainer in removing the use of preprocessor assertions from
Emacs.

zw