Disable Keil warning

now I could go look up what the warning ment, but since you want to keep it a secret, I'll leave it so

Erik

now I could go look up what the warning ment, but since you want to keep it a secret, I'll leave it so

Erik

The warning refers to pointers (I am using a pointer of one type, and point to another type). I understand the warning. I want to disable the message in the build output window.

So, the answer that I expect should apply to all compiling warnings (thus not including the details in my first post)

So doesn't the "normal" way of adjusting pointer types work well for you? Any decent C text should contain information about type casts.

Are you really, really, really sure that trying to disable this warning number is the correct route?

Do you, by the way, know that the two pointers are compatible enough that it is meaningful to try to do what you are attempting?

I understand the warning. I know how I can correct it in code. Performance wise, I preffer not to. You mow probably ask "how could possibly fixing the pointer type affect the performance". The full answer is more complicated. The easy version is that I would need to write a chunk of code to make it happen that will end up in adding extra steps, that will cause some timeouts.

Now, I am not here to debate whether this approach is good or not.My question is rather simple:

Does Keil have any way to disable a specific warning that it outputs? (This should be something basic for a compiler)

Thank you.

From your answer, we know that you don't understand this issue. So maybe you really should spend some time to debate this issue.

If the two pointers really are compatible, then a type cast in C wouldn't add any extra code or consume clock cycles. It would be a pure syntactic construct to tell the compiler "yes, I know the pointer is type A but but is compatible enough that I want to use it as if it was type B". The only conversion happening would be of the meta information kept within the symbol tables of the C compiler while it was busy generating the code.

It does not cost time to convert an int* pointer into a char* pointer - except the few seconds it takes to tell the compiler that you really want to use the int* pointer as if it was a char* pointer.

But the next issue is that actual pointer types can matter a lot depending on architecture and used compiler. Such as size of pointer (near, far, huge), or a "based" pointer that might operate relative to a specific segment register or address within a specific memory region. Then there can be alignment issues.

In the end - if the pointers really can be used as you want, then there is no need for any flag to turn off that warning number because there are C language constructs available to type cast the pointer. And if the pointers really aren't compatible enough, then turning off any warnings will not result in a correct program.

Disabling such a warning is crazy.

It will appear e. g. if you do the following:

int* pi;
char* pc;

Then you might like to write

pi= pc;

of course this is extremely dangerous, therefore you get this warning.

But to tell the compiler, that you are really sure what is going on there, you should cast:

pi= (int*)pc;

Then the compiler will assume that you take the risk yourself and will not warn you further ...

Yes - I most certainly do:

how could fixing the pointer type possibly affect the performance??

You are neither fixing nor changing any assembly code with this cast. So it has not ANY implication on performance.

This cast (int*) is just the assurance to the compiler, that you take the complete responsibility for such a dangerous assignment. (... the compiler in this case then will not give a warning...).