Annoying warning

bridged with qdn.public.qnxrtp.devtools
Wojtek Lerch

Re: Annoying warning

Post by Wojtek Lerch » Thu May 01, 2003 2:36 pm

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.

Mario Charest

Re: Annoying warning

Post by Mario Charest » Thu May 01, 2003 5:01 pm

"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)

Bill Caroselli

Re: Annoying warning

Post by Bill Caroselli » Thu May 01, 2003 7:03 pm

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.

Wojtek Lerch

Re: Annoying warning

Post by Wojtek Lerch » Thu May 01, 2003 7:28 pm

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().

Colin Burgess

Re: Annoying warning

Post by Colin Burgess » Thu May 01, 2003 7:33 pm

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

Bill Caroselli

Re: Annoying warning

Post by Bill Caroselli » Thu May 01, 2003 7:36 pm

Thanks again very much Colin, for all of your help.

Colin Burgess <cburgess@qnx.com> wrote:
CB > Bill Caroselli <qtps@earthlink.net> wrote:
Thanks Colin. That's exactly what I was looking for.

Where do I find this gcc html manual?
CB > 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");
CB > There isn't a way to do this, I'm afraid.
#pragma error "Your #defines are screwed up!" ;
CB > #warning "Aye Carumba!"
CB > #error "Golly gee!

CB > should do the trick?

Bill Caroselli

Re: Annoying warning

Post by Bill Caroselli » Thu May 01, 2003 7:39 pm

Wojtek Lerch <wojtek_l@yahoo.ca> wrote:
WL > The code has to behave *as if* the variable was destroyed at the end of
WL > the block. The compiler is free to reorder things as long as it can
WL > prove that the reordering doesn't change any required behaviour. In
WL > particular, if the variable didn't have a destructor, the compiler could
WL > analyze its constructor and notice that the variable's address can't be
WL > known to anything that printf() could possibly call, and therefore the
WL > memory can be reused before printf() runs. But since the variable does
WL > have a destructor, and the destructor has side effects, those
WL > side-effects must happen after the side-effects of printf().

Years ago, the "bible" on the C++ language was the ARM (Annotated
Reference Manual). The language has evolved a lot since then but I
don't think the ARM has kept up with it.

What is the current "bible" of the C++ language?
Is it available on line?

Wojtek Lerch

Re: Annoying warning

Post by Wojtek Lerch » Fri May 02, 2003 1:47 pm

Bill Caroselli <qtps@earthlink.net> wrote:
Years ago, the "bible" on the C++ language was the ARM (Annotated
Reference Manual). The language has evolved a lot since then but I
don't think the ARM has kept up with it.

What is the current "bible" of the C++ language?
The ISO C++ standard. ISO/IEC 14882:1998.
Is it available on line?
You can buy a PDF copy from ANSI for $18:

http://webstore.ansi.org/ansidocstore/p ... 882%2D1998

Make sure to read the license agreement first -- some people on
comp.std.c have claimed that it allows ANSI to sue you too easily.
(That was actually about the license for the C standard, not C++, but I
suspect the agreement is either identical or very similar.)

Bill Caroselli

