WARNINGS in QNX standard header files with gcc -Wall option

Our project requires us to use gcc -Wall options on all the source code.
The QNX header files generate a lot of warnings with that options.

Any plan for QNX to fix them?

-Tony
p.s. It should be requirements for any one who sell source code to
use max warning setting whencompile the code.


Here are some examples of them.

D:/ErgTools/QNXsdk/target/qnx6/usr/include/fcntl.h:260: warning: int flock(int, int)' hides constructor for struct flo
ck’
In file included from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/sys/wait.h:20,
from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/stdlib.h:28,
from dipc_shmemdrv.cpp:33:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/signal.h:179: warning: int sigaction(int, const sigaction *, sigaction *)' h ides constructor for struct sigaction’
D:/ErgTools/QNXsdk/target/qnx6/usr/include/signal.h:213: warning: int sigstack(sigstack *, sigstack *)' hides construct or for struct sigstack’
In file included from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/stdlib.h:32,
from dipc_shmemdrv.cpp:33:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/malloc.h:117: warning: struct mallinfo mallinfo()' hides constructor for st
ruct mallinfo’

To get a little more detail - are you building C++ code? If you use
qcc instead of gcc for doing the build do the warnings go away?

Just FYI - we build everything with -Wall here at work but almost everything
we do is written in C.

chris


Tony Lee <tl_168168@yahoo.com> wrote:

Our project requires us to use gcc -Wall options on all the source code.
The QNX header files generate a lot of warnings with that options.

Any plan for QNX to fix them?

-Tony
p.s. It should be requirements for any one who sell source code to
use max warning setting whencompile the code.


Here are some examples of them.

D:/ErgTools/QNXsdk/target/qnx6/usr/include/fcntl.h:260: warning: int flock(int, int)' hides constructor for struct flo
ck’
In file included from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/sys/wait.h:20,
from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/stdlib.h:28,
from dipc_shmemdrv.cpp:33:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/signal.h:179: warning: int sigaction(int, const sigaction *, sigaction *)' h ides constructor for struct sigaction’
D:/ErgTools/QNXsdk/target/qnx6/usr/include/signal.h:213: warning: int sigstack(sigstack *, sigstack *)' hides construct or for struct sigstack’
In file included from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/stdlib.h:32,
from dipc_shmemdrv.cpp:33:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/malloc.h:117: warning: struct mallinfo mallinfo()' hides constructor for st
ruct mallinfo’


\


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

I am compiling .cpp files with qcc compiler.

-Tony

“Chris McKillop” <cdm@qnx.com> wrote in message
news:a374ka$710$2@nntp.qnx.com

To get a little more detail - are you building C++ code? If you use
qcc instead of gcc for doing the build do the warnings go away?

Just FYI - we build everything with -Wall here at work but almost
everything
we do is written in C.

chris


Tony Lee <> tl_168168@yahoo.com> > wrote:

Our project requires us to use gcc -Wall options on all the source code.
The QNX header files generate a lot of warnings with that options.

Any plan for QNX to fix them?

-Tony
p.s. It should be requirements for any one who sell source code to
use max warning setting whencompile the code.


Here are some examples of them.

D:/ErgTools/QNXsdk/target/qnx6/usr/include/fcntl.h:260: warning: int flock(int, int)' hides constructor for struct flo
ck’
In file included from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/sys/wait.h:20,
from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/stdlib.h:28,
from dipc_shmemdrv.cpp:33:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/signal.h:179: warning: int sigaction(int, const sigaction *, sigaction *)' h ides constructor for struct sigaction’
D:/ErgTools/QNXsdk/target/qnx6/usr/include/signal.h:213: warning: int sigstack(sigstack *, sigstack *)' hides construct or for struct sigstack’
In file included from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/stdlib.h:32,
from dipc_shmemdrv.cpp:33:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/malloc.h:117: warning:
struct mallinfo mallinfo()' hides constructor for st
ruct mallinfo’





\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

As far as I see -Wall will switch on all the warnings. But remember these
are just warnings, some of them can tell you that this code can lead to a
run-time
error and some simply inform that this is an unusual practice to write code
like that.
When this unusual practice is part of your design so it’s up to you to fix
it
or disable this warning. This flexibility is fine.

