Re: Warnings in the C++ Front-End and GCC in General

[Craig Burley <burley at gnu dot org>]

>I don't understand the desire for new language constructs. If one has
>to change sources and header files anyway, one could just fix the code
>instead of disabling the warning in many cases.

Agreed.

>Mark's facility is really for people who get hundreds of identical
>warnings, and want to shut up all of them.

I agree that's at least *one* case of what it's for.

However, what it's for, and how it'll actually be used, are two very
different things.

__asm__.  volatile.  regparm.  `&&label' in inlinable code.  How
many of these things have we wasted time and energy discussing
on this and other forums, in situations where the way they were
used was *not* remotely similar to what those things were intended
for??

One solution is to add this facility, and simultaneously institute
a new policy at egcs-bugs (and similar): use of any gcc extension
not strictly in line with how *we* think it should be used will
mean we'll not consider fixing the problem at all, and we'll insist
on seeing *real* examples of the "problem code" to verify this
for ourselves.

I don't seriously suggest that, but if we want to continue to get
real work done in the future, rather than try to explain to an
ever-growing audience of programmers why they shouldn't use each and
every single feature written up in the docs in the cleverest ways
possible and then complain if the features don't work as they think
they "should", it's either that or, stop adding features that aren't
properly designed for portable languages like C in the first place.

        tq vm, (burley)