I used:
#pragma QAC MESSAGE OFF. RULE NUMBER
It works for many of the messages to suppress the QAC warnings but this technique is not working for Message No 434. Do we have any other methods to suppress these QAC warnings.
You can add a comment above the line where there is a warning e.g.
/* PRQA S 0434*/
I believe that it is not possible to suppress MISRA rules using in-code #pragma or comment suppression in QA-C as explained here. I imagine this is explained in the documentation (which I do not have access to at present). The reasoning is that it would diminish the trust in the MISRA report if a developer could arbitrarily suppress it for specific code - hiding the deviation from your client or enforcement authority.
If MISRA compliance is a contractual or legal requirement in your case, you should document each deviation and let the warning stand. If you are just using MISRA as a "ready made" coding standard, then it may be better to configure the standard QA-C rules to check the MISRA rules without such strong enforcement. I think there are equivalents to most MISRA rules or they can be synthesised from multiple rules.
"Diagnostic Suppression/Suppression Syntax" is where to look in the MCPP component help.
Related
The CMake documentation on generator expressions is fairly clear that "A common mistake is to try to split a generator expression across multiple lines with indenting". Here is the example they give:
# WRONG: New lines and spaces all treated as argument separators, so the
# generator expression is split and not recognized correctly.
target_compile_definitions(tgt PRIVATE
$<$<AND:
$<CXX_COMPILER_ID:GNU>,
$<VERSION_GREATER_EQUAL:$<CXX_COMPILER_VERSION>,5>
>:HAVE_5_OR_LATER>
)
My experience is that using multiple lines with indenting works exactly as I'd hope. For example, the following code produces the exact results I would naively expect with the use of whitespace and indentation:
target_compile_options(common_interface INTERFACE
$<$<CXX_COMPILER_ID:MSVC>:
/W4 # Turn on warnings
/WX # Turn warnings into errors
>
$<$<CXX_COMPILER_ID:GNU,Clang,AppleClang>:
-Wall # Turn on warnings
-Wextra # Turn on warnings
-Werror # Turn warnings into errors
>
)
As I understand the CMake documentation, each line here would be added as a separate compile option (e.g., $<$<CXX_COMPILER_ID:MSVC>:), but that is clearly not the case since the generated build files show the flags come through correctly.
My questions are:
What am I missing? Is the issue only with certain types of expressions (e.g., logical operators)? Has the behavior changed and the documentation is out of date? or maybe the documentation needs to be enhanced to clarify the restrictions and expected behavior?
Is it safe to continue using whitespace and indentation in some circumstances?
My suspicion is that the resulting true_string (or false_string in $<IF:condition,true_string,false_string>) of a conditional expression may contain whitespace, but the other arguments of an expression cannot be broken.
Tsyvarev's comments to the question are on the money, but I'll give a more formal answer as both one of the CMake maintainers and the author of the generator expression documentation you linked to. The TLDR version is "The docs describe what you can rely on. Don't rely on implementation details that are outside that and which may change.".
The documentation makes clear where you are required to use quoting to ensure robust behavior. Splitting a genex across multiple lines or whitespace has never been officially supported. Sometimes it might appear to work, but that is by coincidence, not by design. Just because you found a case that happens to work in some range of CMake versions, you shouldn't assume that is supported behavior, especially when the documentation now explicitly calls that out as unsupported. There is no promise that such unsupported behavior will continue to work in future releases.
To be absolutely clear, the direct answers to your questions are:
What am I missing? Is the issue only with certain types of expressions (e.g., logical operators)? Has the behavior changed and the documentation is out of date? or maybe the documentation needs to be enhanced to clarify the restrictions and expected behavior?
The documentation is up to date, and I don't know how to make things clearer than what the existing documentation already says. You're asking about things that go directly against that documentation. The aspects you're asking about are not things we intend to document because they are specifically not intended to be supported behavior! Furthermore, CMake's behavior in this area may well have changed over different versions, but it has never been promised to be stable, since it has never been part of CMake's documented API.
Is it safe to continue using whitespace and indentation in some circumstances?
No. The current documentation should make it very clear what's safe and what isn't. If you're asking if something that contradicts that documentation is safe, well, it should hopefully be clear that my answer is still "No". ;)
Footnote
People failing to quote their generator expressions has been one of the most frequently reported problems (or more accurately, the cause of reported problems) in the CMake forums and issue tracker. It kept biting people over and over, to the point where I wrote a Quoting In CMake blog article about quoting in general and I also added the Whitespace And Quoting section to the generator expressions manual in the official CMake docs (that update appeared with CMake 3.24).
Simply, we are very sensitive to ABI changes, and we want to prevent people on our team using experimental features because of issues this can cause at runtime. Is there a way either via gradle configuration and/or a custom gradle plugin to detect when such features are used and elicit a compiler warning, preferably with a custom error message?
The Kotlin compiler (and transitively Gradle) will warn you by default (or even show an error) when experimental features are used.
To change this behaviour, the developer has to opt in via an #OptIn annotation or -opt-in compiler argument. If you're trying to avoid accidental usages of experimental features, this should therefore be sufficient (if we consider that opting in to an experimental feature is not an accident).
If you want to prevent usages of #OptIn itself, this is a different story. Technically #OptIn itself is still experimental at the moment, so there will be a warning for usages of it anyway unless someone adds the compiler argument to opt in to the #OptIn experimental annotation :) So currently just having a culture of not modifying compiler arguments should be enough, but that of course will change once #OptIn gets stable.
I am not aware of plugins that already do this, but you should be able to write a plugin with Kotlin Symbol Processing that checks for those annotations (never tried it myself, though).
As a side note about ABI compatibility, there is also the binary-compatibility-validator, but that's for your own code, so I don't think it's related to the question.
With a snippet like
perl6 -e 'loop { FIRST say "foo"; last }'
I get
WARNINGS for -e:
Useless use of LOOP_BLOCK_1 symbol in sink context (line 1)
foo
I know how to work around the warning. I'm wondering about what the source of the warning is. I found this open ticket, but it doesn't seem to have received any attention.
What is this warning about?
And what about this is useless?
Version
$ perl6 --version
This is Rakudo version 2018.06 built on MoarVM version 2018.06
implementing Perl 6.c.
It's a bug, a bogus warning.
I know how to work around the warning.
That's the main thing.
I'm wondering about what the source of the warning is.
It's a bogus warning from the compiler.
I found this open ticket, but it doesn't seem to have received any attention.
I think it got some attention.
bbkr, who filed the bug, linked to another bug in which they showed their workaround. (It's not adding do but rather removing the FIRST phaser and putting the associated statement outside of the loop just before it.)
If you follow the other links in bbkr's original bug you'll arrive at another bug explaining that the general "unwanted" mechanism needs to be cleaned up. I imagine available round tuits are focused on bigger fish such as this overall mechanism.
Hopefully you can see that it's just a bizarre warning message and a minor nuisance in the bigger scheme of things. It appears to come up if you use the FIRST phaser in a loop construct. It's got the very obvious work around which you presumably know and bbkr showed.
What is this warning about?
Many languages allow you to mix procedural and functional paradigms. Procedural code is run for its side effects. Functional code for its result. Some constructs can do both.
But what if you use a construct that's normally used with the intent of its result being used, and the compiler knows that, but it also knows it's been used in a context in which its value will be ignored?
Perls call this "useless use of ... in sink context" and generally warn the coder about it. ("sink" is an alternative/traditional term for what is often called "void" context in other language cultures.)
This error message is one of these warnings, albeit a bogus one.
And what about this is useless?
Nothing.
The related compiler warning mechanism has gotten confused.
The "Useless use of ... in sink context" part of the message is generic and hopefully self-explanatory.
But there's no way it should be saying things like "LOOP_BLOCK_1 symbol". That's internal mumbo-jumbo.
It's a warning message bug.
I know that I can ignore compiler warnings with -w on a given file in Xcode.
I would like to similarly ignore analyze warnings on a given file (JSONKit.m in this case, which has two potential leaks). I trust that the developer of that library knows what they're doing, and I don't want to maintain a fork of it. Not to mention that I have no clue what's going on in there anyway.
Any ideas?
Don't trust the developer. Figure out why the potential leaks exist and fix them (ideally, sending a patch back to the developer).
If you want to take the lazy way out (j/k ;), you can add code to fix the problem under the analyzer only using:
#ifdef __clang_analyzer__
... release the offending variable here ...
#endif
I prefer this solution to whole-file-disabling because it both exactly identifies the problem area with an easily searchable identifier and it allows the rest of the file to be vetted by the constantly improving analyzer.
I'm using weak keys while doing cryptography with libgcrypt and I'm getting proper warnings about it from libgpg-error as "Weak encryption keys" to stderr. Problem is that I'm reading std:err into GUI, where I don't want to see them (just because getting too many of them). I can filter stderr input in GUI, but my preferable way would be to suppress the warning in more intelligent way. Unfortunately I don't have any clue how to achieve this. While reading though libgcrypt documentation I found that it allows suspending of secure memory warning only. Reading through libgpg-error source code I haven't found anything useful.
Your advice would be much appreciated.
Thanks in advance.
Jan
Finally I've got to ask libgcrypt developers. Following is the answer from Werner Koch, whom I want to thank in this way. I hope this is going to help somebody else.
==================================================================
I case you try to use a weak key for regular encryption and the error
checking inside the DES module inhibits you from actually doing it,
there is no documented way to go with it. A weak key is something which
should never ever happen.
You may however use a private control code to disable the weak key
detection. We use it in the regression tests. But note that this is
undocumented private feature which may or may not work with future
versions of Libgcrypt. Here is a code excerpt:
#define PRIV_CTL_DISABLE_WEAK_KEY 61
err = gcry_cipher_open (&hd, cipher_algo, cipher_mode, 0);
if (err)
die ("gcry_cipher_open failed for algo %d, mode %d: %s\n",
cipher_algo, cipher_mode, gpg_strerror (err));
gcry_cipher_ctl (hd, PRIV_CTL_DISABLE_WEAK_KEY, NULL, 0);
==================================================================
Edit
Disabling weak keys warning is now suppressed in the latest libgcrypt version so the above makes no sense anymore. We've fixed that by catching up stderr in a boost stream and filtering it out before providing it in a log.