What is really annoing is that when compiling C++ code with templates
gcc issues error message - “instantinated from here” but it’s ok, the
compiler
is still able to generate the code!

I believe it should be fixed in gcc v3 but when it’s going to be adopted by
QSSL
nobody knows.

cheers,
Igor

“Tony Lee” <tl_168168@yahoo.com> wrote in message
news:a370sn$n3e$2@inn.qnx.com

Our project requires us to use gcc -Wall options on all the source code.
The QNX header files generate a lot of warnings with that options.

Any plan for QNX to fix them?

-Tony
p.s. It should be requirements for any one who sell source code to
use max warning setting whencompile the code.


Here are some examples of them.

D:/ErgTools/QNXsdk/target/qnx6/usr/include/fcntl.h:260: warning: int flock(int, int)' hides constructor for struct flo
ck’
In file included from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/sys/wait.h:20,
from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/stdlib.h:28,
from dipc_shmemdrv.cpp:33:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/signal.h:179: warning: int sigaction(int, const sigaction *, sigaction *)' h ides constructor for struct sigaction’
D:/ErgTools/QNXsdk/target/qnx6/usr/include/signal.h:213: warning: int sigstack(sigstack *, sigstack *)' hides construct or for struct sigstack’
In file included from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/stdlib.h:32,
from dipc_shmemdrv.cpp:33:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/malloc.h:117: warning: struct mallinfo mallinfo()' hides constructor for st
ruct mallinfo’

\

I strongly believe QNX need to fix their header files and make sure it
doesn’t
generate any warnings. They should have a few hello-world.cpp files
that include every header files and make sure they compile without warning.

it is very ugly to have warnings in the standard header files and I have
to explain to our manager why this is the case.



I use C++ template and don’t have any warning with my code with gcc/qcc.
I used version 2.95. You propably need to explicitly tell the compiler
where
to instantiate the template class.

put this in the header file
extern template class CBlockTemplateClass<128, NUM_BLK_128>;

put this in the one of cpp file.
template class CBlockTemplateClass<128, NUM_BLK_128>;

-Tony


“Igor Levko” <no_spam@nihrena.net> wrote in message
news:a378te$s38$1@inn.qnx.com

As far as I see -Wall will switch on all the warnings. But remember these
are just warnings, some of them can tell you that this code can lead to a
run-time
error and some simply inform that this is an unusual practice to write
code
like that.
When this unusual practice is part of your design so it’s up to you to fix
it
or disable this warning. This flexibility is fine.

What is really annoing is that when compiling C++ code with templates
gcc issues error message - “instantinated from here” but it’s ok, the
compiler
is still able to generate the code!

I believe it should be fixed in gcc v3 but when it’s going to be adopted
by
QSSL
nobody knows.

cheers,
Igor

“Tony Lee” <> tl_168168@yahoo.com> > wrote in message
news:a370sn$n3e$> 2@inn.qnx.com> …
Our project requires us to use gcc -Wall options on all the source code.
The QNX header files generate a lot of warnings with that options.

Any plan for QNX to fix them?

-Tony
p.s. It should be requirements for any one who sell source code to
use max warning setting whencompile the code.


Here are some examples of them.

D:/ErgTools/QNXsdk/target/qnx6/usr/include/fcntl.h:260: warning: int flock(int, int)' hides constructor for struct flo
ck’
In file included from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/sys/wait.h:20,
from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/stdlib.h:28,
from dipc_shmemdrv.cpp:33:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/signal.h:179: warning: int sigaction(int, const sigaction *, sigaction *)' h ides constructor for struct sigaction’
D:/ErgTools/QNXsdk/target/qnx6/usr/include/signal.h:213: warning: int sigstack(sigstack *, sigstack *)' hides construct or for struct sigstack’
In file included from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/stdlib.h:32,
from dipc_shmemdrv.cpp:33:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/malloc.h:117: warning:
struct mallinfo mallinfo()' hides constructor for st
ruct mallinfo’



\

I agree.

When it is possible/practicle to write code that won’t produce ANY warning
this should be done. I have always insisted that production code compile
without any warnings. Sometimes this requires type casting and spacifying
storage classes out the wazoo. OK. So be it!

