I'm using uV 4.70.0.0, compiler version is 5.03.0.24.
Is there a way to disable specific warnings? In other Keil toolchains I seem to remember there was a command-line control that allowed this. I can't seem to find a similar control in this ( ARM ) compiler, rather all I can find in the manual is the -W which disables all warnings. Am I missing something ?
Thanks
Robert;
I'm not running v4.7 but earlier version allowed specific disables.
Select 'Target Options' then select the linker tab. Enter the specific warning number that wish to suppress. Watch for the entry at the bottom in the "linker Control dialog". You should see something like 'diag_suppress xxxx' were xxxx is the linker warning number that you need to disable.
Search on __diag_suppress in the Linker User Guide.
Bradford
Is there a way to disable specific warnings ?
anyone seriously asking that question while working for me would learn what unemployment is.
Erik
Err... don't do whatever it is that causes the warning?!
Well, if you withold the relevant detail you must expect the trivial answer!
What is it that makes it more attractive for you to suppress the warning(s) than to fix the code? We can't know if you don't say.
Yes, there are a few cases where "keeping the compiler happy" can be more effort than it's worth - but why not show some evidence that this is really one of those cases? You haven't given any reason to believe that it is.
Even when "keeping the compiler happy" is more effort than it's worth, it's debatable whether suppressing the warning is a good approach. Documenting the expected warning may be more appropriate...
I totally agree here. Andrew, Eric and sometimes Per often come across as arrogant "know it alls" and would be better off not posting a reply at all if they can't provide a straight answer without criticising the OP's style, wording or skill set!
I can't see why you wanna suppress warnings.
a) If there's a warning, it means some minor problems exist in your program or project. Better to solve them.
b) If you know the causes of the warnings well and you're certain enough that the warnings won't cause any bad results, why not just ignore them? Warnings won't keep you from getting your expected build results.
I use the
#pragma diag_suppress 265
in one module.
It worked nicely until uVision 4.5. But since 4.6 it unfortunately did not work any more (it does neither work in 4.7).
So I had to add "--diag_suppress 265" to the "Misc controls" in the "C/C++" page of the compile settings for this module. This works then, but the "pragma diag_suppress..." would be nicer for my application (as I need it only for a table with references to my struct/class addresses for communication access - this is a VERY local and small part of my code).
If you know the causes of the warnings well and you're certain enough that the warnings won't cause any bad results, why not just ignore them?
A very bad habit. If you're not careful, your list of acceptable warnings will start to grow and you'll miss the new one that really matters. Far better to suppress the one(s) you know are not problematic to you or your project so that any other warnings are seen more easily.
a) Just ignore the warnings which you judge NO HARM b) Suppress the warnings which you judge NO HARM You think these two choices different, because suppressing warnings more reasonable?
I'm afraid I cannot agree. I can't see any differences in these two. If the programmer made a wrong judgement, the problem will exist, no matter he ignore it or suppress it.
I can't see any differences in these two.
Then I suggest you open your eyes, read what I wrote again and consider it further.
Of course, it is preferable to remove a warning. But remember that some warnings are really benign.
Probably Jack Zhang is writing only small demo programs, but has no experience with larger projects.
If I suppress a warning around a specific function, I know that warning doesn't produce any build noise. So any warning showing up is something new and unexpected to take a closer look at.
Nowadays, most compilers gives decent warning messages, allowing the source code to just be adjusted to mute the warnings.
Some compilers have had totally brain-dead warning messages that would require the source code to be nuked just to make the compiler happy. So in some situations it is more meaningful to partially disable a warning instead of breaking the code - especially since the code may be designed for use on a large number of different platforms making code changes requiring lots of rebuilds and retesting.
So there is a reason why lots of compilers have nice pragma options to push a warning state, before disabling a warning. Then popping the original warning state again.
A global kill of a warning is seldom good - unless the compiler developer had a big hole in is head. Microchip have managed some real broken compilers where they must have had a bad day when brain storming what to warn about. An example - when having a 16-bit variable that should be assigned to an 8-bit variable, it is traditional to have an 8-bit cast to tell the compiler not to warn about loss of information when assigning to the smaller variable. But this Microchip compiler instead complains that the 8-bit cast is bad for efficiency - despite not requiring any code to be generated...
So there are most definitely reasons to be able to enable/disable warnings, depending on compiler and actual code requirements. Just that disable of warnings is not at the top of the list of things to consider when seeing a warning.
For such a short disable/enable of warnings, the following construction really is very useful:
#pragma push #pragma diag_suppress 265 ... #pragma pop
or alternatively:
#pragma diag_suppress 265 ... #pragma diag_default 265
I managed to use the first version above until uVision 4.5, just unfortunately in uVision 4.6 and 4.7 this does not work any more. Would be nice, if it would be re-anabled in 4.8 (but of course it is not crucial - V4.7 has SOOO many nice and surprising improvements (concerning the in-situ-compiler and code completion), that I do not want to grump ...).
Andrew, Eric and sometimes Per often come across as arrogant "know it alls" very funny. as seen above the replies are due to NOT knowing it all. that the OP refuses to give his reasons makes it impossible to give an answer. I, for one, would not ever tell anyone how to get rid of WARNING: external reference to nothing (paraphrased).
I, for one, would not ever tell anyone how to get rid of WARNING: external reference to nothing (paraphrased).
One would hope the OP notices that not all posters here are as cantankerous as the regulars frequently appear to be.