JavaScript is not currently enabled, but is required for full CodeSonar manual search and browse functionality.
If you are viewing this file in your hub's Web GUI, enable JavaScript in your browser: you will also need it for GUI functionality.
If you opened this file directly from disk, your browser may be directly suppressing JavaScript functionality: certain browsers perform this suppression on local files (but not files delivered by web servers) for security reasons.
| CodeSonar® 9.2p0 | CONFIDENTIAL | CodeSecure Inc |
CodeSonar operates by building its own internal representation (IR) of your regular software project, then performing an analysis that involves a series of checks involving various aspects of that IR. Any warnings issued by the analysis are then mapped back to your source code for presentation.
In some cases, text that appears in a project's source code files is not actually compiled into the project's object code, and so is also not included in the CodeSonar IR for the project. For example, a region of text may be excluded by the C or C++ preprocessor, and so not be included in the native software or its corresponding CodeSonar project. CodeSonar warnings will not be issued for this excluded text, because it is not part of the analyzed project.
This section describes some of the cases where text present in a source file is not represented in the underlying software or CodeSonar IR, and so will not trigger CodeSonar warnings.
If a file is not included in the CodeSonar build/analysis, there will be no IR for any part of the file and so no warnings will be issued for any code in the file.
The mechanism for including a file in the CodeSonar build/analysis depends on the file language, as shown in the following table.
| File language (click for detailed build/analysis information) |
Ensuring CodeSonar constructs IR and reports warnings for a file |
|---|---|
| C, C++ |
The CodeSonar build/analysis must observe your native compiler
compiling the source file as part of your regular software
build. For the file to be represented in the analyzed IR, all of the following must be true.
|
| Java |
In order to identify and report vulnerabilities with respect to
a Java source file, the CodeSonar build/analysis must observe a
cs-java-scan command that specifies
both of the following.
|
| C# |
In order to identify and report vulnerabilities with respect to
a C# source file, the CodeSonar build/analysis must observe a
cs-dotnet-scan command that implicitly
or explicitly specifies both of the following.
|
Code that is removed by the C or C++ preprocessor will never reach the compiler, so it cannot be part of the native software or its corresponding CodeSonar project. CodeSonar warnings will not be issued in code that has been preprocessed out.
For ease of recognition, the CodeSonar GUI uses special highlighting to indicate code that has been preprocessed out. See Code Coloring and Interation: C and C++ Source Coloring for more information.
Consider the following code fragment. Depending on the setting of preprocessor variable TESTVAR, it defines slightly different versions of dodiv(): one that can perform a division by zero and one that can't.
#if TESTVAR > 1
int dodiv(int i){
if (i<0) return -1;
return 5/i;
}
#else
int dodiv(int i){
if (i<=0) return -1;
return 5/i;
}
#endif
int exercise(void){
return dodiv(0);
}
We can look at the effects of two different TESTVAR settings:
| Use preprocessor to select "good" dodiv() | Use preprocessor to select "bad" dodiv() |
|---|---|
#define TESTVAR 1 #if TESTVAR > 1 /* The body of this "#if" branch is removed by the preprocessor. * - The "bad" version of dodiv() is not included in the * compilation, so does not appear in the underlying software * or the CodeSonar project. * - The CodeSonar GUI uses grey, italic text to display the #if body. * - No warnings will appear in the greyed-out #if body: it is not part * of the project. */ int dodiv(int i){ if (i<0) return -1; return 5/i; } #else int dodiv(int i){ if (i<=0) return -1; return 5/i; } #endif int exercise(void){ return dodiv(0); } |
#define TESTVAR 2
#if TESTVAR > 1
int dodiv(int i){
if (i<0) return -1;
return 5/i; /* Division by Zero warning issued here */
}
#else
/* The body of this "#else" branch is removed by the preprocessor.
* - The "good" version of dodiv() is not included in the
* compilation, so does not appear in the underlying software
* or the CodeSonar project.
* - The CodeSonar GUI uses grey, italic text to display the #else body.
*/
int dodiv(int i){
if (i<=0) return -1;
return 5/i;
}
#endif
int exercise(void){
return dodiv(0); /* Unreachable Data Flow warning issued here:
* control cannot return from the call to "bad" dodiv(0)
* because it will always perform division by zero
*/
}
|
In most cases, CodeSonar does not produce IR for inline functions that are not called. Any errors in such functions will therefore not be detected by the CodeSonar analysis.
C++ compilers can implicitly inline functions even if they are not declared with the inline keyword.
#include <cstddef>
class NPDClass{
private:
int *myptr;
public:
NPDClass(void){myptr=NULL;};
void npd_inl_called(int i){
*(this->myptr) = i; /* Null Pointer Dereference warning issued here:
* npd_inl_called() is implicitly inline, but has IR because it is called in the program.
*/
};
void npd_inl_uncalled(int i){
*(this->myptr) = i; /* No warning: npd_inl_uncalled() is implicitly inline and never called, so it has no IR.
* Because this function is never called, the null pointer dereference in its body can never be executed.
*/
};
};
void testNPDClass(){
NPDClass N;
N.npd_inl_called(5);
}
To report problems with this documentation, please visit https://support.codesecure.com/.