But gcc/qcc does display “warning” about things that simply can’t be cast
away. I.E. No amount of syntax mumbo-gumbo will get rid of some warnings.
In this case, there should be a way to globally disable these warnings.
With Watcom you could have a global header with #pragmas to turn off
specific warnings. Perhaps this is the answer.

P.S. Since I haven’t said it for two or three days now, I hate gcc compared
to Watcom. There, I feel better already.


Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net


“Tony Lee” <tl_168168@yahoo.com> wrote in message
news:a37ekn$2pg$1@inn.qnx.com

I strongly believe QNX need to fix their header files and make sure it
doesn’t
generate any warnings. They should have a few hello-world.cpp files
that include every header files and make sure they compile without
warning.

it is very ugly to have warnings in the standard header files and I have
to explain to our manager why this is the case.



I use C++ template and don’t have any warning with my code with gcc/qcc.
I used version 2.95. You propably need to explicitly tell the compiler
where
to instantiate the template class.

put this in the header file
extern template class CBlockTemplateClass<128, NUM_BLK_128>;

put this in the one of cpp file.
template class CBlockTemplateClass<128, NUM_BLK_128>;

-Tony


“Igor Levko” <> no_spam@nihrena.net> > wrote in message
news:a378te$s38$> 1@inn.qnx.com> …
As far as I see -Wall will switch on all the warnings. But remember
these
are just warnings, some of them can tell you that this code can lead to
a
run-time
error and some simply inform that this is an unusual practice to write
code
like that.
When this unusual practice is part of your design so it’s up to you to
fix
it
or disable this warning. This flexibility is fine.

What is really annoing is that when compiling C++ code with templates
gcc issues error message - “instantinated from here” but it’s ok, the
compiler
is still able to generate the code!

I believe it should be fixed in gcc v3 but when it’s going to be adopted
by
QSSL
nobody knows.

cheers,
Igor

“Tony Lee” <> tl_168168@yahoo.com> > wrote in message
news:a370sn$n3e$> 2@inn.qnx.com> …
Our project requires us to use gcc -Wall options on all the source
code.
The QNX header files generate a lot of warnings with that options.

Any plan for QNX to fix them?

-Tony
p.s. It should be requirements for any one who sell source code to
use max warning setting whencompile the code.


Here are some examples of them.

D:/ErgTools/QNXsdk/target/qnx6/usr/include/fcntl.h:260: warning: int flock(int, int)' hides constructor for struct flo
ck’
In file included from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/sys/wait.h:20,
from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/stdlib.h:28,
from dipc_shmemdrv.cpp:33:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/signal.h:179: warning: int sigaction(int, const sigaction *, sigaction *)' h ides constructor for struct sigaction’
D:/ErgTools/QNXsdk/target/qnx6/usr/include/signal.h:213: warning: int sigstack(sigstack *, sigstack *)' hides construct or for struct sigstack’
In file included from
D:/ErgTools/QNXsdk/target/qnx6/usr/include/stdlib.h:32,
from dipc_shmemdrv.cpp:33:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/malloc.h:117: warning:
struct mallinfo mallinfo()' hides constructor for st
ruct mallinfo’





\

Bill Caroselli <qtps@earthlink.net> wrote:

When it is possible/practicle to write code that won’t produce ANY warning
this should be done. I have always insisted that production code compile
without any warnings. Sometimes this requires type casting and spacifying
storage classes out the wazoo. OK. So be it!

The sad thing is that it’s a running target. Every time you try a new
version of a compiler, there’s a chance that you’ll need to tweak your
code some more. How much readability does it make sense to sacrifice to
get rid of all the warnings from all the possible compilers, even the
stupidest ones?..

But gcc/qcc does display “warning” about things that simply can’t be cast
away. I.E. No amount of syntax mumbo-gumbo will get rid of some warnings.

Exactly. Have any other POSIX platforms managed to declare struct
sigaction and the sigaction() function without getting the “function
hides constructor” warning from g++?


Wojtek Lerch QNX Software Systems Ltd.

I use C++ template and don’t have any warning with my code with gcc/qcc.
I used version 2.95. You propably need to explicitly tell the compiler
where
to instantiate the template class.

That’s not the point, the problem is that the compiler gives error message
which is 1) not error in fact 2) absolutely meaningles. This is ugly and
confusing.
Besides this templates are perfectly fine when compiled by VC++, Borland
and Watcom compilers.