Annoying warning (But this time the compiler's right!

Post by Bill Caroselli » Wed May 07, 2003 10:22 pm

I'm porting some QNX4 photon code. My projects with maximum warning
level set. When compiling a C++ module with maximum warnings set and
including photon/PtTree.h I get:
/usr/include/photon/PtTree.h:201: warning: cast discards qualifiers from pointer target type

The line(s) in question read:
inline int PtTreeItemIndex(
const PtWidget_t *tree, const PtTreeItem_t *item
) {
return PtGenTreeItemIndex( tree, (PtGenTreeItem_t*) item );
}

But they *should read:
inline int PtTreeItemIndex(
const PtWidget_t *tree,
const PtTreeItem_t *item )
{
return PtGenTreeItemIndex( tree, (const PtGenTreeItem_t*) item );
}

This simply maintains the 'const' in the typecast. The compiler is
right and QSSL should fix their header file(s).

I have also found:
/usr/include/photon/PtImageTree.h:163: warning: cast discards qualifiers from pointer target type
It is the exact same situation.

I'm sure there are other's.

Is there some way that QSSL can compile all of their header files with maximum warning levels set to find all instances where things were insufficiently typecast?

Wojtek Lerch

Re: Annoying warning (But this time the compiler's right!

Post by Wojtek Lerch » Thu May 08, 2003 3:50 pm

Bill Caroselli <qtps@earthlink.net> wrote:
I'm porting some QNX4 photon code. My projects with maximum warning
level set. When compiling a C++ module with maximum warnings set and
including photon/PtTree.h I get:
/usr/include/photon/PtTree.h:201: warning: cast discards qualifiers from pointer target type

This simply maintains the 'const' in the typecast. The compiler is
right and QSSL should fix their header file(s).
The compiler is right, but only in the sense that the compiler is free
to warn you about anything it wishes to. What matters is that it
doesn't refuse to compile correct code; and code that casts away the
constness of a pointer is not incorrect, even if it does it
unnecessarily.

But in this case I agree that *not* doing it is better. I'll fix it. :-)
Is there some way that QSSL can compile all of their header files with
maximum warning levels set to find all instances where things were
insufficiently typecast?
But in this case, things are sufficiently typecast, as far as the
language is concerned; it's just that according to GCC's preferences,
such a typecast is suspicious enough to deserve a warning at the highest
warning level.

Personally, I don't think it's a good idea to make following GCC's
preferences a policy that you have to obey at all cost. Especially if
you consider porting your code to other compilers that might have
different preferences. Of course, *we* shouldn't make that decision for
our customers; I agree that it's better if our headers don't generate
unnecessary warnings. But I would be upset if I were told that my
*code* must compile without warnings from gcc at -w9.

GCC can be really annoying when you turn the warnings too high. I
really hate how it wants you to stick superfluous parentheses and braces
everywhere. Or that when you actually do need to convert a const
pointer to a non-const pointer (in C), there's no way to do it without
getting a warning unless you do something really horrible like this:

void *p; void const *cp;
p = (void*) cp; // Warning!
memcpy( &p, &cp, sizeof(p) ); // Eeew! But no warning.

Bill Caroselli

Re: Annoying warning (But this time the compiler's right!

Post by Bill Caroselli » Thu May 08, 2003 8:06 pm

Having spent another day with the compiler I asm starting to agree
with you. Using -w9 is just rediculous in the things it complains
about.

-w8 seems almost usable.

Wojtek Lerch <wojtek_l@yahoo.ca> wrote:
WL > GCC can be really annoying when you turn the warnings too high. I
WL > really hate how it wants you to stick superfluous parentheses and braces
WL > everywhere. Or that when you actually do need to convert a const
WL > pointer to a non-const pointer (in C), there's no way to do it without
WL > getting a warning unless you do something really horrible like this:

WL > void *p; void const *cp;
WL > p = (void*) cp; // Warning!
WL > memcpy( &p, &cp, sizeof(p) ); // Eeew! But no warning.

Bill Caroselli

Re: Annoying warning

Post by Bill Caroselli » Tue Aug 19, 2003 4:08 pm

I am porting a very large program with a small piece of code that boils
down to this:

------------
extern void fn2( int );

void fn()
{
int j=8;
for( int j=0; j<10; j++ )
{
fn2( j );
}
fn2(j);
}
------------
Of interest is the assignment of j in the for loop.

When compiling with the IDE I get warning for:
Name lookup of 'j' changed for new ANSI 'for' scoping.
Using obsolute binding at 'j'.
I understand what these warning are telling me.
How can I get rid of them?

PS There are many instances of this kind of code and the
loops are sometimes quite large.

Bill Caroselli

Re: Annoying warning

Post by Bill Caroselli » Tue Oct 21, 2003 1:08 pm

I have a new annoying warning from the GCC compiler. BTW, I could
have sworn I asked this once before but I could not find that post
so I'm asking again.

I have a class called Tracer. All of the work is done in the
constructor and destructor. I.E. you put it at the beginning of a
function and it log when you entered and exited the functions. It can
also log the call stack, etc.

So, in code I might write:
void my_funct ( )
{
Tracer fn( "my_funct()" );
// rest of function
}

To enable this class I have a define that I must define before the
header file.

#define TracerDebugOn
#include <tracer.hpp>

If I don't want the class to do anything, in the header file I have this:


#ifndef TracerDebugOn

class Tracer
{
public:
Tracer ( const char * s, int = 5 , int = 5 ) { }
Tracer ( const char * s, const char *, int = 5 , int = 5 ) { }
static void SetLogSwitch ( void * ) {}
static void ClearLogSwitch ( ) {}
static void SetShowCalls ( ) {}
static void ClearShowCalls ( ) {}
static void ShowCalls ( ) {}
static void Spaces ( ) {}
};


#else

// the real tracer class goes here

#endif

HOWEVER, . . . . I can't get rid of this warning that says:
Warning: Unused variable 'class Tracer fn'

It *IS* perfectly valid to have an object that is not referenced except
for it's constructor and destructor.

How can I get rid of this warning?

Garry Turcotte

Re: Annoying warning

Post by Garry Turcotte » Tue Oct 21, 2003 2:04 pm

[snip]
static void ShowCalls ( ) {}
static void Spaces ( ) {}
} __attribute__((unused));

.... should get rid of the warning.

Colin Burgess

Re: Annoying warning

Post by Colin Burgess » Tue Oct 21, 2003 2:09 pm

Tracer fn( "my_funct()" ) __attribute__((unused));

should do it..

Bill Caroselli <qtps@earthlink.net> wrote:
I have a new annoying warning from the GCC compiler. BTW, I could
have sworn I asked this once before but I could not find that post
so I'm asking again.

I have a class called Tracer. All of the work is done in the
constructor and destructor. I.E. you put it at the beginning of a
function and it log when you entered and exited the functions. It can
also log the call stack, etc.

So, in code I might write:
void my_funct ( )
{
Tracer fn( "my_funct()" );
// rest of function
}

To enable this class I have a define that I must define before the
header file.

#define TracerDebugOn
#include <tracer.hpp

If I don't want the class to do anything, in the header file I have this:
#ifndef TracerDebugOn

class Tracer
{
public:
Tracer ( const char * s, int = 5 , int = 5 ) { }
Tracer ( const char * s, const char *, int = 5 , int = 5 ) { }
static void SetLogSwitch ( void * ) {}
static void ClearLogSwitch ( ) {}
static void SetShowCalls ( ) {}
static void ClearShowCalls ( ) {}
static void ShowCalls ( ) {}
static void Spaces ( ) {}
};
#else

// the real tracer class goes here

#endif

HOWEVER, . . . . I can't get rid of this warning that says:
Warning: Unused variable 'class Tracer fn'

It *IS* perfectly valid to have an object that is not referenced except
for it's constructor and destructor.

How can I get rid of this warning?
--
cburgess@qnx.com

Post Reply

Return to “qdn.public.qnxrtp.devtools”