Dead Code: Expression is Always True - Revision history

KirstenS at 23:28, 7 April 2009

2009-04-07T23:28:13Z

KirstenS at 10:10, 14 February 2009

2009-02-14T10:10:13Z

KirstenS at 12:28, 30 October 2008

2008-10-30T12:28:00Z

KirstenS at 22:11, 23 September 2008

2008-09-23T22:11:12Z

Weilin Zhong at 18:02, 19 July 2006

2006-07-19T18:02:41Z

New page

{{Template:Vulnerability}}
{{Template:Fortify}}

==Abstract==

This expression will always evaluate to true.

==Description==

This expression will always evaluate to true; the program could be rewritten in a simpler form. The nearby code may be present for debugging purposes, or it may not have been maintained along with the rest of the program. The expression may also be indicative of a bug earlier in the method.

==Examples ==

The following method never sets the variable secondCall after initializing it to true. (The variable firstCall is mistakenly used twice.) The result is that the expression firstCall || secondCall will always evaluate to true, so setUpForCall() will always be invoked.

<pre>
public void setUpCalls() {
boolean firstCall = true;
boolean secondCall = true;

if (fCall < 0) {
cancelFCall();
firstCall = false;
}
if (sCall < 0) {
cancelSCall();
firstCall = false;
}

if (firstCall || secondCall) {
setUpForCall();
}
}
</pre>

==Related Threats==

==Related Attacks==

==Related Vulnerabilities==

==Related Countermeasures==

==Categories==

[[Category:Code Quality Vulnerability]]

[[Category:Java]]

[[Category:Implementation]]

[[Category:Code Snippet]]

← Older revision		Revision as of 23:28, 7 April 2009
Line 3:		Line 3:
	#REDIRECT [[Failure to follow guideline/specification]]		#REDIRECT [[Failure to follow guideline/specification]]

−
−	~~__TOC__~~
−
−	~~[[ASDR Table of Contents]]~~

	Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''		Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

@@ Line 1: / Line 1: @@
-{{Template:Vulnerability}}
+{{template:CandidateForDeletion}}
-{{Template:Fortify}}
 __TOC__
@@ Line 7: / Line 9: @@
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
@@ Line 61: / Line 60: @@
 ==References==
 TBD

@@ Line 2: / Line 2: @@
 {{Template:Fortify}}
-[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
+__TOC__
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
-[[ASDR Table of Contents]]
+[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
@@ Line 95: / Line 95: @@
 [[Category:Implementation]]
 [[Category:Code Snippet]]

@@ Line 2: / Line 2: @@
 {{Template:Fortify}}
-==Abstract==
+[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 ==Description==
-==Examples ==
+==Risk Factors==
 The following method never sets the variable secondCall after initializing it to true. (The variable firstCall is mistakenly used twice.) The result is that the expression firstCall || secondCall will always evaluate to true, so setUpForCall() will always be invoked.
@@ Line 34: / Line 42: @@
 </pre>
-==Related Threats==
+==Related [[Attacks]]==
-==Related Attacks==
+In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
-==Related Vulnerabilities==
+Availability Vulnerability
-==Related Countermeasures==
+Authorization Vulnerability
-==Categories==
+Authentication Vulnerability
 [[Category:Code Quality Vulnerability]]
 [[Category:Java]]
 [[Category:Implementation]]
 [[Category:Code Snippet]]