I’be been working with gcc long enough and it’s not the best compiler i
worked with.
Gcc has its pros and cons. The key point is the compiler is free so
dealing
with gcc gyus is easy, if you have any problems go and fix it yourself.
But things are quit different when you buy a development seat where the
compiler
and debugger are vital parts of the package. QSSL decided to make gcc their
default compiler - fine, then QSSL has to get the whole responsibility for
maintaning
and updating it and provide the best quality they can.

cheers,
Igor

Wojtek Lerch <wojtek_l@ottawa.com> wrote:

Bill Caroselli <> qtps@earthlink.net> > wrote:
[snip]
But gcc/qcc does display “warning” about things that simply can’t be cast
away. I.E. No amount of syntax mumbo-gumbo will get rid of some warnings.

Exactly. Have any other POSIX platforms managed to declare struct
sigaction and the sigaction() function without getting the “function
hides constructor” warning from g++?

Prepare to be astounded… :v)

Firstly, the good news. You actually have pretty good control over
what is warned about. For example the above “hides constructor” warning
is controlled by the -Wshadow option, which can be turned off with
-Wno-shadow.

But here’s the interesting thing… gcc actually knows that system
headers (which it often doesn’t have control over) have problems, and
in some cases they aren’t gonna change. So they actually disable most
warnings for headers that are ‘system’ headers, and have a special
preprossor directive -isystem that you use for your system header directories.

So what Mr Lee is seeing is a result of codewarrior or something else doing
an -I $QNX_TARGET/usr/include, since this will include the system dirs
without marking them as ‘system’.

Joy! :v)


cburgess@qnx.com

Colin Burgess <cburgess@qnx.com> wrote:

Firstly, the good news. You actually have pretty good control over
what is warned about. For example the above “hides constructor” warning
is controlled by the -Wshadow option, which can be turned off with
-Wno-shadow.

Not if your boss tells you to enable all warnings…


Wojtek Lerch QNX Software Systems Ltd.

Igor Levko wrote:

QSSL decided to make gcc their
default compiler - fine, then QSSL has to get the whole responsibility for
maintaning
and updating it and provide the best quality they can.

Agreed. QSSL seems to agree also (at least according to the VP of mktg).

Rennie

“Colin Burgess” <cburgess@qnx.com> wrote in message
news:a39ob7$43o$1@nntp.qnx.com

Wojtek Lerch <> wojtek_l@ottawa.com> > wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:
[snip]
But gcc/qcc does display “warning” about things that simply can’t be
cast
away. I.E. No amount of syntax mumbo-gumbo will get rid of some
warnings.

Exactly. Have any other POSIX platforms managed to declare struct
sigaction and the sigaction() function without getting the “function
hides constructor” warning from g++?

Prepare to be astounded… :v)

Firstly, the good news. You actually have pretty good control over
what is warned about. For example the above “hides constructor” warning
is controlled by the -Wshadow option, which can be turned off with
-Wno-shadow.

The bad news is our project requires -Wall without any exception.

But here’s the interesting thing… gcc actually knows that system
headers (which it often doesn’t have control over) have problems, and
in some cases they aren’t gonna change. So they actually disable most

I certainly hope “they” do not include QNX.

warnings for headers that are ‘system’ headers, and have a special
preprossor directive -isystem that you use for your system header
directories.

So what Mr Lee is seeing is a result of codewarrior or something else
doing
an -I $QNX_TARGET/usr/include, since this will include the system dirs
without marking them as ‘system’.

We don’t use codewarrior. Our clearcase admin controls the makefile and the
make
process so the developer can’t cheat easily. If we do that, we might
encounter
the same problem of with all the warnings in “production level” code be
discovered
by customers.

Shouldn’t the gcc pickup the “system” attribute from #include <stdlib.h>
instead of
#include “stdlib.h”.


Anyway thanks for the suggestion, but it doesn’t work. Here’s the log.


