Supressing Specific Warnings in RealView Compiler

take the pieces you do not want to be warned about and compile them into a library, then include the library in your build.

Erik

Wouldn't it be better to just remove the causes of those warnings...?

ie, fix the problem, rather than just masking the symptoms?

Most definitely start a code quality improvement program and correct this - and probably other - bad habits that the code seems to suffer from.

If you are already doing other work with the code or are switching compiler or target platforms you still have to perform new validations of the code.

Does this help?
infocenter.arm.com/.../CIHECIAD.html

--
Marcus
http://www.doulos.com/arm/

infocenter.arm.com/.../CIHECIAD.html

I think not: the OP said he knows how to globally disable a warning - and that's not what he wants.

He wants to just selectively disable specific instances of a warning.

If I understand correctly, something like this:

   :
   :
    // Code with warnings enabled
   :
   :
#pragma begin SUPPRESS_SYMPTOMS_INSTEAD_OF_FIXING_CAUSE
   if( a = b )  // just suppress the warning on this particular line
#pragma end
   :
   :
    // Code with warnings enabled
   :
   :

   :
   :
    // Code with warnings enabled
   :
   :
#pragma begin SUPPRESS_SYMPTOMS_INSTEAD_OF_FIXING_CAUSE
   if( a = b )  // just suppress the warning on this particular line
#pragma end
   :
   :
    // Code with warnings enabled
   :
   :

Even if this were possible, it highlights the fundamental flaw in the approach!

When a change is subsequently needed in the "protected" code, the warning will have to be re-enabled to be sure that the change isn't also subject to the problem!

That issue would not arise if you fixed the actual problem!

Again, I think it would be far better to fix the underlying problem rather than just try to supress the symptoms.

But a creative reader would have been able to follow that link and (with maybe a bit of knowledge of other compilers) noted push/pop:

infocenter.arm.com/.../index.jsp

Don't encourage him!

"Again, I think it would be far better to fix the underlying problem rather than just try to supress the symptoms."

Of course.

That warning is one of the most meaningful warnings available.

Besides - there are explicit ways to rewrite code to avoid this warning. A method that is applicable without any knowledge of #pragma or other methods to turn on/off/toggle compiler warnings:

if ((a = b) != 0) {
    ...
}

Compare this with:

if (a = b) {
    ...
}

The first alternative with the extra comparison operator clearly shows that the developer was aware of the assign and did add a "I promise that this assign is intended as written".

The second code alternative will always get a reader to a screeching halt, wondering if the code is accidentally buggy, or written by a fool who doesn't understand better, or maybe written by someone very evil who purposefully tried to saw doubt.

Using the pragma would probably not be my preferred choice to tackle this, but it is always difficult to judge when to berate people and when to just answer the question. There might be perfectly valid reasons for doing it this way. In fact I could think of some.

--
Marcus

Another option is, of course, just to write:

a = b;
if( a )  // or if( b )
{
   :
}

It is a common mistake to assume that minimising source lines improves the efficiency of generated code!

user.it.uu.se/.../engblom-esc-sf-2001.pdf

"Trying to write your code on as few lines as possible, using ?:-expressions, postincrements, and comma expressions to squeeze in a lot of side effects in a single expression, will not make the compiler generate more efficient code. It will just make your source code convoluted and hard to maintain. It is easy to overlook a postincrement or an assignment if it is done in the middle of a complex expression. Write your code in a style that is easy to read."

www.iar.se/.../

Indeed.

But it is the poster's responsibility to provide all the information necessary to give appropriate answers!

In a recent blog, Dave Van Ess wrote:

"When I am out showing off PSoC I will have customers draw out a schematic and ask if PSoC can do that. A schematic is a solution, not a definition. I end up asking just what are they trying to do. When they tell us We then figure out how to do it the PSoC way."

See: www.cypress.com/ - last paragraph

In this thread, the OP has effectively sketched a schematic...

Yes, complex source lines are seldom good. The maintainance costs are very much related to how easy the code is to read and understand.

But there can be a number of problems with rewriting an if statement to move out the assign. The assign may be a sub-expression where evaluation order is important.

The great thing about just adding (assign) != 0 is that it can be inlined without changing any evaluation order.

There is a bit of a difference between designing new code, and finding good code rewrite rules for existing code.

Guys, thanks for all the remarks, I think I will go with one of Per's suggestions:

if ((a = b) != 0) {
    ...
}

I agree with all that was said, but since this code is not maintained by us, I understood that section of the code, and know they meant it as it was written... I would not have a problem just suppressing those warnings.

Per, thanks for going as far as showing me push/pop in order to actually do what I meant to do, but since the suggested change is simple enough, I will just do it.

Thank you all for the prompt response,
George Andrew Brindeiro
Robotron Automation and Technology