I am running Coverity static analyzer tool on My Project which is having some flex/bison generated cpp file. Coverity is reporting following warning on one of the flex file.
CID 340350 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking **yyg->yy_buffer_stack**
suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
Code snippet of the flex generated file where Coverity reported issue :
if (YY_CURRENT_BUFFER) {
DNParser_load_buffer_state(yyscanner );
yyg->yy_did_buffer_switch_on_eof = 1;
}
}
There are two possibilities - either it can be NULL in which case there's a bug as the pointer has already been dereferenced before it even got to the check, or the check is overly defensive coding that serves no point.
Since it's generated code, I'd be inclined to ignore the defect unless you believe that it actually can be NULL.
Related
I am facing below coverity warning:
Type: Parse recovery warning (RW.ROUTINE_NOT_EMITTED)
Classification: Unclassified
Severity: Unspecified
Action: Undecided
Owner: Unassigned
Defect only exists locally.
Not sure what this means ??
The warning RW.ROUTINE_NOT_EMITTED is basically a parser warning which is generated when some piece of code is not analyzed due to previous errors.
But the real glitch I think is here that actual error you should fix is generated later in the sequence.
So I would suggest fix other below Coverity and this should be resolved.
In my case I forgot to include a header file for system structure. So due to this error parser could not parse something which generated the : RW.ROUTINE_NOT_EMITTED warning.
RW.ROUTINE_NOT_EMITTED means that the Coverity parser failed to understand some of the code running by it, but instead of discarding the entire file it recovered from the error and discarded the routine containing the error (since it's impossible to know whether the semantics were still valid or not).
This usually occurs when the dialect accepted by your compiler differs from the dialect accepted by the Coverity compiler, whether due to yours being further ahead of the curve on new language standards, by your compiler implementing its own extension to the language standard, or simply a bug in the Coverity compiler itself.
The best thing to do here would be to send a reproducer to Coverity support so that R&D can fix the issue in a future release. Otherwise, these are fairly safe to ignore - you won't get analysis defects reported for the function that was discarded, and inter-procedural analysis may miss some defects as well, but the odds of this are fairly low.
I am working on an Android application that uses OpenCV 2.4.9 and NDKr9 as dependecies. I also use Eclipse 4.4 Luna as the IDE, with CDT plugin 8.4 installed.
Whenever I'm trying to use the methods std::vector.at(int), or the "[]" method, i get weird errors. For instance, consider the code:
#include <vector>
.........................
struct CustomStruct {
int level;
Point firstPoint, secondPoint, middlePoint;
};
.........................
int maxElemNr = 10;
std::vector<CustomStruct > customStructVector(maxElemNr);
.........................
for(int i=0;i<customStructVector.size();i++){
if(customStructVector.at(i).level == 0){
}
}
At customStructVector.at(i) Eclipse tells me the following:
Invalid arguments ' Candidates are: ResultWithEvidence & at(?) const
ResultWithEvidence & at(?)'
If I want to use the "[]" operator, instead of the "at(index)" method, i get the following:
resultWithEvidenceVector[i].level tells me that the field level is not found.
I am by no means an expert C/C++ coder, and I am rather new at working with the NDK. Coming from a Java background, I was expecting to get an object of type CustomStruct when calling either customStructVector.at(i) or customStructVector[i], such that I could then simply access the field level on my object, to read its value.
Also, declaring my vector as
int maxElemNr = 10;
std::vector<CustomStruct> customStructVector;
customStructVector.reserve(maxElemNr);
I get:
Invalid arguments ' Candidates are: void reserve(?) '
I have searched for answers, and came with the theory that eclipse might not use the c++11 version of the std library?
I've read about the vector class from here. Also, this issue closely resembles the question asked here.
Will provide more info about my environment and such, if needed. Would like to solve this, as it's quite a blocker for my project as of now..
What am I doing wrong? I had no problems compiling and running the code previously to using the std::vector class.
LE: apparently the workaround &(resultWithEvidenceVector.data()+i)->level is recognized by the editor, and the code compiles. Would still like to use the std::vector as it is supposed to be used though.
I had the same problem. It works in Visual Studio compiler but when i try to access vector element i get exactly the same error.
However it seems that if you don't use 'at' then it works for example customStructVector.at(i) use customStructVector(i),
It is strange. I didn't test it in detail. Please note that if you have vector you have to cast the result in order to access the type members.
Regards
I have my own emulation of java.util.Timer (and quite a lot of other stuff missing in GWT). I have even a JUnit test proving it works in the browser.
I've just tried to convert some third-party library to GWT, which needed a Timer, and in some part of it, I call:
SystemUtils.getTimer().scheduleAtFixedRate(timerTask, value, value);
But the GWT compiler turns getTimer().scheduleAtFixedRate() to:
getTimer().nullMethod()
SystemUtils.getTimer() is a static method. I have googled for nullMethod(), but most hits are about:
null.nullMethod();
That doesn't apply to me. What could be going wrong, and what can I do to fix it?
[EDIT] Actually, the java.util.Timer emulation itself works, but it seems that (atm?) SystemUtils.getTimer() returns "undefined". Could that be the reason? Since getTimer() returns an instance created dynamically, how could the GWT compiler possibly make any assumption about the return value of getTimer(), and the presence/usage of the methods of the Timer type?
When I have seen this kind of errors it was caused by unreachable code: GWT had determined that some code was not reachable, turning off compilation for some stuff, but then it still somehow tried to link the unreachable code, showing this kind of errors.
For completeness sake
If this error shows up (which often happens after deploying to App Engine) then compile without obfuscation, turn off super dev mode, restart jetty and refresh the browser. Open the generated javascript and find where the problem occurs by searching for 'nullMethod'. You'll see that the compiler may have removed whole chunks of code that it believes is 'unreachable'.
The code surrounding 'null.nullMethod' is probably very different than what you expected. The simplest way around this is to add a null /undefined check and initializing whatever variable that is generated as 'null'. This forces the compiler to reconsider because now the variable can never be null and the code that follows it must be reachable.
For example, if null.nullMethod is found and 'null' is actually supposed to be var a = ... then add if(a == null) { a = ""; } before it (in Java of course).
For anybody who struggles with this null.nullMethod issue:
It may be possible that your GWT compiler isn't able to find the properties of your JSON bean object if your object variable is declared with its interface type:
MyTypeIF item = ...;
...
item.getStart();
...
In my scenario, GWT compiled that into:
MyTypeIF item = ...;
...
null.nullMethod();
...
Instead, I had to declare and cast it to its real implementation class:
JSMyType item = (JSMyType)...;
...
When running doxygen over one particular pretty large C-language project consisting many files (all completely documented, I think), then I always find this warning at the bottom of the output:
<#1>:1: warning: parameters of member #1 are not (all) documented
How can I find and remove the trigger of this warning?
Note that the project in question is too large (and the issue not important enough) for bisection or other trial and error based search methods.
Realize this is an old question but just ran into this behaviour myself and didn't find a solution online.
Found the offending file by running Doxygen and looking at where the error message appears in the output (make sure you're not suppressing stdout or you'll just get the error with no context).
In my case the error appeared after the line "Generating dependency graph for group [name]". By looking at the relevant file I found an undocumented, unnamed enum. The members of the enum were still documented. e.g.
enum
{
X = 1, /**< Documented. */
...
}
I'm guessing it's the lack of name on the enum that was throwing Doxygen and causing the unhelpful message. Adding a name causes more helpful error messages to be generated. Documenting the enum (with or without a name) removes the error.
I'm trying to port the speakhere example into another app and I'm having issues. I copied all the files, and all the frameworks, but for some reason I get a bunch of compile errors that I've never seen before and thus don't know what to do. The only difference is that i'm not suing IB and so i had to change it slightly.
What does error: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo' mean?... I get this error multiple times for different files
In my situation the first error is pointing at 'MeterTable'.. a class that includes <stdlib.h>,<stdio.h> and <math.h>. But those files seem to be importing fine (if i remove them i get more errors)
Any suggestions on how to debug this?
TIA!
EDIT:
I still can't seem to figure it out. I'm literally just copying files from the example into another project. Can someone check it out please ? SpeakHerePort.zip and the original is here SpeakHere.zip
Your problem is that you are compiling SpeakHerePortAppDelegate.m, which is an Objective C file, but it is indirectly including MeterTable.h which is a C++ header file.
Rename it to SpeakHerePortAppDelegate.mm (double m) so that it is compiled as Objective C++ and your problem is resolved.
Name all your files .mm and then all your code will be compiled as Objective C++
In my case, the .h and .m in question are built fine with regular target, and the App can run as well.
However after the subset of the files are moved under a static library target, it gets this compile error when the static library is built.
Was stuck for a while & tried the above mentioned techniques, unfortunately they didn't help in my case.
Noted that this error happened only for the NSString*, for e.g.,
extern double const kTimeout; // fine
extern NSString* const kImageType; // compile error
After the above analysis & little break, eventually the problem is resolved by adding the the following import to the .h - "Foundation/Foundation.h"
It sounds like an unfinished declaration, probably in a header file. Search for 'foo' (or whatever the symbol actually is) across all project files, using ⇧⌘F (Edit ▸ Find ▸ Find In Project...) in Xcode, and/or examine the headers you're including where MeterTable is declared. Sometimes the compiler gets confused about the actual location of the error, since header files are frequently #imported into other files, so the problem can be manifest in multiple locations.
This might not have applied to this exact situation, but I had this exact error too, which was caused by a bad forward declaration. In Objective-C, make sure your forward-declares begin with the # sign - e.g.
#class MyClass;
Those of us still on autopilot from C++ will forget the #, see that XCode has highlighted class as a reserved keyword, and think all is well with the world. It is not.
It means that you have a syntax error. If you paste the code in question, it's easier to debug.
I had a similar scenario to some of the posts above. I'd written a C++ class based off of the examples in the Audio Queue Services documentation, and had this compilation issue in a test project. This post helped a tremendous amount.
Today, I'm incorporating the C++ class in my project, and got the build error again. In my scenario, I had to also set the type (using the "Get Info" window) to sourcecode.cpp.objcpp for the objective-c class that was calling my C++ class.