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

[Joe Buck <jbuck at synopsys dot com>]

> > > What if you worked for a company that required, as part of their coding
> > > style, warningless compilation?

I wrote:
> > But if we provide pragmas to turn off warnings and you use them, you
> > are violating your company's coding style!
> 
> That seems a little too simplistic.  Suppose, more reasonably, that you
> were required to examine all warnings, perhaps with peer review, and
> then either modify the code (if it did not meet company requirements),
> or (if it did meet company requirements) hush the warning so that in 
> the future people would not be distracted by the warning?

Clearly in that case, using a pragma to turn off a particular warning
would then be fine.  The company's policy would then have to require
this process before anyone would be permitted to use a warning-suppressing
pragma.

It still appears to me, however, that the lion's share of cases where
people want to turn off warnings would be handled by adding a mechanism
like /*NOTREACHED*/, which the compiler understands.  This is not
a command to suppress a specific warning, as it may suppress many
warnings; further, it could increase opportunies for optimization.

> You suggest lint-like comments as a way of hushing some warnings. 

The main reason is that my code has to go through many compilers, most
of which will not understand a new gcc mechanism, and seas of #ifdefs
are a maintainance problem.

> That's fine; I have no strong preference for #pramgas, _Pragmas,
> lint-like comments, or other mechanisms.  All I suggest is that 
> whatever mechanism selected be general enough to handle all warnings;
> not just those for which there is existing lint-like comment syntax.

If you insist on that, pragmas may be better for some classes of warnings.
It's just that for warnings that are primarily about the flow of control,
I think it's better to give the compiler more information on the flow
than to just tell it to shut up.