How to ignore Wall errors for a portion of code

How to ignore Wall errors for a portion of code

[Joezac Zachariah]

i,

I am compiling a C code with -Wall -Werror options. In my File I am 
including another C file which has many Wall errors, which I don't want 
to check for. Is there a way I can exclude some portion of code from a 
given file using some kind of #define scheme

void func1()
{
.......
}

#define DISABLE_WERROR 1
include myfile.c
#undef ENABLE_WERROR

void func2()
{
..............
}

Thanks,
Joezac

Re: How to ignore Wall errors for a portion of code

[Tim Prince]

Joezac Zachariah wrote:
>
>
>
> I am compiling a C code with -Wall -Werror options. In my File I am 
> including another C file which has many Wall errors, which I don't 
> want to check for. Is there a way I can exclude some portion of code 
> from a given file
The usual way is to use make

http://www.gnu.org/software/make/manual/make.html

Re: How to ignore Wall errors for a portion of code

[Joezac Zachariah]

Hi,

Thanks for your fast response. I am not sure whether my query was clear. 
I am using 'make' to compile the code and I am passing -Wall -Werror 
options. My requirement is that the Wall checks need to be done only on 
a portion of the code in a given '.c' file and not on the complete file. 
Is there a way or a Wall option with which I could switch the -Wall 
check 'off' for a portion of the file?

Thanks,
Joezac


Tim Prince wrote:

> Joezac Zachariah wrote:
>
>>
>>
>>
>> I am compiling a C code with -Wall -Werror options. In my File I am 
>> including another C file which has many Wall errors, which I don't 
>> want to check for. Is there a way I can exclude some portion of code 
>> from a given file
>
> The usual way is to use make
>
> http://www.gnu.org/software/make/manual/make.html
>

Re: How to ignore Wall errors for a portion of code

[John Love-Jensen]

Hi Joezac,

I do not believe there is a mechanism in GCC to do quite what you want.

There have been quite a few requests (including from myself) for inline
#pragma control over warnings generation, similar to what MSVC has in their
compiler.

However, there are several reasons why this hasn't happened.

Before I go into that history (as I poorly understand it), you may be able
to employ this mechanism to sort of do what you want:

#pragma GCC system_header

q.v. #pragma GCC system_header
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/cpp/System-Headers.html

q.v. -Wno-system-header
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Warning-Options.html

- - - - -

Many years ago, the GNU folks were strongly in disfavor of the #pragma
mechanism.  There list of objections to it were lengthy and, in my opinion,
well thought out and compelling.  So they refrained from utilizing the
#pragma mechanism as much as they could, and instead enhanced the C/C++
languages using other techniques such as __attribute__ and other extensions.

The Powers That Be in the standards committees eventually agreed with the
GNU folks, and enhanced the #pragma facilities which addressed or
compromised on all the GNU complaints against the #pragma mechanism.  There
was much rejoicing.  But due to culture or inertial, the GNUrus were not
very interested in going #pragma hog wild.

So that's the glossy overview of the #pragma backstory.

- - - - -

The warning story is a bit different.

In the beginning, there were expensive, powerful compilers that would reject
dicey code.  To make compilers smaller and faster, the C compiler writers
decided to separate that diagnostic functionality out of the compiler and
put it into a different tool, called lint.

Over time, some compiler writers concluded that separating out the
functionality from the compiler was a mistake.

So, many years ago when I was using GCC's g++, and I asked on this forum
"Anyone know of a good lint program for C++ code?"  The answer was along the
lines of "The GNU philosophy is that the lint facilities belong in the
compiler.  That is enable by turning on the compiler warnings."

For me, that was an "AHA!" moment.

Because of the viewpoint about warnings being the holistic lint-like
facilities, the desire to enable or disable them inline in the code becomes
mu ("unask the question").

- - - - -

The last chapter of the story is not going to make you happy.

GCC is a community developed compiler.

The GNUrus who currently put in long hours honing GCC each have their own
agendas, and incorporating the facilities to control warning emission
behavior inline the source code has either been low on their collective
priority list, or for a faction of the GNUrus, is actually considered a
terrible malfeature (a wart).

But if you are really keen on having warning emission control inline in the
code... the beauty of open source is that you can do that.

For Quick-&-Dirty alternative, you can post-process the GCC output with
Perl, Python, sed, awk, or whatever other preferred regex capable scripting
engine you prefer, and filter out the undesired messages.

Sincerely,
--Eljay

Re: How to ignore Wall errors for a portion of code

[Brian Dessent]

John Love-Jensen wrote:

> For Quick-&-Dirty alternative, you can post-process the GCC output with
> Perl, Python, sed, awk, or whatever other preferred regex capable scripting
> engine you prefer, and filter out the undesired messages.

