Using qcc from PhAB on a C++ file I get many of this very annoying
warning:
…/callbacks.cc:23: warning: `my_type * ptr’ might be used
uninitialized in this function
The lines of code that would produce this look something like this:
my_type * ptr; // this line is flagged with this warning.
ptr = something_that_returns_a_my_type_ptr();
The PhAB command line looks like this:
qcc -Vgcc_ntox86_gpp -w8 -O -O3 -fomit-frame-pointer
-I. -c -o callbacks.o …/callbacks.cc
How can I disable this annoying warning?
(Yes in know I can assign to it when it is declaired, but I don’t
want to.)
I do like to keep my warning level set very high. But I don’t
consider this a valid warning.
P.S. Other C++ compilers (who shall remain Watcom) can correctly
report “Used before set” warnings.
Can you post the full function Bill? I tried a little demo app based on
what you described and I cannot get the warning to come out.
warn.c:
typedef struct
{
int foo;
int bar;
} my_type;
my_type* something_that_returns_a_my_type_ptr() {
return new my_type;
}
int main( int argc, char **argv )
{
my_type *ptr;
ptr = something_that_returns_a_my_type_ptr();
delete ptr;
return 0;
}
qcc -Vgcc_ntox86_gpp -w8 -O -O3 -fomit-frame-pointer -c -o warn.o warn.cc
Compiles without warning.
chris
Bill Caroselli <qtps@earthlink.net> wrote:
Using qcc from PhAB on a C++ file I get many of this very annoying
warning:
…/callbacks.cc:23: warning: `my_type * ptr’ might be used
uninitialized in this function
The lines of code that would produce this look something like this:
my_type * ptr; // this line is flagged with this warning.
ptr = something_that_returns_a_my_type_ptr();
The PhAB command line looks like this:
qcc -Vgcc_ntox86_gpp -w8 -O -O3 -fomit-frame-pointer
-I. -c -o callbacks.o …/callbacks.cc
How can I disable this annoying warning?
(Yes in know I can assign to it when it is declaired, but I don’t
want to.)
I do like to keep my warning level set very high. But I don’t
consider this a valid warning.
P.S. Other C++ compilers (who shall remain Watcom) can correctly
report “Used before set” warnings.
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Chris McKillop <cdm@qnx.com> wrote:
Can you post the full function Bill? I tried a little demo app based on
what you described and I cannot get the warning to come out.
NO!
Well actually (blush), I had a nice example all ready to post here.
I started trimming the unrelated stuff to post the shortest example
possible. When I did the problem went away.
So I slowly started replacing lines and saw what it was really bitching
about. It was my fault. But the warning message was pointing me in
the wrong direction.
I just need to become more intimate with GNU I guess. After over a
decade I start to actually think like the Watcom compiler thinks.
When it says something I tend to know exactly what it means. I
haven’t achieved that level of intimacey with GNU yet.
Well actually (blush), I had a nice example all ready to post here.
I started trimming the unrelated stuff to post the shortest example
possible. When I did the problem went away.
So I slowly started replacing lines and saw what it was really bitching
about. It was my fault. But the warning message was pointing me in
the wrong direction.
I just need to become more intimate with GNU I guess. After over a
decade I start to actually think like the Watcom compiler thinks.
When it says something I tend to know exactly what it means. I
haven’t achieved that level of intimacey with GNU yet.
You have seen a picture of a GNU right? You might not want to get too close. 
Glad to hear you found your troubles.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
I find it annoying to get that warning as well. I often see it in a case
like:
if( (fd = open(“blah”,O_RDONLY)) != -1){
…
and get a warning about fd being uninitialized. It seems kind of dumb since
there’s no way for it to make it through that statement uninitialized.
cheers,
Kris
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:b6d48m$qhn$1@inn.qnx.com…
Chris McKillop <> cdm@qnx.com> > wrote:
Can you post the full function Bill? I tried a little demo app based on
what you described and I cannot get the warning to come out.
NO!
Well actually (blush), I had a nice example all ready to post here.
I started trimming the unrelated stuff to post the shortest example
possible. When I did the problem went away.
So I slowly started replacing lines and saw what it was really bitching
about. It was my fault. But the warning message was pointing me in
the wrong direction.
I just need to become more intimate with GNU I guess. After over a
decade I start to actually think like the Watcom compiler thinks.
When it says something I tend to know exactly what it means. I
haven’t achieved that level of intimacey with GNU yet.
-Wno-uninitialized will suppress this message
/usr/lib/gcc-lib/nto/2.95.3/cc1 --help for a list of warnings. They
can all be turned off by addign no-
Bill Caroselli <qtps@earthlink.net> wrote:
Using qcc from PhAB on a C++ file I get many of this very annoying
warning:
…/callbacks.cc:23: warning: `my_type * ptr’ might be used
uninitialized in this function
The lines of code that would produce this look something like this:
my_type * ptr; // this line is flagged with this warning.
ptr = something_that_returns_a_my_type_ptr();
The PhAB command line looks like this:
qcc -Vgcc_ntox86_gpp -w8 -O -O3 -fomit-frame-pointer
-I. -c -o callbacks.o …/callbacks.cc
How can I disable this annoying warning?
(Yes in know I can assign to it when it is declaired, but I don’t
want to.)
I do like to keep my warning level set very high. But I don’t
consider this a valid warning.
P.S. Other C++ compilers (who shall remain Watcom) can correctly
report “Used before set” warnings.
–
cburgess@qnx.com
Colin Burgess <cburgess@qnx.com> wrote:
-Wno-uninitialized will suppress this message
/usr/lib/gcc-lib/nto/2.95.3/cc1 --help for a list of warnings. They
can all be turned off by addign no-
Thank you. This is helpful.
The warning is also helpful when it is correctly issued. And like I
said, I do like to keep my warning level set very high. I have
worked at places where it was company policy that no code be accepted
unless it compiled cleanly with a maximum warning level set.
Chris McKillop wrote:
You have seen a picture of a GNU right? You might not want to get too close. >
Not to mention that the consequences of rejection can be severe 
Rennie
I have a new annoying warning.
I have a debug class that is only usful for it’s constructor and
destructor. A stripped down version looks like this:
class Tracer
{
const char * name;
public:
Tracer ( const char * fn ) : name( fn )
{ cerr << "Entered Function " << name << endl; }
~Tracer ( )
{ cerr << "Exited Function " << name << endl; }
};
Then in a function I can have:
void do_something ()
{
Tracer fn( “do_something()” );
}
and it will display every time that function is entered and exited.
But with GNU the compiler complains:
test_tracer.cc: In function void do_something()': test_tracer.cc:<line number>: warning: unused variable struct Tracer fn’
It was in fact used because of it’s construstoc & destructor.
What can I use to get rid of this warning?
Got it!
The compiler seems to like having no object name. I.E.
void do_something ()
{
Tracer ( “do_something()” );
}
Weird, but it works.
Bill Caroselli <qtps@earthlink.net> wrote:
BC > I have a new annoying warning.
BC > I have a debug class that is only usful for it’s constructor and
BC > destructor. A stripped down version looks like this:
BC > class Tracer
BC > {
BC > const char * name;
BC > public:
BC > Tracer ( const char * fn ) : name( fn )
BC > { cerr << "Entered Function " << name << endl; }
BC > ~Tracer ( )
BC > { cerr << "Exited Function " << name << endl; }
BC > };
BC > Then in a function I can have:
BC > void do_something ()
BC > {
BC > Tracer fn( “do_something()” );
BC > }
BC > and it will display every time that function is entered and exited.
BC > But with GNU the compiler complains:
BC > test_tracer.cc: In function void do_something()': BC > test_tracer.cc:<line number>: warning: unused variable struct Tracer fn’
BC > It was in fact used because of it’s construstoc & destructor.
BC > What can I use to get rid of this warning?
Nope. No cigar.
Not including an object name gets rid of the warning.
It also gets rid of the object.
Does anyone else know a work around for this?
A class is only useful for it’s constructor and destructor.
It is otherwise not referenced. But te compiler complains
about it not being referenced.
How can I get rid of this warning?
Bill Caroselli <qtps@earthlink.net> wrote:
BC > Got it!
BC > The compiler seems to like having no object name. I.E.
BC > void do_something ()
BC > {
BC > Tracer ( “do_something()” );
BC > }
BC > Weird, but it works.
BC > Bill Caroselli <qtps@earthlink.net> wrote:
BC > BC > I have a new annoying warning.
BC > BC > I have a debug class that is only usful for it’s constructor and
BC > BC > destructor. A stripped down version looks like this:
BC > BC > class Tracer
BC > BC > {
BC > BC > const char * name;
BC > BC > public:
BC > BC > Tracer ( const char * fn ) : name( fn )
BC > BC > { cerr << "Entered Function " << name << endl; }
BC > BC > ~Tracer ( )
BC > BC > { cerr << "Exited Function " << name << endl; }
BC > BC > };
BC > BC > Then in a function I can have:
BC > BC > void do_something ()
BC > BC > {
BC > BC > Tracer fn( “do_something()” );
BC > BC > }
BC > BC > and it will display every time that function is entered and exited.
BC > BC > But with GNU the compiler complains:
BC > BC > test_tracer.cc: In function void do_something()': BC > BC > test_tracer.cc:<line number>: warning: unused variable struct Tracer fn’
BC > BC > It was in fact used because of it’s construstoc & destructor.
BC > BC > What can I use to get rid of this warning?
P.S. Anyone else is free to jion in on my conversation.
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:b8pji2$40o$1@inn.qnx.com…
I have a new annoying warning.
I have a debug class that is only usful for it’s constructor and
destructor. A stripped down version looks like this:
class Tracer
{
const char * name;
public:
Tracer ( const char * fn ) : name( fn )
{ cerr << "Entered Function " << name << endl; }
~Tracer ( )
{ cerr << "Exited Function " << name << endl; }
};
Then in a function I can have:
void do_something ()
{
Tracer fn( “do_something()” );
}
and it will display every time that function is entered and exited.
Sorry can’t help you with the warning, but I wonder if the behavior you
expect is really standard. My understanding of scope says that whenever the
object isn’t use the compiler is free to decide when the desctructor is
called.
thus:
void do_something ()
{
Tracer fn( “do_something()” );
printf(“a\n”);
}
I beleive the compiler is free to called the desctructor before the
printf. In general I don’t beleive that is the case, since all compiler I
know will free object allocated on the stack when the fonction returns (in
you example) but I wonder if that behavior is defined by the language.
Try -Wno-unused
dB
“Mario Charest” postmaster@127.0.0.1 wrote in message
news:b8pq5n$aru$1@inn.qnx.com…
“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:b8pji2$40o$> 1@inn.qnx.com> …
I have a new annoying warning.
I have a debug class that is only usful for it’s constructor and
destructor. A stripped down version looks like this:
class Tracer
{
const char * name;
public:
Tracer ( const char * fn ) : name( fn )
{ cerr << "Entered Function " << name << endl; }
~Tracer ( )
{ cerr << "Exited Function " << name << endl; }
};
Then in a function I can have:
void do_something ()
{
Tracer fn( “do_something()” );
}
and it will display every time that function is entered and exited.
Sorry can’t help you with the warning, but I wonder if the behavior you
expect is really standard. My understanding of scope says that whenever
the
object isn’t use the compiler is free to decide when the desctructor is
called.
thus:
void do_something ()
{
Tracer fn( “do_something()” );
printf(“a\n”);
}
I beleive the compiler is free to called the desctructor before the
printf. In general I don’t beleive that is the case, since all compiler I
know will free object allocated on the stack when the fonction returns (in
you example) but I wonder if that behavior is defined by the language.
For some reason I can’t reproduce this (what compiler options etc?)
But you can add a attribute((unused)) to the definition
of Tracer
From the gcc html manual
unused
When attached to a type (including a union or a struct),
this attribute means that variables of that type are meant to appear
possibly unused. GNU CC will not produce a warning for any variables of
that type, even if the variable appears to do nothing. This is often
the case with lock or thread classes, which are usually defined and then
not referenced, but contain constructors and destructors that have
nontrivial bookkeeping functions.
Bill Caroselli <qtps@earthlink.net> wrote:
I have a new annoying warning.
I have a debug class that is only usful for it’s constructor and
destructor. A stripped down version looks like this:
class Tracer
{
const char * name;
public:
Tracer ( const char * fn ) : name( fn )
{ cerr << "Entered Function " << name << endl; }
~Tracer ( )
{ cerr << "Exited Function " << name << endl; }
};
Then in a function I can have:
void do_something ()
{
Tracer fn( “do_something()” );
}
and it will display every time that function is entered and exited.
But with GNU the compiler complains:
test_tracer.cc: In function void do_something()': test_tracer.cc:<line number>: warning: unused variable struct Tracer fn’
It was in fact used because of it’s construstoc & destructor.
What can I use to get rid of this warning?
–
cburgess@qnx.com
That looks like the nicest solution, Colin. FYI, I didn’t actually use
Bill’s original example, I just applied qcc (lowercase) to
main() {
int a;
return 0;
}
with -Wall -Wno-unused. The same works for gcc.
dB
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:b8r6l8$627$1@nntp.qnx.com…
For some reason I can’t reproduce this (what compiler options etc?)
But you can add a attribute((unused)) to the definition
of Tracer
From the gcc html manual
unused
When attached to a type (including a union or a struct),
this attribute means that variables of that type are meant to appear
possibly unused. GNU CC will not produce a warning for any variables of
that type, even if the variable appears to do nothing. This is often
the case with lock or thread classes, which are usually defined and then
not referenced, but contain constructors and destructors that have
nontrivial bookkeeping functions.
Bill Caroselli <> qtps@earthlink.net> > wrote:
I have a new annoying warning.
I have a debug class that is only usful for it’s constructor and
destructor. A stripped down version looks like this:
class Tracer
{
const char * name;
public:
Tracer ( const char * fn ) : name( fn )
{ cerr << "Entered Function " << name << endl; }
~Tracer ( )
{ cerr << "Exited Function " << name << endl; }
};
Then in a function I can have:
void do_something ()
{
Tracer fn( “do_something()” );
}
and it will display every time that function is entered and exited.
But with GNU the compiler complains:
test_tracer.cc: In function void do_something()': test_tracer.cc:<line number>: warning: unused variable struct Tracer
fn’
It was in fact used because of it’s construstoc & destructor.
What can I use to get rid of this warning?
\
cburgess@qnx.com
Mario Charest postmaster@127.0.0.1 wrote:
Sorry can’t help you with the warning, but I wonder if the behavior you
expect is really standard. My understanding of scope says that whenever the
object isn’t use the compiler is free to decide when the desctructor is
called.
thus:
void do_something ()
{
Tracer fn( “do_something()” );
printf(“a\n”);
}
I beleive the compiler is free to called the desctructor before the
printf.
I don’t think the C++ standard supports this belief:
Vari6.7p2: … Variables with automatic storage duration declared
in the block are destroyed on exit from the block.
“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:b8rbda$3i3$1@inn.qnx.com…
Mario Charest postmaster@127.0.0.1 wrote:
Sorry can’t help you with the warning, but I wonder if the behavior you
expect is really standard. My understanding of scope says that whenever
the
object isn’t use the compiler is free to decide when the desctructor is
called.
thus:
void do_something ()
{
Tracer fn( “do_something()” );
printf(“a\n”);
}
I beleive the compiler is free to called the desctructor before the
printf.
I don’t think the C++ standard supports this belief:
Vari6.7p2: … Variables with automatic storage duration declared
in the block are destroyed on exit from the block.
Noted, thanks!
That still sounds odd to me, I don’t see how this rules fits with compiler
reusing register for local variable (when the compiler is automaticaly
promoting the variable to register)
Thanks Colin. That’s exactly what I was looking for.
Where do I find this gcc html manual?
I have a few other QNX4 isms I’d like to look up, like:
#pragma library ("/somedir/library_name");
#pragma error “Your #defines are screwed up!” ;
Colin Burgess <cburgess@qnx.com> wrote:
CB > For some reason I can’t reproduce this (what compiler options etc?)
CB > But you can add a attribute((unused)) to the definition
CB > of Tracer
CB > From the gcc html manual
CB > unused
CB > When attached to a type (including a union or a struct),
CB > this attribute means that variables of that type are meant to appear
CB > possibly unused. GNU CC will not produce a warning for any variables of
CB > that type, even if the variable appears to do nothing. This is often
CB > the case with lock or thread classes, which are usually defined and then
CB > not referenced, but contain constructors and destructors that have
CB > nontrivial bookkeeping functions.
Mario Charest postmaster@127.0.0.1 wrote:
“Wojtek Lerch” <> wojtek_l@yahoo.ca> > wrote in message
news:b8rbda$3i3$> 1@inn.qnx.com> …
Mario Charest postmaster@127.0.0.1 wrote:
…
void do_something ()
{
Tracer fn( “do_something()” );
printf(“a\n”);
}
I beleive the compiler is free to called the desctructor before the
printf.
I don’t think the C++ standard supports this belief:
Vari6.7p2: … Variables with automatic storage duration declared
in the block are destroyed on exit from the block.
Noted, thanks!
That still sounds odd to me, I don’t see how this rules fits with compiler
reusing register for local variable (when the compiler is automaticaly
promoting the variable to register)
The code has to behave as if the variable was destroyed at the end of
the block. The compiler is free to reorder things as long as it can
prove that the reordering doesn’t change any required behaviour. In
particular, if the variable didn’t have a destructor, the compiler could
analyze its constructor and notice that the variable’s address can’t be
known to anything that printf() could possibly call, and therefore the
memory can be reused before printf() runs. But since the variable does
have a destructor, and the destructor has side effects, those
side-effects must happen after the side-effects of printf().
Bill Caroselli <qtps@earthlink.net> wrote:
Thanks Colin. That’s exactly what I was looking for.
Where do I find this gcc html manual?
http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html
I have a few other QNX4 isms I’d like to look up, like:
#pragma library ("/somedir/library_name");
There isn’t a way to do this, I’m afraid.
#pragma error “Your #defines are screwed up!” ;
#warning “Aye Carumba!”
#error "Golly gee!
should do the trick?
Colin Burgess <> cburgess@qnx.com> > wrote:
CB > For some reason I can’t reproduce this (what compiler options etc?)
CB > But you can add a attribute((unused)) to the definition
CB > of Tracer
CB > From the gcc html manual
CB > unused
CB > When attached to a type (including a union or a struct),
CB > this attribute means that variables of that type are meant to appear
CB > possibly unused. GNU CC will not produce a warning for any variables of
CB > that type, even if the variable appears to do nothing. This is often
CB > the case with lock or thread classes, which are usually defined and then
CB > not referenced, but contain constructors and destructors that have
CB > nontrivial bookkeeping functions.
–
cburgess@qnx.com