Z:\frvob_base\src\ukernel\ipc>cmake “MOD_CFLAGS=-g -W
p,-isystem,D:/ErgTools/QNXsdk/target/qnx6/usr/include” pfsw_ipc.o
============> TARGET: [FR_UINOS] pfsw_ipc.o
rm -f …/…/…/frbld/FR_UINOS/obj/ukernel/ipc/pfsw_ipc.o
qcc pfsw_ipc.cpp -xc++ -c -o
…/…/…/frbld/FR_UINOS/obj/ukernel/ipc/pfsw_ipc.o -V
gcc_ntox86 -fPIC -Wshadow -Wmissing-p
rototypes -Wmissing-declarations -Wall -D_POSIX_C_SOURCE=POSIX_VERSION -D_
EXTENSIONS__ -D__EXT_XOPEN_EX -DHW=FR -DIMAG
E=UINOS -g -W
p,-isystem,D:/ErgTools/QNXsdk/target/qnx6/usr/include -I…/…/…/hw/FR -ID:/
ErgTools/QNXsdk/target/qnx6/us
r/include -Ih -I…/…/…/frbld/FR_UINOS/pvtexp -I…/…/global/h -I…/…/…/f
rbld/FR_UINOS/exp -I…/…/ukernel/h -I…/…/
ukernel/ns/h -I…/…/ukernel/timer/h -I…/…/ukernel/trace/h
In file included from pfsw_ipc.cpp:30:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function void * std::memchr(void *, int, unsigned int)': D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:125: declaration of C function void * std::memchr(void *, int, unsi
gned int)’ conflicts with
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:49: previous declaration
const void * std::memchr(const void *, int , unsigned int)' here D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function void *
std::memchr(void *, int, unsigned int)’:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:127: passing const void *' as argument 1 of std::memchr(void *, in
t, unsigned int)’ discards qualifiers
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char * std::strchr(char *, int)': D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:130: declaration of C function char * std::strchr(char *, int)’ con
flicts with
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:50: previous declaration
const char * std::strchr(const char *, int )' here D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char *
std::strchr(char *, int)’:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:132: passing const char *' as argument 1 of std::strchr(char *, in
t)’ discards qualifiers
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char * std::strpbrk(char *, const char *)': D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:135: declaration of C function char * std::strpbrk(char *, const ch
ar *)’ conflicts with
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:51: previous declaration
const char * std::strpbrk(const char *, co nst char *)' here D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char *
std::strpbrk(char *, const char *)’:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:137: passing const char *' as argument 1 of std::strpbrk(char *, c
onst char *)’ discards qualifiers
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char * std::strrchr(char *, int)': D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:140: declaration of C function char * std::strrchr(char *, int)’ co
nflicts with
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:52: previous declaration
const char * std::strrchr(const char *, in t)' here D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char *
std::strrchr(char *, int)’:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:142: passing const char *' as argument 1 of std::strrchr(char *, i
nt)’ discards qualifiers
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char * std::strstr(char *, const char *)': D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:145: declaration of C function char * std::strstr(char *, const cha
r *)’ conflicts with
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:53: previous declaration
const char * std::strstr(const char *, con st char *)' here D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char *
std::strstr(char *, const char *)’:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:147: passing const char *' as argument 1 of std::strstr(char *, co
nst char *)’ discards qualifiers
cc: d:/ergtools/QNXsdk/host/win32/usr/gcc/lib/gcc-lib/ntox86/2.95.2/cc1plus
caught signal 33
============> Done with target: [FR_UINOS] pfsw_ipc.o _____________________


Joy! :v)


cburgess@qnx.com

Anyway thanks for the suggestion, but it doesn’t work. Here’s the log.

