Dissabling specific warnings in C51

Hi Erik, thanks for your reply.

When I say the code is fine I was referring that the generated assembler code is correct.

I see your point, and this is way I have spent 4 hours revising the generated assembler for each line with warnings, but as you said "warnings are not always errors".

And the problem is that this f***** warning, which I clearly have under control, generates so many output that it could easily hide some other more important warnings simply because you are not going revise 200 warnings each time that you compile.

The feature I talk is quite common in most compilers I have use, but I'm not able to find it in the C51 compiler. Is this compiler missing this feature?

Note
This message was edited because of rude or abusive language.

Hi Erik, thanks for your reply.

When I say the code is fine I was referring that the generated assembler code is correct.

I see your point, and this is way I have spent 4 hours revising the generated assembler for each line with warnings, but as you said "warnings are not always errors".

And the problem is that this f***** warning, which I clearly have under control, generates so many output that it could easily hide some other more important warnings simply because you are not going revise 200 warnings each time that you compile.

The feature I talk is quite common in most compilers I have use, but I'm not able to find it in the C51 compiler. Is this compiler missing this feature?

Note
This message was edited because of rude or abusive language.

What warning(s) are you actually talking about ?

When I say the code is fine I was referring that the generated assembler code is correct.

It may not anymore be once you change things like optimization level or compiler revision.

Hi Christoph,
thanks for your interest.

Warning C259: pointer different mspace.

It could be a really dangerous warning ... or not ...

The device is a 80x51 using the Dallas 390 Linear Addressing.
It seems the compiler casts from xdata to far correctly (adding the third byte to the pointer), but in any case, it also add a warning.

In the other direction, it simply uses the offset (lower 2 bytes) and ignores the high byte, what it is a really dangerous cast (the cast should not be done automatically, and this should be an error and not a warning!!)

It could be a really dangerous warning ... or not ...

It's classified as Error/Warning. I would take that even more seriously than just a regular warning.

It seems the compiler casts from xdata to far correctly (adding the third byte to the pointer), but in any case, it also add a warning.

Are you using implicit or explicit casting ? If the former, does the warning go away if you cast explicitly ?

Anyway - casting from a pointer to xdata to a pointer to code memory is a fairly odd operation (I'd really have to think hard to find any operation that requires such casts), and not at all covered by any standard C rule. A different compiler (version) might handle this type of cast entirely differently.

"unused variable" means one less slot for the stack

No, a compiler smart enough to detect an unused variable should - and will - remove that variable. It warns because the developer may have spelled another variable reference wrong, and suggests that the developer should check again why the variable isn't used.

If an employee of mine suppressed warning reporting by ANY means, he would be very close to entering the unemployment line.

Life isn't that easy. There really are warnings that you don't want, and you don't want to try work-arounds in the code, just to silence them. Some compilers are a bit too smart, and some compilers a bit too stupid...

There are a number of times - depending on compiler etc - where you really have to turn off warnings, because the compiler can't know everything the developer does.

Let's say that you have a function that has to return a value - say main(). You know that a specific application will never return - quite common in the embedded world. The compiler generates a warning that it doesn't find any return statement. If you add a return statement, the compiler is stupid enough to generate code for it, even if the function contains an infinite loop and will never be able to reach the return.

On the other hand, the compiler might be smart enough to notice that it doesn't have to generate any output for the return statement, but will instead emit a warning about the return statement being unreachable...

In short - an example where one compiler generates a warning if you add the return, and another compiler generates a warning if you don't.

Another common nuisance is unused parameters. A function prototype may require the parameter, but your code does know that it doesn't need the parameter. Depending on compiler, you might really have to either make a dummy access, or disable the specific warning.

There are a number of other situations, where you may get completely innocent warnings that you want to kill, so that any compilation warning you see is a new one, requiring a check. That is why many good compilers allows push/pull of warning state, so you can turn off a specific warning for a specific function - or around some specific lines of code. The bad thing is to turn off specific warnings for all source files. The unreachable code may really be a logic error in the source...

Pipe the error output through sed to delete the warnings you don't care about.

Sorry. Forgot the context:

"... so many output that it could easily hide some other more important warnings simply because you are not going revise 200 warnings each time that you compile."

Pipe the error output through sed to delete the warnings you don't care about.

I totally agree with you, Per.

But pitifully, it seems that the goal of the thread has been lost. I think it is not worth to discuss aboutif warnings should be shown always or not, this could become a unuseful interchange of points of view ...

The original question is still unanswered:

Has the Cx51 compiler any flag or macro or way of silence a single warning (out of the warninglevels mechanism?)

It seems that the LX51 do has it, but lamentably, the C51 seems to not have it.
Could any one confirm this extreme?

"Could any one confirm this extreme?"

By reading the manual for you?

Hi Dan,
I'm able to read, and I have read the whole manual without finding a solution for what I'm looking for, which, on other hand, it's something really usual in most modern compilers I have used (that the reason why I ask, because it sounds strange to me that the compiler has not such feature).

But sometimes the manuals are inaccurate, or not updated, or simply you have not understand what you have read in the first pass...

In any case, I see you don't have an answer to the question, so I presume you have not read the manuals and cannot be of help on this thread.

The question is simple, please don't loose the focus.

"The original question is still unanswered"

Also unanswered is whether you're doing an implicit or explicit cast - and, if the former, whether an explicit cast removes the warning...?

If sed is not available, grep is quite useful. Just use -v to invert the matching rule.

I want to get the answer too.

Dan Henry wrote: "Pipe the error output through sed to delete the warnings you don't care about."

Thanks, this would be a useful work around. With the advantage that it can configure more selectively. But how can you integrate the sed/grep into the uVision3 IDE, so that it filter the compiler/linker output?

David;
The simple answer is that the compiler does not support disable of warnings by warning number. Both BX51 and LX51 support disable warnings by warning number. In the dialog Options-LX51 Misc you can insert multiple individual warning numbers each separated by a comma to disable the warning.
Bradford