This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Criteria for a warning to be in -Wall? (was: Re: a warning to implement)

Robert Dewar wrote:

> I would say that if you want to write portable code that must be free of
> warnings then you are going to have to compromise and occasionally do
> a junk initialization. It's hard to believe that this is really

For an incoming unused argument, what other "junk initialization" can
you do that doesn't burn at least one opcode or that obfuscates the code
any less?

> s a bit annoying, but in truth it makes a completely undetectable
> difference to performance).

It compiles (at least when optimizing) to zero opcodes in every case I
looked at on every compiler.

> a. someone reasonably decides that int a = a; should generate a warning.
> It looks like GCC may in fact make this decision, but to base the integrity

This would br ironic, since this construct most frequently appears to
AVOID a warning.  Turning off the warning (-Wno-ununused) is too big of
a hammer since it has file scope and in reality you sometimes just need
to turn it off for a function or two.

> I actually find the requirement to write portable code that compiles
> with no warnings on multiple compilers itself to be seriously
> flawed. You can never tell when one of the compilers in question will
> add a new warning that just happens to hit your code.

I'm all for tools pointing out potential defects in my code.  Sometimes
I'm willing to throw them a bone becuase we are highly trained
professionals and know that what it's warning us about is a potential
hazard, but it really is necessary.  (Like this case.)

When new warnings show up, we address them.  We don't crank up maximum
"spank me" mode on every one of the compilers.  We just picked some
reasonable subset (which included -Wall on gcc) and have found that it
stays pretty static over time.

It's clear that you don't like this construct, but you haven't 
suggested anything else for ISO C that;
	A) has zero runtime cost in code or data
	B) Doesn't use a vendor-specific option.
	C) keeps -Wunused useful on functions with mandated arg lists.
(For C++, Joe's answer would clearly be the winning entry.)

I understand this has undefined behaviour.  I can even understand how in
C++ it could be really evil when ctors and such are involved.  But for
plain old scalars in C, I just don't think this is a warn-able offense -
esp. when the most common occurrence of it to date has been to avoid a


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]