This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Mistaken change in GCC (fwd)
- To: dewar at gnat dot com (Robert Dewar)
- Subject: Re: Mistaken change in GCC (fwd)
- From: Joe Buck <jbuck at racerx dot synopsys dot com>
- Date: Wed, 22 Nov 2000 08:34:30 -0800 (PST)
- Cc: rms at gnu dot org, zackw at stanford dot edu, gcc at gcc dot gnu dot org, gerd at gnu dot org, pfeifer at dbai dot tuwien dot ac dot at
RMS writes:
> <<Thinking of --traditional in this way will tend to lead to bad
> decisions. Its purpose is to make old constructs work, not to emulate
> an old compiler and its limitations. It is very common for some newer
> constructs to be used in conjunction with old ones.
> >>
Robert Dewar writes:
> Hmmm! I am no expert here, but I always thought of --traditional as meaning
> traditional K&R style C. If it means something else, it needs very well
> defining. Why not just introduce additional switches for features that
> do not fall into existing categories neatly.
Rather than getting all philosophical, we should look at what we promised
the users. The gcc 2.95.2 distribution contains cpp.texi, which describes
what -traditional does, and it specifically says, for some features, that
they do not work if -traditional is used, e.g. "This macro is not defined
if the @samp{-traditional} option is used." Where there is no such
notation, the user will assume that -traditional has no such effect.
The description for #cpu does not have this caveat, therefore the manual
promises that #cpu works with -traditional. Users who write code based
on this promise are not wrong.
Dropping documented features can be done, but the SC must agree. Zack,
it's not your call. (That doesn't mean that you, personally, have to fix
it, but if every flavor of Emacs out there will break and it's a simple
fix, let's just do it, OK?).