This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Warnings in the C++ Front-End and GCC in General
- To: mark at markmitchell dot com
- Subject: Re: Warnings in the C++ Front-End and GCC in General
- From: Manfred Hollstein <manfred at s-direktnet dot de>
- Date: Mon, 7 Sep 1998 18:54:22 +0200 (MEST)
- Cc: egcs-patches at cygnus dot com, egcs at cygnus dot com, jason at cygnus dot com
- References: <199809070744.AAA11440@smtp.earthlink.net>
- Reply-To: manfred at s-direktnet dot de, Manfred dot Hollstein at ks dot sel dot alcatel dot de
First of all, thank you very much, Mark! I really like the idea of
turning warnings on and off from inside the source files; and I agree,
using #pragma is the way to go!
I anybody disagrees this would be useful, you should try to #include
e.g. X11R5 C header files on Sun/Solaris from within your C++ code ;-)
Due to missing "int" return types, you're getting spat by lots of
warnings...
I've already implemented this several years ago (somewhere between
gcc-2.2.2 and 2.6.3), perhaps I'll even be able to locate those
patches again. May I suggest one addition, though:
In addition to switching warnings on and off, it would be
useful to "restore" a warning flag's state to its previous
state.
I believe this is the only way to use this feature inside "common"
include files, because you normally do not know which warning flags a
particular project is using, i.e what to do at the end of a .h file?
Something like
#ifndef _common_include_file_h
# define _common_include_file_h
...
#pragma gcc_disable_warn (62)
...
#pragma gcc_restore_warn (62)
...
#endif
will then leave the warning flag's status untouched after this file has
been #include'd.
What do you think?
manfred