Doh! I forgot that one. I think I’ve found why this is happening, but
it involves a code change to the compiler. This is because there
is a switch in gcc that specifies that system headers have an implicit
extern “C” around them - it was set, and we don’t want it. :v(

This will be fixed for the 6.2 toolset.

In the meantime, adding

#pragma GCC system_header

to the /usr/include/* header files with
problems will suppress warnings in just those headers files, by
indicating that they are system headers but fortunately not setting
the implicit extern “C”

Z:\frvob_base\src\ukernel\ipc>cmake “MOD_CFLAGS=-g -W
p,-isystem,D:/ErgTools/QNXsdk/target/qnx6/usr/include” pfsw_ipc.o
============> TARGET: [FR_UINOS] pfsw_ipc.o
rm -f …/…/…/frbld/FR_UINOS/obj/ukernel/ipc/pfsw_ipc.o
qcc pfsw_ipc.cpp -xc++ -c -o
…/…/…/frbld/FR_UINOS/obj/ukernel/ipc/pfsw_ipc.o -V
gcc_ntox86 -fPIC -Wshadow -Wmissing-p
rototypes -Wmissing-declarations -Wall -D_POSIX_C_SOURCE=POSIX_VERSION -D_
EXTENSIONS__ -D__EXT_XOPEN_EX -DHW=FR -DIMAG
E=UINOS -g -W
p,-isystem,D:/ErgTools/QNXsdk/target/qnx6/usr/include -I…/…/…/hw/FR -ID:/
ErgTools/QNXsdk/target/qnx6/us
r/include -Ih -I…/…/…/frbld/FR_UINOS/pvtexp -I…/…/global/h -I…/…/…/f
rbld/FR_UINOS/exp -I…/…/ukernel/h -I…/…/
ukernel/ns/h -I…/…/ukernel/timer/h -I…/…/ukernel/trace/h
In file included from pfsw_ipc.cpp:30:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function void * std::memchr(void *, int, unsigned int)': D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:125: declaration of C function void * std::memchr(void *, int, unsi
gned int)’ conflicts with
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:49: previous declaration
const void * std::memchr(const void *, int , unsigned int)' here D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function void *
std::memchr(void *, int, unsigned int)’:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:127: passing const void *' as argument 1 of std::memchr(void *, in
t, unsigned int)’ discards qualifiers
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char * std::strchr(char *, int)': D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:130: declaration of C function char * std::strchr(char *, int)’ con
flicts with
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:50: previous declaration
const char * std::strchr(const char *, int )' here D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char *
std::strchr(char *, int)’:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:132: passing const char *' as argument 1 of std::strchr(char *, in
t)’ discards qualifiers
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char * std::strpbrk(char *, const char *)': D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:135: declaration of C function char * std::strpbrk(char *, const ch
ar *)’ conflicts with
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:51: previous declaration
const char * std::strpbrk(const char *, co nst char *)' here D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char *
std::strpbrk(char *, const char *)’:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:137: passing const char *' as argument 1 of std::strpbrk(char *, c
onst char *)’ discards qualifiers
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char * std::strrchr(char *, int)': D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:140: declaration of C function char * std::strrchr(char *, int)’ co
nflicts with
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:52: previous declaration
const char * std::strrchr(const char *, in t)' here D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char *
std::strrchr(char *, int)’:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:142: passing const char *' as argument 1 of std::strrchr(char *, i
nt)’ discards qualifiers
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char * std::strstr(char *, const char *)': D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:145: declaration of C function char * std::strstr(char *, const cha
r *)’ conflicts with
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:53: previous declaration
const char * std::strstr(const char *, con st char *)' here D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h: In function char *
std::strstr(char *, const char *)’:
D:/ErgTools/QNXsdk/target/qnx6/usr/include/string.h:147: passing const char *' as argument 1 of std::strstr(char *, co
nst char *)’ discards qualifiers
cc: d:/ergtools/QNXsdk/host/win32/usr/gcc/lib/gcc-lib/ntox86/2.95.2/cc1plus
caught signal 33
============> Done with target: [FR_UINOS] pfsw_ipc.o _____________________



Joy! :v)


cburgess@qnx.com

cburgess@qnx.com

“Colin Burgess” <cburgess@qnx.com> wrote in message
news:a3a3fa$d2n$1@nntp.qnx.com

Doh! I forgot that one. I think I’ve found why this is happening, but
it involves a code change to the compiler. This is because there
is a switch in gcc that specifies that system headers have an implicit
extern “C” around them - it was set, and we don’t want it. :v(

This will be fixed for the 6.2 toolset.

This is actually a little disappointing. I men that I was hoping that 6.2

was much closer to being released. If you can add a new fix now that means
that QSSL is not yet that far along the QC path yet.


In the meantime, adding

#pragma GCC system_header

to the /usr/include/* header files with
problems will suppress warnings in just those headers files, by
indicating that they are system headers but fortunately not setting
the implicit extern “C”

I know that many others complain about the “unreadability” of #pragmas. But

I like this solution. We had #pragmas sprinkeled throughout our header
files. This enables us to compile everything with the “Barf on All Errors
and Warnings” option but at the same time to say "I know the compiler will
bitch about this but it isn’t really an error. It’s really just like
casting away a warning.


Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net