Re: RFA: Deprecate C++ options

[Zack Weinberg <zack at codesourcery dot com>]

On Thu, Sep 06, 2001 at 06:22:48PM -0700, Mark Mitchell wrote:
> 
> I would support this, too -- even though it seems somewhat more
> radical.  I agree that I have not found a good use for -traditional
> in ages; the code that I have seen that needs pre-ISO stuff uses enough
> weird stuff that even -traditional does not support that it still doesn't 
> work.
> 
> The key point is not that it's not a useful feature -- it's that it's
> not useful unless it really works.  Given unlimited resources, I'd
> definitely keep it; without them, I'm tempted to focus on the bigger
> wins.  It's nearly certain that no GNU software needs this flag; I
> wonder if anyone wants to search the Debian package distributions to
> see if any of them are built with -traditional?

As Joe points out, there's a distinction to be made between the
traditional preprocessor and the traditional C compiler.

I can say with confidence that no Debian package in the current
archives uses the traditional C compiler, because that does not 
work at all with glibc >=2.1's headers.  I would support dropping
that code from gcc.

There are plenty of uses for the traditional preprocessor,
e.g. Imake.  It's implemented as a separate program right now, so it
doesn't impose any maintenance burden on cpplib.  We could
theoretically split it into its own package and distribute it
separately, but I don't think that would be worth the trouble.

Here's another proposal, which might sound radical, but I bet it'd
have even less user-visible impact: Let's drop support for every host
and target that doesn't have a C89-compliant standard library.  That
would mean, for instance, we could throw away fix-header and about
two-thirds of fixincludes.

zw