Re: a warning to implement

Re: a warning to implement

[Robert Dewar]

<<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.  For example:
>>

Obviously this dubious use should generate a warning, and most certainly
it should be enabled by -Wall. The idea of using this to *avoid* the
warning seems absurd to me. If you want a way of turning off warnings,
implement one, but don't use a clearly bogus construct for the purpose.

Re: a warning to implement

[Alexandre Oliva]

On Feb  2, 2002, dewar@gnat.com (Robert Dewar) wrote:

> If you want a way of turning off warnings, implement one, but don't
> use a clearly bogus construct for the purpose.

It's not clearly bogus.  It's explicitly allowed in the Standard.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: a warning to implement

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| <<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.  For example:
| >>
| 
| Obviously this dubious use should generate a warning,

Well, that construct have been debated to death in the C++ committee.
And given the length of the debate and the opinions expressed there I
would certainly *not* characterize it as obviously dubious.  I would
object to have it enabled by -Wall.

-- Gaby

Re: a warning to implement

[Alexandre Oliva]

On Feb 11, 2002, Joe Buck <jbuck@synopsys.com> wrote:

>> On Feb 11, 2002, Paolo Carlini <pcarlini@unitus.it> wrote:
>> 
>> > Alexandre, are you deadly sure that the current mainline emits the warning?
>> 
>> Joe Buck said so, with the caveat that it only does so when optimizing
>> (because we don't do liveness analysis otherwise).  I didn't double
>> check.

> No, I did not say this and in fact it is not true.

I stand corrected.  I had mis-read your message.  What you had stated
as a wish, I had taken for granted.  My apologies.

Still, I agree with you the docs imply such a warning should be given,
and if it doesn't, it's just a bug that should be fixed, not a demand
for a new, different warning.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: a warning to implement

[Joe Buck]

> On Feb 11, 2002, Paolo Carlini <pcarlini@unitus.it> wrote:
> 
> > Alexandre, are you deadly sure that the current mainline emits the warning?
> 
> Joe Buck said so, with the caveat that it only does so when optimizing
> (because we don't do liveness analysis otherwise).  I didn't double
> check.

No, I did not say this and in fact it is not true.

Re: a warning to implement

[Alexandre Oliva]

On Feb 11, 2002, Paolo Carlini <pcarlini@unitus.it> wrote:

> Alexandre, are you deadly sure that the current mainline emits the warning?

Joe Buck said so, with the caveat that it only does so when optimizing
(because we don't do liveness analysis otherwise).  I didn't double
check.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: a warning to implement

[Paolo Carlini]

Alexandre Oliva wrote:

>Hmm...  Perhaps my message was lost in the noise...
>
>We *already* have a warning that is enabled with -Wall for constructs
>such as `T x = x;', and the warning is that `x' is being used
>uninitialized.  Some earlier versions of GCC apparently didn't issue
>this warning, or only do when optimization is enabled, but the fact is
>that there is a warning already, and adding another IMHO would be
>overkill.
>
Alexandre, are you deadly sure that the current mainline emits the warning?
The whole thread started with Andrey observation that gcc does *not* 
warn. At the time I supported him, having verified that indeed it 
does'nt with -Wall and/or -Wuninitialized. Unfortunately I don't have 
here my snapshots to check again.

Ciao, Paolo.

Re: a warning to implement

[Robert Dewar]

<We *already* have a warning that is enabled with -Wall for constructs
such as `T x = x;', and the warning is that `x' is being used
uninitialized.  Some earlier versions of GCC apparently didn't issue
this warning, or only do when optimization is enabled, but the fact is
that there is a warning already, and adding another IMHO would be
overkill.
>>

Sorry, I did get confused by the thread, yes, indeed that's a perfectly
fine warning, this is nothing more or less than an instance of using
x before it is initialized.

Re: a warning to implement

[Alexandre Oliva]

On Feb 11, 2002, Bernard Dautrevaux <Dautrevaux@microprocess.com> wrote:

> However there seems to be such a strong opposition to having this warning
> installed by default in -Wall that I think we should at least provide it as
> an additional warning flag; it's useful enough that we may get it.

Hmm...  Perhaps my message was lost in the noise...

We *already* have a warning that is enabled with -Wall for constructs
such as `T x = x;', and the warning is that `x' is being used
uninitialized.  Some earlier versions of GCC apparently didn't issue
this warning, or only do when optimization is enabled, but the fact is
that there is a warning already, and adding another IMHO would be
overkill.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

RE: a warning to implement

[Robert Dewar]

<<However there seems to be such a strong opposition to having this warning
installed by default in -Wall that I think we should at least provide it as
an additional warning flag; it's useful enough that we may get it.
>>

I don't see strong opposition. One person writing dozens of emails (Gaby)
does not add up to strong opposition. I would say that the consensus is
clearly to have it included in -Wall.

RE: a warning to implement

[Bernard Dautrevaux]

> -----Original Message-----
> From: Per Abrahamsen [mailto:abraham@dina.kvl.dk]
> Sent: Sunday, February 10, 2002 3:01 PM
> To: gcc@gcc.gnu.org
> Subject: Re: a warning to implement
> 
> 
> Gabriel Dos Reis <gdr@codesourcery.com> writes:
> 
> > What I'm saying is that if you want to be warned about that 
> construct
> > then you should explicitly turn on the appropriate flag.  In this
> > case, I do think -Walll should -not- turn that flag on.  
> 
> The manual says this about -Wall:
> 
>   `-Wall'
>        All of the above `-W' options combined.  This enables all the
>        warnings about constructions that some users consider
>        questionable, and that are easy to avoid (or modify to 
> prevent the
>        warning), even in conjunction with macros.
> 
> An example of a warning produced by -Wall:
> 
>   void foo (const char* p, char* q)
>   {
>     while (*q = *p)
>       { ++q; ++p; }
>   }
> 
>   test.cc: In function `void foo(const char *, char *)':
>   test.cc:3: warning: suggest parentheses around assignment 
> used as truth value
> 
> It is clear that _some_ users consider assignment as truth value
> questionable, and it is easy to avoid.  Thus, it is a good example of
> a -Wall warning.  Just to set the level we are talking about.
> 
> Are you saying the "T x = x" is less questionable or harder to work
> around than the above?
> 
> Personally, not being one of the super programmers on this 
> list, I have
> lost a couple of days work debugging errors caused by accidental use
> of the "T x = x" construct, which I at the time didn't even knew was
> legal, so I would have loved to have had a warning with -Wall, but
> wouldn't even have thought of searching for a separate flag.
> 

I can only agree with that :-)

However there seems to be such a strong opposition to having this warning
installed by default in -Wall that I think we should at least provide it as
an additional warning flag; it's useful enough that we may get it.

Anyway for me, that doesn't change a lot: I'm not even setting -Wall in my
makefiles: it's set up in some central place so that ALL compiles by ALL
developpers in my teams use it without even knowing that I've decided it;
thus I only have to add -Wself-initialize, or whatever it'll be called, to
this single location and all my programmers will have it :-)

I think this thread is now long enough we all refrain continuing this
religion war about whether this should be in -Wall or not (unless there is
some authoritative person that can get convinced and can rule about this
:-)).

Best regards, and thanks to all for the good work.

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

Re: a warning to implement

[Per Abrahamsen]

Gabriel Dos Reis <gdr@codesourcery.com> writes:

> What I'm saying is that if you want to be warned about that construct
> then you should explicitly turn on the appropriate flag.  In this
> case, I do think -Walll should -not- turn that flag on.  

The manual says this about -Wall:

  `-Wall'
       All of the above `-W' options combined.  This enables all the
       warnings about constructions that some users consider
       questionable, and that are easy to avoid (or modify to prevent the
       warning), even in conjunction with macros.

An example of a warning produced by -Wall:

  void foo (const char* p, char* q)
  {
    while (*q = *p)
      { ++q; ++p; }
  }

  test.cc: In function `void foo(const char *, char *)':
  test.cc:3: warning: suggest parentheses around assignment used as truth value

It is clear that _some_ users consider assignment as truth value
questionable, and it is easy to avoid.  Thus, it is a good example of
a -Wall warning.  Just to set the level we are talking about.

Are you saying the "T x = x" is less questionable or harder to work
around than the above?

Personally, not being one of the super programmers on this list, I have
lost a couple of days work debugging errors caused by accidental use
of the "T x = x" construct, which I at the time didn't even knew was
legal, so I would have loved to have had a warning with -Wall, but
wouldn't even have thought of searching for a separate flag.

Re: a warning to implement

[Gabriel Dos Reis]

Bernard Dautrevaux <Dautrevaux@microprocess.com> writes:

| > -----Original Message-----
| > From: Gabriel Dos Reis [mailto:gdr@codesourcery.com]
| > Sent: Friday, February 08, 2002 5:29 PM
| > To: dewar@gnat.com
| > Cc: Dautrevaux@microprocess.com; gdr@codesourcery.com; 
| > gcc@gcc.gnu.org;
| > nathan@cs.bris.ac.uk; rsandifo@redhat.com
| > Subject: Re: a warning to implement
| > 
| > 
| > dewar@gnat.com (Robert Dewar) writes:
| > 
| > | >>| I think here we should REALLY had a warning;
| > | 
| > | Yes, good point from Bernard, I agree this is a case that 
| > really needs
| > | a warning.
| > 
| > There was no good point.  The class I showed wasn't designed to have a
| > default constructor -- that is part of its specification.  The
| > compiler (or Bernard) shouldn't insist on knowing more than the
| > class-defisgner. 
| 
| OK; fine. But then you are saying that if a gun-holder wants to shoot
| himself in the foot, nobody should warn him that this isn't *usually* a good
| idea?

Proof by analogy is fraud.

| an dyou insist that if someone is able to warn him, this warning
| should *in no case* be emitted by default, but only if he choose to get it?

What I'm saying is that if you want to be warned about that construct
then you should explicitly turn on the appropriate flag.  In this
case, I do think -Walll should -not- turn that flag on.  

[...]

| > There are already plenty of warnings there saying they know more than
| > thge programmer -- and in effect thery don't -- ending with being
| > completely unusable in modern C++; an example is -Weffc++ (or whatever
| > it is called). 
| 
| OK; I 200% agree with you: "-Weffc++" is NOT a warning i would expect to be
| activated by "-Wall". It's not a warning about dubious or dangerous
| constructs,

The example I gave is by no means dubious and dangerous.  It is just a
perfectly well-formed implementation of singly-linked circular list.

| but a warning to help someone (obviously not you, nor me in
| fact) adhere to some coding conventions that nobody request anybody to
| accept.

In case you missed it, I'll repeat again: I'm not arguing against
having an option that implement the warning.

-- Gaby

RE: a warning to implement

[Bernard Dautrevaux]

> -----Original Message-----
> From: Gabriel Dos Reis [mailto:gdr@codesourcery.com]
> Sent: Friday, February 08, 2002 5:29 PM
> To: dewar@gnat.com
> Cc: Dautrevaux@microprocess.com; gdr@codesourcery.com; 
> gcc@gcc.gnu.org;
> nathan@cs.bris.ac.uk; rsandifo@redhat.com
> Subject: Re: a warning to implement
> 
> 
> dewar@gnat.com (Robert Dewar) writes:
> 
> | >>| I think here we should REALLY had a warning;
> | 
> | Yes, good point from Bernard, I agree this is a case that 
> really needs
> | a warning.
> 
> There was no good point.  The class I showed wasn't designed to have a
> default constructor -- that is part of its specification.  The
> compiler (or Bernard) shouldn't insist on knowing more than the
> class-defisgner. 

OK; fine. But then you are saying that if a gun-holder wants to shoot
himself in the foot, nobody should warn him that this isn't *usually* a good
idea? an dyou insist that if someone is able to warn him, this warning
should *in no case* be emitted by default, but only if he choose to get it?

IMHO a compiler should warn the user of all possible cases where he may be
shooting into his own foot (or into another one's foot FWIW :-)); what I
could agree is that this warning could be disable by people that really want
to point the gun to their foot but knows there are cute enough to shoot just
between they toes, but the compiler should not assumbe blindly they are cute
enough.

After all, if you suddenly get a warning about a construct you're using
because you know what you do, you will then be inclined to RTFM and then
will discover the magic "-Wno-self-initialize" option that get you rid of
this anoying warning. 

But saving *you* the small burden of saying to the compiler "Hi, I'm a very
experienced programmer and I know exactly what I'm doing" seems not very
fair to all the "average" programmers that, incidentally, will *never* read
this thread because they don't even imagine what we are talking about.

> 
> There are already plenty of warnings there saying they know more than
> thge programmer -- and in effect thery don't -- ending with being
> completely unusable in modern C++; an example is -Weffc++ (or whatever
> it is called). 

OK; I 200% agree with you: "-Weffc++" is NOT a warning i would expect to be
activated by "-Wall". It's not a warning about dubious or dangerous
constructs, but a warning to help someone (obviously not you, nor me in
fact) adhere to some coding conventions that nobody request anybody to
accept.
 
	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

Re: a warning to implement

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| >>| I think here we should REALLY had a warning;
| 
| Yes, good point from Bernard, I agree this is a case that really needs
| a warning.

There was no good point.  The class I showed wasn't designed to have a
default constructor -- that is part of its specification.  The
compiler (or Bernard) shouldn't insist on knowing more than the
class-defisgner. 

There are already plenty of warnings there saying they know more than
thge programmer -- and in effect thery don't -- ending with being
completely unusable in modern C++; an example is -Weffc++ (or whatever
it is called). 

-- Gaby

Re: a warning to implement

[Robert Dewar]

>>| I think here we should REALLY had a warning;

Yes, good point from Bernard, I agree this is a case that really needs
a warning.

Re: a warning to implement

[Gabriel Dos Reis]

Bernard Dautrevaux <Dautrevaux@microprocess.com> writes:

[...]

| > The following is OK:
| > 
| >   struct Node {
| >      Node* link;
| >      Node(Node& n) : link(&n) { }
| >   };
| > 
| >   int main()
| >   {
| >      T x = x;
| >   }
| > 
| > and is a canonical example of use for user-defined-type.
| 
| I think here we should REALLY had a warning; 

I'm of the opposite opinion.  Warning for what?

| in fact you have here a class which explicitely do NOT have a
| default constructor, 

So what?  

The class is defined to meet specific needs.  The default constructor
isn't part of that need.  So why should there be one?

| and then we create an 
| un-constructed object value. 

That is nonsense.

-- Gaby

RE: a warning to implement

[Bernard Dautrevaux]

> -----Original Message-----
> From: Gabriel Dos Reis [mailto:gdr@codesourcery.com]
> Sent: Wednesday, February 06, 2002 5:40 PM
> To: nathan@cs.bris.ac.uk
> Cc: Robert Dewar; gdr@codesourcery.com; rsandifo@redhat.com;
> gcc@gcc.gnu.org
> Subject: Re: a warning to implement
> 
> 
> Nathan Sidwell <nathan@acm.org> writes:
> 
> | Hi,
> | I've been reading this thread, and I still can't figure out how
> | 	T x = x;
> | as anything but undefined semantics. I'm talking C++ here.
> | [3.3.1]/1 gives an example about point of declaration, and says of
> | 	int x = x;
> | 	Here ... is initialized with its own (indeterminate) value.
> | 
> | But, that assignment requires an lvalue to rvalue conversion on 'x',
> | and [4.1] says
> | 	'or if the object is uninitialized,... undefined behaviour'
> 
> The object isn't uninitialized; it is initialized with an
> indeterminated value. The point is precisely to give an explicit hint
> to the compiler to assign (if possible) to assign a singular value to
> x (pretty much in the same way you might assign a SNaN to a floating
> point to prevent use before explicit assignment with determinate
> value. 
> 
> | So it appears that we've got undefined behaviour for any POD T.
> 
> Except when T = char or unsigned char.
> 
> | For a class T, we could be calling the copy ctor T(T const &).
> | Reference binding at [8.3.1]/4 says a reference must be bound to a
> | `valid object'. I suppose that it is ok to reference bind to an
> | object of indeterminate value.
> 
> The following is OK:
> 
>   struct Node {
>      Node* link;
>      Node(Node& n) : link(&n) { }
>   };
> 
>   int main()
>   {
>      T x = x;
>   }
> 
> and is a canonical example of use for user-defined-type.

I think here we should REALLY had a warning; in fact you have here a class
which explicitely do NOT have a default constructor, and then we create an
un-constructed object value. 

OTOH, if I have

class Node {
      Node* link;
public:
	Node() { link = 0; }
	~Node() { delete link; }
	Node(Node* n) : link(n) { }
	Node(Node& n) : link(&n) { }
};

int main() {
	T x = x;
}

Then I' most surely have, in my Node class, taken all possible precautions
to avoid any use of undefined pointer values, yet the given main will most
surely crash with some kind of SIGSEGV ;-(

So IMNSHO, the warning IS needed and should be on ASAP, so at least in
-Wall.

Just my .02euro

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

Re: a warning to implement

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| >>It is defined to copy a signalling NaN.
| 
| Not in this situation it is not!

The above is silly: it deletes the context in which I made that statement.

-- Gaby

Re: a warning to implement

[Joe Buck]

Re: int a = a, Alexandre writes:

> I hereby withdraw my suggestion, in case I haven't done so yet.
> Thanks for pointing out my glaring mistake *blush* :-)  It's indeed
> bogus.  At the very least, the use of a's rvalue in the RHS of its
> first assignment should be warned about.  Perhaps this would be
> enough, and we don't need any further warnings?

Currently the uninitialized variable warning points at the declaration of
the variable.  I don't think that a separate warning for self-assignment
is needed if it is just flagged as "may be used unitialized".

I am curious, though.  Can anyone point to existing free software that
is using this, um, feature to supress warnings?

Re: a warning to implement

[Alexandre Oliva]

On Feb  6, 2002, Joe Buck <jbuck@synopsys.com> wrote:

>> On Feb  6, 2002, dewar@gnat.com (Robert Dewar) wrote:
>> 
>> > One thing I realize I am confused about now, is it *currently* the case
>> > that gcc documents that
>> 
>> >    int a = a;
>> 
>> > suppresses warnings on a, or is this just a proposed feature?

> Alexandre writes:
>> I've only proposed it as a feature.  I don't think this is
>> documented as such.

> It is currently the case *by accident*, and this accident is particularly
> bad in C++, as it suppresses uninitialized variable warnings in
> constructor calls that users would like to see.

> Evidently Alexandre would like to document this accident.

I hereby withdraw my suggestion, in case I haven't done so yet.
Thanks for pointing out my glaring mistake *blush* :-)  It's indeed
bogus.  At the very least, the use of a's rvalue in the RHS of its
first assignment should be warned about.  Perhaps this would be
enough, and we don't need any further warnings?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: a warning to implement

[mike stump]

> To: dewar@gnat.com, gdr@codesourcery.com
> Cc: gcc@gcc.gnu.org, nathan@cs.bris.ac.uk, rsandifo@redhat.com
> Date: Wed,  6 Feb 2002 15:23:48 -0500 (EST)
> From: dewar@gnat.com (Robert Dewar)

> You seem to be assuming that of necessity a char object can contain
> only valid representations. This is definitely not true on all
> implementations.

It is certainly true on all C and C++ implementations.  gcc is first,
and foremost, a C/C++ compiler.  We wind up with the reality that
while what you say might be true, no such implementation can host
either a C or C++ compiler, and no such implementation is interesting
while discussing gcc.

Re: a warning to implement

[Robert Dewar]

>>It is defined to copy a signalling NaN.

Not in this situation it is not! That's because

   int a = a;

is undefined, so any assurance that an ordinary assignment or initialization
may give does not apply in this case.

Re: a warning to implement

[Jason Riedy]

And Gabriel Dos Reis writes:
 - 
 - It is defined to copy a signalling NaN.

Nit:  Signalling behavior on copying _with_no_change_in_format_
is up to the implementation in 754-1985.  The language suggests 
uniformity, so it should always signal invalid or never signal 
invalid.  The revision committee has agreed it should be quiet 
always in a future standard.  I don't know about format changes,
though.  I'll have to bring that up.  (Think loading a non-80-
bit-quantity in x86, which is already not 754-1985, but still...)

Jason

Re: a warning to implement

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| <<  Certain object representations need not represent a value of the
|   object type.  If the stored value of the object has such a
|   representation and is read by an lvalue expression that does not
|   have character type, the behavior is undefined.  If such a
|   representation is produced by a side effect thaty modifies all or
|   any part of the object by an lvalue expression that does not have
|   character type, the behavior is undefined.  Such a representation is
|   called a trap represetation.
| >>
| 
| You seem to be assuming that of necessity a char object can contain only
| valid representations. 

I assume nothing.  Those are the words of the standard.
Put in another words, there is no trap representation for characters.

-- Gaby

Re: a warning to implement

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.com> writes:

| Robert writes:
| > But Gaby, right now, the construct
| > 
| >  int a = a;
| > 
| > produces an undefined result, so no one can use it. It might suppress
| > warnings in one version of gcc, but then someone might submit a patch
| > that causes it to have some disastrous effect, and no one would have
| > a right to complain, since if they are using this, they are using an
| > undocumented behavior, and have no right to count on it.
| 
| One possible disasterous effect is that
| 	float a = a;
| with debugging off might generate an actual load and store, and if it
| reads stack noise that looks like a signalling NaN, boom.

It is defined to copy a signalling NaN.

-- Gaby

Re: a warning to implement

[Robert Dewar]

<<  Certain object representations need not represent a value of the
  object type.  If the stored value of the object has such a
  representation and is read by an lvalue expression that does not
  have character type, the behavior is undefined.  If such a
  representation is produced by a side effect thaty modifies all or
  any part of the object by an lvalue expression that does not have
  character type, the behavior is undefined.  Such a representation is
  called a trap represetation.
>>

You seem to be assuming that of necessity a char object can contain only
valid representations. This is definitely not true on all implementations.

Re: a warning to implement

[Joe Buck]

Robert writes:
> But Gaby, right now, the construct
> 
>  int a = a;
> 
> produces an undefined result, so no one can use it. It might suppress
> warnings in one version of gcc, but then someone might submit a patch
> that causes it to have some disastrous effect, and no one would have
> a right to complain, since if they are using this, they are using an
> undocumented behavior, and have no right to count on it.

One possible disasterous effect is that
	float a = a;
with debugging off might generate an actual load and store, and if it
reads stack noise that looks like a signalling NaN, boom.  The compiler
could avoid this by optimizing away the assignment even at -O0.

Re: a warning to implement

[Robert Dewar]

But Gaby, right now, the construct

 int a = a;

produces an undefined result, so no one can use it. It might suppress
warnings in one version of gcc, but then someone might submit a patch
that causes it to have some disastrous effect, and no one would have
a right to complain, since if they are using this, they are using an
undocumented behavior, and have no right to count on it.

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.

Re: a warning to implement

[Joe Buck]

> Joe Buck <jbuck@synopsys.COM> writes:
> 
> [...]
> 
> | In fact "int a = a" uses an uninitialized variable and should give
> | warnings according to *current documentation* when -Wall is given, but
> | evidently Gaby wants us to preserve this botch indefinitely!

Gaby writes:
> Joe, that is not a fair or accurate representation of my
> position.

I apologize -- I meant to say Alexandre, since he proposed documenting
this behavior.  I may have blended together messages from him and from
you.

Re: a warning to implement

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.COM> writes:

[...]

| In fact "int a = a" uses an uninitialized variable and should give
| warnings according to *current documentation* when -Wall is given, but
| evidently Gaby wants us to preserve this botch indefinitely!

Joe, that is not a fair or accurate representation of my
position. I'll repeat it again: I'm not opposed to an option that
warns about self-initialization if done correctly.  
I simply don't think it should be turned on by -Wall.  

In the real world, an example along the line you gave above was
presented to me when someone  -- actually Vincent Lefevre
<vincent+news@vinc17.org> -- complained (loudly) on the French
speaking newsgroup news:fr.comp.lang.c about GCC giving bogus warning
for a perfectly valid program construct (I don't remember the exact
code, but it was about initializing variables based on some series of
conditions). 

As an aside, I'm a bit surprised to see that far more misleading
constructs should be warned about by GCC, but the corresponding flags
are not turned on by -Wall and yet nobody is arguing so strongly about
having them in -Wall.  An example is -Wnested-externs.  

-- Gaby

Re: a warning to implement

[Joe Buck]

> 
> >>Perhaps there should be an option to enable *all* warnings?
> 
> Sounds reasonable. Too bad that the obvious name for this option is taken :-)
> 
> Actually we find in the Ada case that there are some warnings that are just
> too specialized to be generally useful since they correspond to specific
> style options that few people follow. For example, in Ada -gnatwd requires
> that all dereferencing be explicit, rather than being implicit as allowed
> by the language. This warning would generate false positives on nearly all
> Ada code, but is useful to a very small minority that wish to follow this
> particular style rule.

Some of the warnings for other languages are similar, so I suspect that
people only *think* they would want to enable all warnings.

Re: a warning to implement

[Joe Buck]

> On Feb  6, 2002, dewar@gnat.com (Robert Dewar) wrote:
> 
> > One thing I realize I am confused about now, is it *currently* the case
> > that gcc documents that
> 
> >    int a = a;
> 
> > suppresses warnings on a, or is this just a proposed feature?

Alexandre writes:
> I've only proposed it as a feature.  I don't think this is
> documented as such.

It is currently the case *by accident*, and this accident is particularly
bad in C++, as it suppresses uninitialized variable warnings in
constructor calls that users would like to see.

Evidently Alexandre would like to document this accident.

Re: a warning to implement

[Joe Buck]

> 
> <<I've only proposed it as a feature.  I don't think this is
> documented as such.
> >>
> 
> So no one could actually be using 
> 
> int a = a;
> 
> for any useful purpose right now as I understand it, so I am at a complete
> loss to understand Gaby's claim that some people think this is useful.

OK, here's the scoop.

Someone evidently discovered that if one writes "int a = a" it suppresses
uninitialized variable warnings!  This seems to be an accidental feature
of gcc, arguably a misfeature, and now that I see it I understand why
gcc failed to warn about coding errors I've made in the past.

The reason people seem to be motivated to do things like this has to do
with weaknesses in the current uninitialized variable analysis.  For
example

void fred(int);

int foo(int a, int b)
{
    int bar;
    int flag = 0;
    if (a > b) {
	bar = a;	/* this is the only place bar is set */
	flag = 1;
    }
    if (flag) {
	fred(bar);	/* this is the only place bar is used */
    }
    return 0;
}

% gcc -O -Wall -c foo.c
foo.c: In function `foo':
foo.c:5: warning: `bar' might be used uninitialized in this function

We get the warning because gcc is not smart enough to trace the value of
the flag variable and figure out that fred will only be called in cases
where bar is set.

But if the first line of the body of foo is changed to

    int bar = bar;

the warning goes away, and furthermore, the optimizer will remove the
assignment, so the user gets slightly better code than they would have
if they had written

    int bar = 0;

because the same weakness that gives us a bad warning keeps gcc from
knowing that the assignment of 0 is dead code.

It appears that some people have discovered this and are using it in
production code.  IMHO, this sucks.  We should provide some cleaner
way of suppressing the warning.

In fact "int a = a" uses an uninitialized variable and should give
warnings according to *current documentation* when -Wall is given, but
evidently Gaby wants us to preserve this botch indefinitely!  Better
to provide some kind of lint-like comment or attribute to tell gcc
to shut up about alleged uninitialized use.

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

Re: a warning to implement

[Phil Edwards]

On Wed, Feb 06, 2002 at 06:12:48PM +0100, Gerald Pfeifer wrote:
> On Tue, 5 Feb 2002, Phil Edwards wrote:
> > I agree that the warning shouldn't be in -Wall, but I think we could do
> > a better job of educating our users about the GCC features which are not
> > as well-known.  Non-Wall warnings seem to fall into this category.
> 
> New options like these should go into release announcements.

Agreed, but think "new users" rather than "new options".  There are non-Wall
warning options which have been in GCC since long before the first time I
used GCC as a student; it took me a while to learn about them.  Even if the
"new" options had been listed in the release announcements at the time,
it wouldn't have helped me as a new user months/years later.

All my prof told us was, "use -Wall," and arguably it's his fault for
failing to add, "and if you can figure out how to use the info(1) command,
read the GCC manual for the rest of the warning options."  :-)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: a warning to implement

[Gabriel Dos Reis]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

| On Tue, 5 Feb 2002, Phil Edwards wrote:
| > I agree that the warning shouldn't be in -Wall, but I think we could do
| > a better job of educating our users about the GCC features which are not
| > as well-known.  Non-Wall warnings seem to fall into this category.
| 
| New options like these should go into release announcements.

I think that is a very good starting point.

-- Gaby

Re: a warning to implement

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| >>Except when T = char or unsigned char.
| 
| Please explain why you think this is an exception?

Clearly that is spelt out in the C standard -- I think the same
applies in C++ (I'll quote appropriate text later).  It has always
been an established practice in C and C++ to examine raw memory with
objects of character type.

6.2.6.1/5

  Certain object representations need not represent a value of the
  object type.  If the stored value of the object has such a
  representation and is read by an lvalue expression that does not
  have character type, the behavior is undefined.  If such a
  representation is produced by a side effect thaty modifies all or
  any part of the object by an lvalue expression that does not have
  character type, the behavior is undefined.  Such a representation is
  called a trap represetation.

-- Gaby

Re: a warning to implement

[Gerald Pfeifer]

On Tue, 5 Feb 2002, Phil Edwards wrote:
> I agree that the warning shouldn't be in -Wall, but I think we could do
> a better job of educating our users about the GCC features which are not
> as well-known.  Non-Wall warnings seem to fall into this category.

New options like these should go into release announcements.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: a warning to implement

[Robert Dewar]

>>Except when T = char or unsigned char.

Please explain why you think this is an exception?

Re: a warning to implement

[Gabriel Dos Reis]

Nathan Sidwell <nathan@acm.org> writes:

| Hi,
| I've been reading this thread, and I still can't figure out how
| 	T x = x;
| as anything but undefined semantics. I'm talking C++ here.
| [3.3.1]/1 gives an example about point of declaration, and says of
| 	int x = x;
| 	Here ... is initialized with its own (indeterminate) value.
| 
| But, that assignment requires an lvalue to rvalue conversion on 'x',
| and [4.1] says
| 	'or if the object is uninitialized,... undefined behaviour'

The object isn't uninitialized; it is initialized with an
indeterminated value. The point is precisely to give an explicit hint
to the compiler to assign (if possible) to assign a singular value to
x (pretty much in the same way you might assign a SNaN to a floating
point to prevent use before explicit assignment with determinate
value. 

| So it appears that we've got undefined behaviour for any POD T.

Except when T = char or unsigned char.

| For a class T, we could be calling the copy ctor T(T const &).
| Reference binding at [8.3.1]/4 says a reference must be bound to a
| `valid object'. I suppose that it is ok to reference bind to an
| object of indeterminate value.

The following is OK:

  struct Node {
     Node* link;
     Node(Node& n) : link(&n) { }
  };

  int main()
  {
     T x = x;
  }

and is a canonical example of use for user-defined-type.

-- Gaby

Re: a warning to implement

[Robert Dewar]

I asked where it said in the documentation that

  int a = a;

has a well defined meaning, and you replied that you had
already answered that questoin, and I had ignored the answer.

Perhaps you did not read my message carefully and realize
that it was referring only to the int case?

We are only discussing warnings here for the cases where
the semantics is clearly undefined in the standard. My
question was whether gcc had given defined semantics to
any of these cases. My understanding is that the answer
to this question is no, despite your most recent message
on the subject.

Re: a warning to implement

[Nathan Sidwell]

Hi,
I've been reading this thread, and I still can't figure out how
	T x = x;
as anything but undefined semantics. I'm talking C++ here.
[3.3.1]/1 gives an example about point of declaration, and says of
	int x = x;
	Here ... is initialized with its own (indeterminate) value.

But, that assignment requires an lvalue to rvalue conversion on 'x',
and [4.1] says
	'or if the object is uninitialized,... undefined behaviour'

So it appears that we've got undefined behaviour for any POD T.

For a class T, we could be calling the copy ctor T(T const &).
Reference binding at [8.3.1]/4 says a reference must be bound to a
`valid object'. I suppose that it is ok to reference bind to an
object of indeterminate value.

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
           The voices in my head told me to say this
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk

Re: a warning to implement

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| What's going on here? You claimed in your last message that the GCC doc
| already gave a direct meaning for the case of T = int

Which part of which message claimed that?

-- Gaby

Re: a warning to implement

[Robert Dewar]

<<Ah, I think I can live with that.  However, someone gave an example of
a GNU package where self-initialization was used.  I suppose that your
proposal won't warn about his code. For T = int, I'm still not
convinced although I'm understanding your arguments.
>>

What's going on here? You claimed in your last message that the GCC doc
already gave a direct meaning for the case of T = int, but the above
message seems inconsistent with that.

Re: a warning to implement

[Robert Dewar]

>>I already did, but you choosed to ignore it.

No, sorry, I just looked at the complete file of messages from you, and
there was discussion for some cases other than int, but not for int. so
if you pointed to the doc for int, unfortunately the blasted email system
must have lost the message, so could you point it out again, sorry for
the inconvenience.

Re: a warning to implement

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| <Now you'll have to argue why you're stopping something documented used
| to work as documented.
| >>
| 
| Please explain where in the documentation the meaning of
| 
|   int x = x;
| 
| is defined.

I already did, but you choosed to ignore it.

-- Gaby

Re: a warning to implement

[Kevin Handy]

Richard Sandiford wrote:

>Gabriel Dos Reis <gdr@codesourcery.com> writes:
>
>>Richard Sandiford <rsandifo@redhat.com> writes:
>>
>>| Gabriel Dos Reis <gdr@codesourcery.com> writes:
>>| > I'm not sure I can represent on this public list, opinions expressed
>>| > on closed mailing-lists.  However, you might want to consult
>>| > c++std-core archive.  You'll discover people have use of
>>| > self-initialisation even if you cannot imagine such use.
>>| 
>>| But if gcc doesn't behave the way these people expect, that sounds
>>| like an even better reason to warn as part of -Wall.  
>>
>>Then T is a user defined type,
>>
>>   T x = x;
>>
>>should be implemented correctly by GCC.
>>
>>| If gcc
>>| implements the intended behaviour at some point in the future,
>>| we could stop -Wself-initialization or whatever from warning
>>| about those cases.
>>
>>Now you'll have to argue why you're stopping something documented used
>>to work as documented.
>>
>
>My suggestion was to warn only about cases when we can detect the
>behaviour is not documented or well-defined.  The option itself could be
>documented that way.  If the behaviour of more self-initializers becomes
>defined over time, the number of cases we warn about would go down.
>
>From that point of view, the warning wouldn't trigger for:
>
>    T x = x;
>
>in the well-defined cases you're talking about, but would, for example,
>when T==int (which was the example that the original poster gave).  If
>the warning worked that way, would it be OK for -Wall?
>
Probably a dumb question, but shouldn't this error be noticed in the
same way that code like

    int a;
    int b;
    b = a;

would be? Shouldn't you already be seeing a 'used before initialized' 
warning?

Re: a warning to implement

[Robert Dewar]

<<My suggestion was to warn only about cases when we can detect the
behaviour is not documented or well-defined.  The option itself could be
documented that way.  If the behaviour of more self-initializers becomes
defined over time, the number of cases we warn about would go down.
>>

Of course no one is suggesting warnings where the meaning is well defined.
Just keep focussed on

  int a = a;

which is the focus of this discussion, has no known or defined meaning,
cannot be used today with any useful effect, is known to be undefined,
and which should give a warning!

Re: a warning to implement

[Akim Demaille]

>>>>> "Akim" == Akim Demaille <akim@epita.fr> writes:

Akim> I won't answer about int, but for instance for int *,

Akim>         int *a = a;

Akim> is very helpful: it allows me to introduce distinguished
Akim> pointers, in addition to NULL.  It's used for instance in the
Akim> idutils's lib/hash.c.

Arg.  Stupid me.  Of course I meant

        void *a = &a;

which makes my point moot as its no longer a = a.

Re: a warning to implement

[Robert Dewar]

<Now you'll have to argue why you're stopping something documented used
to work as documented.
>>

Please explain where in the documentation the meaning of

  int x = x;

is defined. I can't find it.

Re: a warning to implement

[Robert Dewar]

<<So it looks like there is divine permission for a warning :-)  (yes I know
Bjarne is not the standard).
>>

No, but one can hadly fault his reasonable statement here, which is a nice
summing up of this strange thread.

Re: a warning to implement

[Gabriel Dos Reis]

Richard Sandiford <rsandifo@redhat.com> writes:

[...]

| > Now you'll have to argue why you're stopping something documented used
| > to work as documented.
| 
| My suggestion was to warn only about cases when we can detect the
| behaviour is not documented or well-defined.  The option itself could be
| documented that way.  If the behaviour of more self-initializers becomes
| defined over time, the number of cases we warn about would go down.

Ah, I think I can live with that.  However, someone gave an example of
a GNU package where self-initialization was used.  I suppose that your
proposal won't warn about his code. For T = int, I'm still not
convinced although I'm understanding your arguments. 

-- Gaby

Re: a warning to implement

[Richard Sandiford]

Gabriel Dos Reis <gdr@codesourcery.com> writes:
> Richard Sandiford <rsandifo@redhat.com> writes:
> 
> | Gabriel Dos Reis <gdr@codesourcery.com> writes:
> | > I'm not sure I can represent on this public list, opinions expressed
> | > on closed mailing-lists.  However, you might want to consult
> | > c++std-core archive.  You'll discover people have use of
> | > self-initialisation even if you cannot imagine such use.
> | 
> | But if gcc doesn't behave the way these people expect, that sounds
> | like an even better reason to warn as part of -Wall.  
> 
> Then T is a user defined type,
> 
>    T x = x;
> 
> should be implemented correctly by GCC.
>
> | If gcc
> | implements the intended behaviour at some point in the future,
> | we could stop -Wself-initialization or whatever from warning
> | about those cases.
> 
> Now you'll have to argue why you're stopping something documented used
> to work as documented.

My suggestion was to warn only about cases when we can detect the
behaviour is not documented or well-defined.  The option itself could be
documented that way.  If the behaviour of more self-initializers becomes
defined over time, the number of cases we warn about would go down.

From that point of view, the warning wouldn't trigger for:

    T x = x;

in the well-defined cases you're talking about, but would, for example,
when T==int (which was the example that the original poster gave).  If
the warning worked that way, would it be OK for -Wall?

Richard

Re: a warning to implement

[Gabriel Dos Reis]

Richard Sandiford <rsandifo@redhat.com> writes:

| Gabriel Dos Reis <gdr@codesourcery.com> writes:
| > I'm not sure I can represent on this public list, opinions expressed
| > on closed mailing-lists.  However, you might want to consult
| > c++std-core archive.  You'll discover people have use of
| > self-initialisation even if you cannot imagine such use.
| 
| But if gcc doesn't behave the way these people expect, that sounds
| like an even better reason to warn as part of -Wall.  

Then T is a user defined type,

   T x = x;

should be implemented correctly by GCC.

| If gcc
| implements the intended behaviour at some point in the future,
| we could stop -Wself-initialization or whatever from warning
| about those cases.

Now you'll have to argue why you're stopping something documented used
to work as documented.

-- Gaby

Re: a warning to implement

[Richard Sandiford]

Gabriel Dos Reis <gdr@codesourcery.com> writes:
> I'm not sure I can represent on this public list, opinions expressed
> on closed mailing-lists.  However, you might want to consult
> c++std-core archive.  You'll discover people have use of
> self-initialisation even if you cannot imagine such use.

But if gcc doesn't behave the way these people expect, that sounds
like an even better reason to warn as part of -Wall.  If gcc
implements the intended behaviour at some point in the future,
we could stop -Wself-initialization or whatever from warning
about those cases.

Out of interest: most of the discussion seems to have been about
"int x = x;".  Do these uses give a meaning to more complex
initializers like "int x = (2 * x) + foo();" as well?

Richard

Re: a warning to implement

[Daniel Egger]

Am Die, 2002-02-05 um 19.37 schrieb Gabriel Dos Reis:

> That argument is flawed:  there are plenty of warning not included in
> -Wall and yet actually used by people.

I often wonderen why -Wall is called -Wall when it doesn't include all
-W options. I really care about everything the compiler has to say
because there're sometimes some nice hints in it. Picking all the
options a particular compiler version offers is really a PITA when 
switching between several compilers every few minutes; wouldn't it
make sense to have a -Wreally-all (alternativly: -Wparanoid) which would
flip really all -W switches on and make it much simpler to go back and
forth between several gcc versions. 
 
-- 
Servus,
       Daniel

Re: a warning to implement

[Akim Demaille]

>>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:

Robert> Gaby, perhaps you could be so kind as to enlighten us with the
Robert> wonderful useful meanings that people argued for

Robert>   int a = a;

Robert> perhaps we will be so impressed by the suggestions that we
Robert> will decide to implement one of them, rather than generating a
Robert> warning here. The only suggestion I saw, which was to use this
Robert> construct to turn off warnings, seemed very peculiar and ill
Robert> motivated. In other words, you could artificially make it have
Robert> this meaning, but I would find that most peculiar.

I won't answer about int, but for instance for int *,

        int *a = a;

is very helpful: it allows me to introduce distinguished pointers, in
addition to NULL.  It's used for instance in the idutils's lib/hash.c.

Re: a warning to implement

[Jeremy Sanders]

(apologies if you use threading - it's hard to reply to the digest mode)

Interestingly Bjarne Stroustrup writes in The C++ Programming Language
(Special Edition), Section 4.9.4:

<<
The scope of a name starts at its point of declaration; that is, after the
complete declarator and before the initializer. This implies that a name
can be used even to specify its own initial value. For example:

int x;
void f3()
{
 int x = x; // perverse: initialise x with its own (unitialised) value
}

This is not illegal, just silly. A good compiler will warn if a variable
is used before it has been set (also see Section 5.9[9]).
>>

So it looks like there is divine permission for a warning :-)  (yes I know
Bjarne is not the standard).

Jeremy

-- 
Jeremy Sanders <jss@ast.cam.ac.uk>  http://www-xray.ast.cam.ac.uk/~jss/
Pembroke College, Cambridge. UK   Institute of Astronomy, Cambridge. UK

Re: a warning to implement

[Robert Dewar]

<<I've only proposed it as a feature.  I don't think this is
documented as such.
>>

So no one could actually be using 

int a = a;

for any useful purpose right now as I understand it, so I am at a complete
loss to understand Gaby's claim that some people think this is useful.
I could see how some people might be able to give it a useful meaning
(but I object in principle to encouraging people to write undefined C
counting on it to have peculiar meanings in compiler), but Gaby claimed
that some people think it is useful now, and I just can't understand that.

Re: a warning to implement

[Alexandre Oliva]

On Feb  6, 2002, dewar@gnat.com (Robert Dewar) wrote:

> One thing I realize I am confused about now, is it *currently* the case
> that gcc documents that

>    int a = a;

> suppresses warnings on a, or is this just a proposed feature?

I've only proposed it as a feature.  I don't think this is
documented as such.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: a warning to implement

[Robert Dewar]

<<I'm not sure I can represent on this public list, opinions expressed
on closed mailing-lists.  However, you might want to consult
c++std-core archive.  You'll discover people have use of
self-initialisation even if you cannot imagine such use.
>>

Well they can only have "use" of this if the compiler in question defines
some special effect. Otherwise they are writing undefined stuff that could
have an arbitrary effect, and I really don't see how that could ever be
useful.

Re: a warning to implement

[Robert Dewar]

One thing I realize I am confused about now, is it *currently* the case
that gcc documents that

   int a = a;

suppresses warnings on a, or is this just a proposed feature? I certainly
never read anything like this in the documentation.

Re: a warning to implement

[Robert Dewar]

<<As already noted it's fairly irrelevant that you find it peculiar or
useless, or anything.  What is relevant, is that there obviously are
people who think it's usefull for that purpose.  Perhaps you can suggest
an equivalent alternative to suppress the warning in question in certain
circumstances.
>>

My objection to having this suppress the warning is that it seems entirely
arbitrary. I would find it no less arbitrary to say that the warning is
suppressed if the comment /* no warnings please */ is found after
the declaration, and it would certainly be more readable. 

RE: a warning to implement

[Robert Dewar]

>>Perhaps there should be an option to enable *all* warnings?

Sounds reasonable. Too bad that the obvious name for this option is taken :-)

Actually we find in the Ada case that there are some warnings that are just
too specialized to be generally useful since they correspond to specific
style options that few people follow. For example, in Ada -gnatwd requires
that all dereferencing be explicit, rather than being implicit as allowed
by the language. This warning would generate false positives on nearly all
Ada code, but is useful to a very small minority that wish to follow this
particular style rule.

Re: a warning to implement

[Robert Dewar]

<<In almost all cases, those are warnings that are useful in particular
(not uncommon) situations, but have drawbacks that prevent them from
being useful in the general case.
>>

And if this is not the case, I would consider adding them to -Wall :-)

The meaning of -Wall should be all warnings that meet the criteria that
Tim stated (very few false positives and easily silenced with an
equivalent construct). Note that my category of things that have clearly
undefined semantics should certainly meet this criterion, since

a) there should be certainly no false positives, in the sense that C code
should not contain any undefined constructs.

b) silencing them is always possible by replacing the incorrect code with
correct code :-)

Re: a warning to implement

[Robert Dewar]

<<That argument is flawed:  there are plenty of warning not included in
-Wall and yet actually used by people.
>>

-Wall sounds to an uninitiated chap like me that it would turn on all 
warnings. That sounds useful to me. I would be surprised to find that
there were useful warnings it did not turn on. Sure in some cases there
can be an argument to leave things out of -Wall, but I think that anything
that is clearly labeled as undefined in effect should be included in -Wall,
because really here the warning is that you are straying outside the
standard. 

Of course not all warnings are about undefined constructs, some are about
constructs that are defined, but dubious, e.g. a statement that does 
nothing at all. But for constructs that are clearly undefined, I think
-Wall should include warnings about them where possible.

Re: a warning to implement

[Joe Buck]

> I am well aware of the -Wall flag, but nevertheless, it may be easier
> for people to enable ALL warnings and specifically disable those they
> wish to ignore (such as -Weff-c++, in your case) using the -Wno-* flags.

-Weff-c++ in almost everyone's case.  It can't be used with the STL unless
you bloat out most of the iterators by adding virtual destructors
(which would decrease performance by a factor of two).

RE: a warning to implement

[Richard Almquist]

I would like to see this warning in -Wall.

I would also ask that you consider generating an -WallXXX that includes 
everthing in -Wall plus additional warnings that are generally usefule 
but don't meet the criteria for -Wall. This would be useful in two cases.

1) A short easy to remember option that could be used periodcally to 
catch errors by turning on a bunch of additional warnings. You can do 
this now by explicitlly adding warnings but I, at least, can never 
remember that the names without going to the documentatiuon. As a 
result, I don't tend to do this as often as I should. In this case, I 
would be willing to wade through lots of warnings about things that 
aren't problems to get warnings about the things that are.

2) I could enable this option in my Makefile and then explicitlly turn 
off the warnings that cause problems.  As new warnings are added to 
-WallXXX, I would automatically get them. If they caused problems, I 
could explicitly disable them. In this case, I would only want a few 
warnings about things that aren't problems.  I, being lazy, am much more 
likely to open up the manual to explicitly disable warnings that are 
causing me trouble than I am to open the manual to look for warnings 
that -Wall doesn't turn on but might be useful.

Re: a warning to implement

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| <<Please, note that I'm not saying that GCC should not have an option to
| trigger the proposed warning. I'm saying that that shouldn't be on by
| default in -Wall.
| >>
| 
| I disagree, this warning should be part of -Wall, since it is a clear error
| with no defined meaning.

Constructs that are "clear errors no defined meaning" are flagged
as such: errors, not warning.  Thus, the above is flawed.

-- Gaby

Re: a warning to implement

[Robert Dewar]

<<Please, note that I'm not saying that GCC should not have an option to
trigger the proposed warning. I'm saying that that shouldn't be on by
default in -Wall.
>>

I disagree, this warning should be part of -Wall, since it is a clear error
with no defined meaning.

Re: a warning to implement

[Gabriel Dos Reis]

Phil Edwards <phil@jaj.com> writes:

[...]

|  but I think we could do
| a better job of educating our users about the GCC features which are not
| as well-known.  Non-Wall warnings seem to fall into this category.

Completely agreed.

-- Gaby

Re: a warning to implement

[Gabriel Dos Reis]

I'm not sure I can represent on this public list, opinions expressed
on closed mailing-lists.  However, you might want to consult
c++std-core archive.  You'll discover people have use of
self-initialisation even if you cannot imagine such use.

-- Gaby

Re: a warning to implement

[Phil Edwards]

On Tue, Feb 05, 2002 at 11:48:19PM +0100, Gabriel Dos Reis wrote:
> Joe Buck <jbuck@synopsys.com> writes:
> | 
> | If we add a new warning to -Wall, people will discover bugs in their code
> | quickly.  If we add a new warning but not to -Wall, 99% of gcc users will
> | be unaware of the new warning and never use it.
> 
> I'm skeptical: New warnings were added, but not in -Wall, and yet
> people got aware of it.

Yes, but only slowly, over time, as they read the manual in desparation.  :-)

I agree that the warning shouldn't be in -Wall, but I think we could do
a better job of educating our users about the GCC features which are not
as well-known.  Non-Wall warnings seem to fall into this category.

No, I don't have any immediate ideas on how to do this.  ("GCC's Feature
of the Week for this week is:  Warnings Not Included In -Wall"...)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: a warning to implement

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| <<Now, even in the case of fundamental interger type T, since the
| value of x is an inderterminate, that construct can be used to give
| an explicit hint to the compiler to handle « x » in special way --
| e.g. it may have a trap representation if used in a context where
| there were no intervening assignment which changed x's value in a
| definite way.  Pretty much, in the same of SNaNs.
| >>
| 
| Seems like a horrible kludge to me. 

"Horrible kludge" is in the eye of the beholder.

| If you want to tell the compiler
| something special, please do it in some direct way,

Such as?

-- Gaby

RE: a warning to implement

[Stephano Mariani]

I am well aware of the -Wall flag, but nevertheless, it may be easier
for people to enable ALL warnings and specifically disable those they
wish to ignore (such as -Weff-c++, in your case) using the -Wno-* flags.

I personally use -Wall -W, but I would welcome such a flag. Indeed, no
one need use it should they wish not to do so; neither should it replace
the -Wall flag, but it should exist if someone wants to use it, at their
option.

Stephano Mariani

-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
Tim Hollebeek
Sent: Tuesday, 5 February 2002 10 31
To: Stephano Mariani
Cc: 'Joe Buck'; 'Gabriel Dos Reis'; tim@hollebeek.com; 'Bernard
Dautrevaux'; dewar@gnat.com; aoliva@redhat.com; coola@ngs.ru;
gcc@gcc.gnu.org; pcarlini@unitus.it
Subject: Re: a warning to implement


> Perhaps there should be an option to enable *all* warnings?

Some warnings are particular perverse and enforce a particular coding
style (-Weff-c++ comes to mind).

Others, are valid for almost all code, and are certainly valid for ALL
code maintained by those who wish to eliminate code that might be
erroneous.  But we already have a name for that:

-Wall.

-Tim

Re: a warning to implement

[Gabriel Dos Reis]

Tim Hollebeek <tim@hollebeek.com> writes:

| On Tue, Feb 05, 2002 at 07:37:52PM +0100, Gabriel Dos Reis wrote:
| > Tim Hollebeek <tim@hollebeek.com> writes:
| > 
| > | > Please, note that I'm not saying that GCC should not have an option to
| > | > trigger the proposed warning. I'm saying that that shouldn't be on by
| > | > default in -Wall.
| > | 
| > | Then noone will have it on (because it is such a rare case they won't
| > | realize they might need it).
| > 
| > That argument is flawed:  there are plenty of warning not included in
| > -Wall and yet actually used by people.
| 
| In almost all cases, those are warnings that are useful in particular
| (not uncommon) situations, but have drawbacks that prevent them from
| being useful in the general case.

Like -Wnested-externs or missing-prototypes?

-- Gaby

Re: a warning to implement

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.com> writes:

| > Tim Hollebeek <tim@hollebeek.com> writes:
| > 
| > | > Please, note that I'm not saying that GCC should not have an option to
| > | > trigger the proposed warning. I'm saying that that shouldn't be on by
| > | > default in -Wall.
| > | 
| > | Then noone will have it on (because it is such a rare case they won't
| > | realize they might need it).
| > 
| > That argument is flawed:  there are plenty of warning not included in
| > -Wall and yet actually used by people.
| 
| If we add a new warning to -Wall, people will discover bugs in their code
| quickly.  If we add a new warning but not to -Wall, 99% of gcc users will
| be unaware of the new warning and never use it.

I'm skeptical: New warnings were added, but not in -Wall, and yet
people got aware of it.

-- Gaby

Re: a warning to implement

[Michael Matz]

Hi,

On Tue, 5 Feb 2002, Robert Dewar wrote:

> Gaby, perhaps you could be so kind as to enlighten us with the wonderful
> useful meanings that people argued for
>
>   int a = a;
>
> perhaps we will be so impressed by the suggestions that we will decide to
> implement one of them, rather than generating a warning here.

Your language is getting annoying again.

> The only suggestion I saw, which was to use this construct to turn off
> warnings, seemed very peculiar and ill motivated. In other words, you
> could artificially make it have this meaning, but I would find that
> most peculiar.

As already noted it's fairly irrelevant that you find it peculiar or
useless, or anything.  What is relevant, is that there obviously are
people who think it's usefull for that purpose.  Perhaps you can suggest
an equivalent alternative to suppress the warning in question in certain
circumstances.

Just to make one thing clear: I'm not arguing either way, if a warning
about 'T x = x;' should be in -Wall or not, or exist at all.


Ciao,
Michael.

Re: a warning to implement

[Tim Hollebeek]

> Perhaps there should be an option to enable *all* warnings?

Some warnings are particular perverse and enforce a particular coding
style (-Weff-c++ comes to mind).

Others, are valid for almost all code, and are certainly valid for ALL
code maintained by those who wish to eliminate code that might be
erroneous.  But we already have a name for that:

-Wall.

-Tim

RE: a warning to implement

[Stephano Mariani]

Perhaps there should be an option to enable *all* warnings?

Stephano Mariani

-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
Joe Buck
Sent: Tuesday, 5 February 2002 9 52
To: Gabriel Dos Reis
Cc: tim@hollebeek.com; Gabriel Dos Reis; Bernard Dautrevaux;
dewar@gnat.com; aoliva@redhat.com; coola@ngs.ru; gcc@gcc.gnu.org;
pcarlini@unitus.it
Subject: Re: a warning to implement

> Tim Hollebeek <tim@hollebeek.com> writes:
> 
> | > Please, note that I'm not saying that GCC should not have an
option to
> | > trigger the proposed warning. I'm saying that that shouldn't be on
by
> | > default in -Wall.
> | 
> | Then noone will have it on (because it is such a rare case they
won't
> | realize they might need it).
> 
> That argument is flawed:  there are plenty of warning not included in
> -Wall and yet actually used by people.

If we add a new warning to -Wall, people will discover bugs in their
code
quickly.  If we add a new warning but not to -Wall, 99% of gcc users
will
be unaware of the new warning and never use it.

Re: a warning to implement

[Robert Dewar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

<<Now, even in the case of fundamental interger type T, since the
value of x is an inderterminate, that construct can be used to give
an explicit hint to the compiler to handle « x » in special way --
e.g. it may have a trap representation if used in a context where
there were no intervening assignment which changed x's value in a
definite way.  Pretty much, in the same of SNaNs.
>>

Seems like a horrible kludge to me. If you want to tell the compiler
something special, please do it in some direct way, and not by some
very peculiar interpretation of a meaningless construct.

Re: a warning to implement

[Robert Dewar]

Gaby, perhaps you could be so kind as to enlighten us with the wonderful
useful meanings that people argued for

  int a = a;

perhaps we will be so impressed by the suggestions that we will decide to
implement one of them, rather than generating a warning here. The only
suggestion I saw, which was to use this construct to turn off warnings,
seemed very peculiar and ill motivated. In other words, you could artificially
make it have this meaning, but I would find that most peculiar.

Re: a warning to implement

[Robert Dewar]

<<I wanted to make if you're of the camp who considers signaling NaN a
nonsense, and now I think I have the answer.  And given that, I don't
consider your former assertion on my report has any sense or any value
(it tries to deny facts, i.e. the debate amoung the committee wasn't
about validity).
>>

Of course signalling Nan's make very good sense, I said nothing about
signallying Nan's, so I have no idea how you think you know what I think
about that issue (unless you perhaps read my book on microprocessors).

What I can't do is make any semantic connection between

   int a = a;

and signalling Nan's @!

Re: a warning to implement

[Tim Hollebeek]

On Tue, Feb 05, 2002 at 01:51:45PM -0800, Joe Buck wrote:
> > Tim Hollebeek <tim@hollebeek.com> writes:
> > 
> > | > Please, note that I'm not saying that GCC should not have an option to
> > | > trigger the proposed warning. I'm saying that that shouldn't be on by
> > | > default in -Wall.
> > | 
> > | Then noone will have it on (because it is such a rare case they won't
> > | realize they might need it).
> > 
> > That argument is flawed:  there are plenty of warning not included in
> > -Wall and yet actually used by people.
> 
> If we add a new warning to -Wall, people will discover bugs in their code
> quickly.  If we add a new warning but not to -Wall, 99% of gcc users will
> be unaware of the new warning and never use it.

Exactly.  The burden is on those who oppose the warning to demonstrate
that a significant number (at least 1%!!) would be inconvenienced.

This, of course, assumes that noone gets a warning that cannot be
avoided by rewriting their code.  But no such case has been posted,
and no credible case for the existence of such code has been made.

-Tim

Re: a warning to implement

[Joe Buck]

> Tim Hollebeek <tim@hollebeek.com> writes:
> 
> | > Please, note that I'm not saying that GCC should not have an option to
> | > trigger the proposed warning. I'm saying that that shouldn't be on by
> | > default in -Wall.
> | 
> | Then noone will have it on (because it is such a rare case they won't
> | realize they might need it).
> 
> That argument is flawed:  there are plenty of warning not included in
> -Wall and yet actually used by people.

If we add a new warning to -Wall, people will discover bugs in their code
quickly.  If we add a new warning but not to -Wall, 99% of gcc users will
be unaware of the new warning and never use it.

Re: a warning to implement

[Tim Hollebeek]

On Tue, Feb 05, 2002 at 07:37:52PM +0100, Gabriel Dos Reis wrote:
> Tim Hollebeek <tim@hollebeek.com> writes:
> 
> | > Please, note that I'm not saying that GCC should not have an option to
> | > trigger the proposed warning. I'm saying that that shouldn't be on by
> | > default in -Wall.
> | 
> | Then noone will have it on (because it is such a rare case they won't
> | realize they might need it).
> 
> That argument is flawed:  there are plenty of warning not included in
> -Wall and yet actually used by people.

In almost all cases, those are warnings that are useful in particular
(not uncommon) situations, but have drawbacks that prevent them from
being useful in the general case.

Name a gcc warning that generates no false positives on 99% of code,
which can be silenced by replacement with an equivalent construct, and
is not part of -Wall.

-Tim

Re: a warning to implement

[Gabriel Dos Reis]

Tim Hollebeek <tim@hollebeek.com> writes:

| > Please, note that I'm not saying that GCC should not have an option to
| > trigger the proposed warning. I'm saying that that shouldn't be on by
| > default in -Wall.
| 
| Then noone will have it on (because it is such a rare case they won't
| realize they might need it).

That argument is flawed:  there are plenty of warning not included in
-Wall and yet actually used by people.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: a warning to implement

[Tim Hollebeek]

> Please, note that I'm not saying that GCC should not have an option to
> trigger the proposed warning. I'm saying that that shouldn't be on by
> default in -Wall.

Then noone will have it on (because it is such a rare case they won't
realize they might need it).

Why can't these rare and hypothetical people with a use for 'T x = x;'
use '-Wall -Wno-warn-self-initialization' ?

It seems to me if a warning is:

1) avoidable via replacement with equivalent construct
2) generates no warnings on >90% (or >99%) of code

it belongs in -Wall.  Cater to the majority, not the minority.

Re: a warning to implement

[Gabriel Dos Reis]

Bernard Dautrevaux <Dautrevaux@microprocess.com> writes:

| > -----Original Message-----
| > From: Gabriel Dos Reis [mailto:gdr@codesourcery.com]
| > Sent: Tuesday, February 05, 2002 5:21 PM
| > To: dewar@gnat.com
| > Cc: gdr@codesourcery.com; aoliva@redhat.com; coola@ngs.ru;
| > gcc@gcc.gnu.org; pcarlini@unitus.it
| > Subject: Re: a warning to implement
| > 
| > 
| > dewar@gnat.com (Robert Dewar) writes:
| > 
| > | <<Then you're wrong because the issue of the debate wasn't 
| > whether it
| > | should be valid statement; the issue was whether it could 
| > be a useful
| > | construct -- incidentally some wanted to make it ill-formed.
| > | >>
| > | 
| > | Sorry, I can't imagine any useful use of this construct
| > 
| > That *you* can't imagine a useful use of that construct doesn't mean
| > other people don't. Other people do imagine, in the same way people
| > have uses of SNaNs.
| 
| There's a little difference here: SNaNs have a definite behaviour,

Since you're arguing from a language standard point of view, SNaNs
don't have definite behaviour, therefore I don't buy your statement:
| which is
| different from NaNs; however, from a language point of view, "int x = x;" is
| exactly equivalent to "int x;" and really different from "int x = x0;". 


Firstly, certainly the warning won't be restricted to int.  I think it
will be implemented for every object type T.  Now it you condiser the
construct 

   T x = x;

then it is not equivalent to 

   T x;

Now, even in the case of fundamental interger type T, since the
value of x is an inderterminate, that construct can be used to give
an explicit hint to the compiler to handle « x » in special way --
e.g. it may have a trap representation if used in a context where
there were no intervening assignment which changed x's value in a
definite way.  Pretty much, in the same of SNaNs.

Please, note that I'm not saying that GCC should not have an option to
trigger the proposed warning. I'm saying that that shouldn't be on by
default in -Wall.

[...]

| ALL these constructs are perfectly valid,

I'll repeat it one more time:  I'm not agruing the validity of the
construct. 

-- Gaby

RE: a warning to implement

[Bernard Dautrevaux]

> -----Original Message-----
> From: Gabriel Dos Reis [mailto:gdr@codesourcery.com]
> Sent: Tuesday, February 05, 2002 5:21 PM
> To: dewar@gnat.com
> Cc: gdr@codesourcery.com; aoliva@redhat.com; coola@ngs.ru;
> gcc@gcc.gnu.org; pcarlini@unitus.it
> Subject: Re: a warning to implement
> 
> 
> dewar@gnat.com (Robert Dewar) writes:
> 
> | <<Then you're wrong because the issue of the debate wasn't 
> whether it
> | should be valid statement; the issue was whether it could 
> be a useful
> | construct -- incidentally some wanted to make it ill-formed.
> | >>
> | 
> | Sorry, I can't imagine any useful use of this construct
> 
> That *you* can't imagine a useful use of that construct doesn't mean
> other people don't. Other people do imagine, in the same way people
> have uses of SNaNs.

There's a little difference here: SNaNs have a definite behaviour, which is
different from NaNs; however, from a language point of view, "int x = x;" is
exactly equivalent to "int x;" and really different from "int x = x0;". 

So I think it's well advised fro the compiler to warn that it doesn't do
anything with the "=x" part of the declaration, much like it warns about "if
(a = 1)" by fear it was in fact "if (a == 1)" or about "a == 0;" because it
often is a typo for "a = 0;"; in all cases there's an obvious way to avoid
the warning *in a portable way* if you really meant what was written: "int
x", "if ((a = 1) != 0)" or "(void)a;".

ALL these constructs are perfectly valid, and have perfectly correct
behaviour. We can even argue that "f() == 0;" can be used to avoid a warning
about unused return value from a call to "int f();" :-)

The fact is that in all these circumstances, GCC emit warnings. So it seems
better *for GCC* to emit a warning for "int x = x;", and to enable it for
"-Wall".

Just my .02euros

	Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

Re: a warning to implement

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| <<Then you're wrong because the issue of the debate wasn't whether it
| should be valid statement; the issue was whether it could be a useful
| construct -- incidentally some wanted to make it ill-formed.
| >>
| 
| Sorry, I can't imagine any useful use of this construct

That *you* can't imagine a useful use of that construct doesn't mean
other people don't. Other people do imagine, in the same way people
have uses of SNaNs.

-- Gaby

Re: a warning to implement

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| >>Can you imagine use of signaling NaNs?
| 
| I can't even imagine what you are suggesting, sounds like nonsense to me.

I wanted to make if you're of the camp who considers signaling NaN a
nonsense, and now I think I have the answer.  And given that, I don't
consider your former assertion on my report has any sense or any value
(it tries to deny facts, i.e. the debate amoung the committee wasn't
about validity).

-- Gaby

Re: a warning to implement

[Robert Dewar]

>>Can you imagine use of signaling NaNs?

I can't even imagine what you are suggesting, sounds like nonsense to me.

Re: a warning to implement

[Robert Dewar]

<<Then you're wrong because the issue of the debate wasn't whether it
should be valid statement; the issue was whether it could be a useful
construct -- incidentally some wanted to make it ill-formed.
>>

Sorry, I can't imagine any useful use of this construct

Yes, of course some wanted to make it ill-formed, the issue of whether
an identifier can be used in a situation like this is a standard issue
in language design.

Re: a warning to implement

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| <Well, that construct have been debated to death in the C++ committee.
| And given the length of the debate and the opinions expressed there I
| would certainly *not* characterize it as obviously dubious.  I would
| object to have it enabled by -Wall.
| >
| What possible useful semantic meaning can this statement have? I can see
| a debate in the C++ committee as to whether it should be legal or not (that's
| quite a subtle issue, and indeed could be expected to generate debate), but
| I can't imagine a debate over whether it is useful or not. So I see no basis
| for your objection.

Then you're wrong because the issue of the debate wasn't whether it
should be valid statement; the issue was whether it could be a useful
construct -- incidentally some wanted to make it ill-formed.  

Can you imagine use of signaling NaNs?

-- Gaby

Re: a warning to implement

[Andrey R. Urazov]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Sat, Feb 02, 2002 at 11:45:08AM +0100, Paolo Carlini wrote:
> indeed it looks like gcc does'nt warn. On the other hand EDG-based compilers
> emit:
> 
> "uzarov.c", line 3: warning #592: variable "x" is used before its value is set
>     int x = x;
>             ^
Are there any special keys that make the compiler you used to emit the
warning or maybe it warns about such kind of definition by default?
> I have quickly browsed GNATS for warnings and it looks like there is'nt a PR
> dealing with this. Why don't you submit one??
I've just reinstalled my system and have gcc-3.0.1. out of the box
(RedHat 7.2) and, unfortunately, there is no `gccbug' program.


                        Yours sincerely, Andrey Urazov
-- 
Computers are not intelligent.  They only think they are.
--
Sunday, February 03, 2002, 17:52:35 +0600 - Andrey R. Urazov (mailto:coola@ngs.ru)


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: a warning to implement

[Robert Dewar]

<Well, that construct have been debated to death in the C++ committee.
And given the length of the debate and the opinions expressed there I
would certainly *not* characterize it as obviously dubious.  I would
object to have it enabled by -Wall.
>
What possible useful semantic meaning can this statement have? I can see
a debate in the C++ committee as to whether it should be legal or not (that's
quite a subtle issue, and indeed could be expected to generate debate), but
I can't imagine a debate over whether it is useful or not. So I see no basis
for your objection.

Re: a warning to implement

[Andrey R. Urazov]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

On Sun, Feb 03, 2002 at 01:54:07PM +0100, Paolo Carlini wrote:
> > Are there any special keys that make the compiler you used to emit the
> > warning or maybe it warns about such kind of definition by default?
> 
> Nice question. In fact, one of them
Have a gross collection of compilers? :-)
> warns *by default*, another only if
> explicitly requested of  "strict ANSI conformance".
But ANSI does not forbids that... So most of the EDG based compilers
probably have non-orthogonal (oblique? ;-)) and inconsistent operation
control options.
> My personal opinion is that such a warning should be definitely available,
> optionally.
Concluding the discussion on the ML, I can say that it's desirable to
have compiler emit the warning when it is run with `-Wall', and, of
course, there should be option for turning off the very warning.
> You have just to go to
> 
>     http://gcc.gnu.org/cgi-bin/gnatsweb.pl
> 
> In my opinion, you should file under "change-request".
done.



                        Yours sincerely, Andrey Urazov
-- 
Hi!  I'm Larry.  This is my brother Bob, and this is my other brother
Jimbo.  We thought you might like to know the names of your assailants.
--
Sunday, February 03, 2002, 20:57:09 +0600 - Andrey R. Urazov (mailto:coola@ngs.ru)


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: a warning to implement

[Robert Dewar]

<<Concluding the discussion on the ML, I can say that it's desirable to
have compiler emit the warning when it is run with `-Wall', and, of
course, there should be option for turning off the very warning.
>>

well I see nothing special about this warning, it is just one particular
case of accessing a variable before it has a defined value, and that is
a reasonable thing to warn about in general.

Re: a warning to implement

[Paolo Carlini]

"Andrey R. Urazov" wrote:

> On the other hand EDG-based
> compilers
> > emit:
> >
> > "uzarov.c", line 3: warning #592: variable "x" is used before its
> value is set
> >     int x = x;
> >             ^
> Are there any special keys that make the compiler you used to emit the
> warning or maybe it warns about such kind of definition by default?

Nice question. In fact, one of them warns *by default*, another only if
explicitly requested of  "strict ANSI conformance".

My personal opinion is that such a warning should be definitely available,
optionally.

> > I have quickly browsed GNATS for warnings and it looks like there
> is'nt a PR
> > dealing with this. Why don't you submit one??
> I've just reinstalled my system and have gcc-3.0.1. out of the box
> (RedHat 7.2) and, unfortunately, there is no `gccbug' program.

Huh??
You have just to go to

    http://gcc.gnu.org/cgi-bin/gnatsweb.pl

In my opinion, you should file under "change-request".

Thanks,
Paolo.

Re: a warning to implement

[Alexandre Oliva]

On Feb  3, 2002, dewar@gnat.com (Robert Dewar) wrote:

>>> It's not clearly bogus.  It's explicitly allowed in the Standard.
> It is a self evident fact that *ALL* warnings are about things that are
> allowed in the standard, or instead you would be posting an error message
> so the above statement is a rather curious non-sequitur.

I see.  Point taken.  I withdraw my objection.  Thanks for keeping me
straight :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: a warning to implement

[Robert Dewar]

>>It's not clearly bogus.  It's explicitly allowed in the Standard.

It is a self evident fact that *ALL* warnings are about things that are
allowed in the standard, or instead you would be posting an error message
so the above statement is a rather curious non-sequitur.

What is bogus about int a = a; is that it clearly has no useful meaning.
You try to establish one (turn off warnings), but there is nothing either
in the standard or in any reasonable usage that would suggest this (we
might just as well say that if you put the = sign in column 43 it turns
off warnings).

If anything deserves a warning then

  int a = a;

is in the list, since it has no sensible and useful meaning, and must surely
be a mistake.

Re: a warning to implement

[Alexandre Oliva]

On Feb  2, 2002, Paolo Carlini <pcarlini@unitus.it> wrote:

>> int x = x;
>> Is there any plans for implementing the feature?

> Hi Andrey,
> indeed it looks like gcc does'nt warn. On the other hand EDG-based compilers
> emit:

> "uzarov.c", line 3: warning #592: variable "x" is used before its value is set
>     int x = x;
>             ^

> I have quickly browsed GNATS for warnings and it looks like there is'nt a PR
> dealing with this. Why don't you submit one??

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.  For example:

  int x;

  if (some condition)
    set x
  else if (some other condition)
    set x
  else
    run a function that never returns but is not marked as such
  // or consider it know that one of the conditions above is known to
  // be always true

  some statement using x

Without `int x = x;', you'd get a warning in the last statement, and
the only way to avoid it would be by introducing code that would make
the generated code less efficient.

But I agree there are times when such a warning could be useful.  It
just shouldn't be enabled with -Wall.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: a warning to implement

[Paolo Carlini]

>    int x = x;
>Is there any plans for implementing the feature?

Hi Andrey,
indeed it looks like gcc does'nt warn. On the other hand EDG-based compilers
emit:

"uzarov.c", line 3: warning #592: variable "x" is used before its value is set
    int x = x;
            ^

I have quickly browsed GNATS for warnings and it looks like there is'nt a PR
dealing with this. Why don't you submit one??

Cheers,
Paolo.

a warning to implement

[Andrey R. Urazov]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

Hello everybody,

if I'm not mistaken, gcc never warns about incorrectness of definitions
having the following form:
    int x = x;
Is there any plans for implementing the feature?

                        Yours sincerely, Andrey Urazov
-- 
There is a vast difference between the savage and civilized man, but it
is never apparent to their wives until after breakfast.
		-- Helen Rowland
--
Saturday, February 02, 2002, 15:21:32 +0600 - Andrey R. Urazov (mailto:coola@ngs.ru)


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]