On 10 Jan 2007 18:48:58 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
|
| It seems to me that the only reason for Winit-self to exists is that
| people try to silence the -Wuninitialized warnings using the init-self
| hack and then other people have to work-around that hack.
I don't believe that explanation.
Anybody is free to believe whatever they wish.
As for facts to make up your mind, here there are a few:
* Some excerpts from the thread that originated the official blessing
on the init-self hack and the subsequent warning to work-around it:
(Joe Buck discovers the init-self hack and proposes to disable it and
require an option to enable it. That wasn't the option implemented.)
"Someone evidently discovered that if one writes "int a = a" it suppresses
uninitialized variable warnings! This seems to be an accidental feature
of gcc"
"The reason people seem to be motivated to do things like this has to do
with weaknesses in the current uninitialized variable analysis."
"Alternatively, I'd like to require the user to explicitly say that s/he
is intentionally using this warning-suppressing idiom, by saying something
like -Wno-self-assign"
http://gcc.gnu.org/ml/gcc/2002-02/msg00401.html
"So the idea of excluding this from -Wall would make sense ONLY if you
make the effect of suppressing warnings an official part of the gcc
semantics. In short only the following make sense:
1. Make this an official construct for the purpose of suppressing warnings
for uninitialized variables, and document that it has no other (ill) effect.
You can then decide whether to put the warning for this non-standard
construct in -Wall or not.
2. Leave this as it is now, undefined, in which case there can be no objection
to it being in -Wall, and indeed those people injudiciously using this
consruct to suppress warnings will be warned that this usage is neither
blessed nor guaranteed.
Frankly I would be surprised if you could get a consensus for approach 1."
http://gcc.gnu.org/ml/gcc/2002-02/msg00410.html
(Ironically, approach 1 was indeed the one implemented).
(Some people argued against the hack. Others argued in favour due to
the deficiencies in Wuninitialized)
"What is relevant, is that there obviously are people who think it's
usefull [sic] for that purpose. Perhaps you can suggest an equivalent
alternative to suppress the warning in question in certain
circumstances."
http://gcc.gnu.org/ml/gcc/2002-02/msg00288.html
"Such usage is explicitly allowed in the C and C++ Standards. I'll
grant you it's of dubious use, but one of the legal uses I can think
for it is to avoid getting a warning about a variable being used
uninitialized when you know for sure that it is not, but the compiler
can't tell as much."
http://gcc.gnu.org/ml/gcc/2002-02/msg00288.html
* The bug that requested Winit-self
"int x = x; is a gcc extension, but I could indeed not find a place in
the manual that talks about a warning option that gives
a message when this extension is used."
"Sure. IIRC the extension is that this reliably calms down warnings about
uninitialized variables."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5582
* The patch that added this option:
"This fixes PR 5582 only when pedantic is on because it as a GCC
extension to do int i = i; to turn off the uninitialized warnings for
that variable."
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00952.html
I hope this is sufficient for anyone to decide by themselves why
Winit-self exists and why int i=i; is not warned by Wuninitialized.
Cheers,
Manuel.