Or better, stop using #include for non-header files and compile them
separately so that you can control the warning flags used for each. 
(That doesn't really help if the code is templates which much be
included, but the poster didn't state that's what they were doing and
even then they should be put in a header file and not included as a .c
file.)

Brian

Re: How to ignore Wall errors for a portion of code

[Tim Prince]

Joezac Zachariah wrote:
> Hi,
>
> Thanks for your fast response. I am not sure whether my query was 
> clear. I am using 'make' to compile the code and I am passing -Wall 
> -Werror options. My requirement is that the Wall checks need to be 
> done only on a portion of the code in a given '.c' file and not on the 
> complete file. Is there a way or a Wall option with which I could 
> switch the -Wall check 'off' for a portion of the file?
>
Sorry, I missed that.  We invoke scripts from make which split functions 
where we want different compile options, then (if using gnu ld) 
recombine the .o files by ld -o bigfile.o -r split*.o (an old HPUX style 
thing).  Our source files have style which permits reliable automatic 
splitting by function.  Of course, this disables -finline-functions, so 
we have options to not split named files.

Re: How to ignore Wall errors for a portion of code

[Segher Boessenkool]

> The GNUrus who currently put in long hours honing GCC each have their 
> own
> agendas, and incorporating the facilities to control warning emission
> behavior inline the source code has either been low on their collective
> priority list, or for a faction of the GNUrus, is actually considered a
> terrible malfeature (a wart).

Also, it's pretty much impossible to implement this pragma
until all the warnings have been moved to the language
frontends.  When that has been done, it will be so trivial
and unobtrusive to implement that hardly anyone will
complain about it.


Segher

Re: How to ignore Wall errors for a portion of code

[Joezac Zachariah]

Hi Eljay,

Thanks for your detailed reply. #pragma control served my purpose. I 
think this method is fine enough to get rid of warning messages from a 
third party code which I am just including into my code. Sorry for the 
delayed reply.

Thanks,
Joezac


John Love-Jensen wrote:

>Hi Joezac,
>
>I do not believe there is a mechanism in GCC to do quite what you want.
>
>There have been quite a few requests (including from myself) for inline
>#pragma control over warnings generation, similar to what MSVC has in their
>compiler.
>
>However, there are several reasons why this hasn't happened.
>
>Before I go into that history (as I poorly understand it), you may be able
>to employ this mechanism to sort of do what you want:
>
>#pragma GCC system_header
>
>q.v. #pragma GCC system_header
>http://gcc.gnu.org/onlinedocs/gcc-4.1.1/cpp/System-Headers.html
>
>q.v. -Wno-system-header
>http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Warning-Options.html
>
>- - - - -
>
>Many years ago, the GNU folks were strongly in disfavor of the #pragma
>mechanism.  There list of objections to it were lengthy and, in my opinion,
>well thought out and compelling.  So they refrained from utilizing the
>#pragma mechanism as much as they could, and instead enhanced the C/C++
>languages using other techniques such as __attribute__ and other extensions.
>
>The Powers That Be in the standards committees eventually agreed with the
>GNU folks, and enhanced the #pragma facilities which addressed or
>compromised on all the GNU complaints against the #pragma mechanism.  There
>was much rejoicing.  But due to culture or inertial, the GNUrus were not
>very interested in going #pragma hog wild.
>
>So that's the glossy overview of the #pragma backstory.
>
>- - - - -
>
>The warning story is a bit different.
>
>In the beginning, there were expensive, powerful compilers that would reject
>dicey code.  To make compilers smaller and faster, the C compiler writers
>decided to separate that diagnostic functionality out of the compiler and
>put it into a different tool, called lint.
>
>Over time, some compiler writers concluded that separating out the
>functionality from the compiler was a mistake.
>
>So, many years ago when I was using GCC's g++, and I asked on this forum
>"Anyone know of a good lint program for C++ code?"  The answer was along the
>lines of "The GNU philosophy is that the lint facilities belong in the
>compiler.  That is enable by turning on the compiler warnings."
>
>For me, that was an "AHA!" moment.
>
>Because of the viewpoint about warnings being the holistic lint-like
>facilities, the desire to enable or disable them inline in the code becomes
>mu ("unask the question").
>
>- - - - -
>
>The last chapter of the story is not going to make you happy.
>
>GCC is a community developed compiler.
>
>The GNUrus who currently put in long hours honing GCC each have their own
>agendas, and incorporating the facilities to control warning emission
>behavior inline the source code has either been low on their collective
>priority list, or for a faction of the GNUrus, is actually considered a
>terrible malfeature (a wart).
>
>But if you are really keen on having warning emission control inline in the
>code... the beauty of open source is that you can do that.
>
>For Quick-&-Dirty alternative, you can post-process the GCC output with
>Perl, Python, sed, awk, or whatever other preferred regex capable scripting
>engine you prefer, and filter out the undesired messages.
>
>Sincerely,
>--Eljay
>
>
>  
>