Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (2.10)  

CWE-570: Expression is Always False

Weakness ID: 570
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software contains an expression that will always evaluate to false.
+ Time of Introduction
  • Implementation
+ Applicable Platforms



+ Common Consequences

Technical Impact: Quality degradation; Varies by context

+ Demonstrative Examples

Example 1

In the following Java example the updateUserAccountOrder() method used within an e-business product ordering/inventory application will validate the product number that was ordered and the user account number. If they are valid, the method will update the product inventory, the user account, and the user order appropriately.

(Bad Code)
Example Language: Java 

public void updateUserAccountOrder(String productNumber, String accountNumber) {
boolean isValidProduct = false;
boolean isValidAccount = false;

if (validProductNumber(productNumber)) {
isValidProduct = true;
else {

if (validAccountNumber(accountNumber)) {
isValidProduct = true;
updateAccount(accountNumber, productNumber);

if (isValidProduct && isValidAccount) {
updateAccountOrder(accountNumber, productNumber);

However, the method never sets the isValidAccount variable after initializing it to false so the isValidProduct is mistakenly used twice. The result is that the expression "isValidProduct && isValidAccount" will always evaluate to false, so the updateAccountOrder() method will never be invoked. This will create serious problems with the product ordering application since the user account and inventory databases will be updated but the order will not be updated.

This can be easily corrected by updating the appropriate variable.

(Good Code)
if (validAccountNumber(accountNumber)) {
isValidAccount = true;
updateAccount(accountNumber, productNumber);

Example 2

In the following example, the hasReadWriteAccess method uses bit masks and bit operators to determine if a user has read and write privileges for a particular process. The variable mask is defined as a bit mask from the BIT_READ and BIT_WRITE constants that have been defined. The variable mask is used within the predicate of the hasReadWriteAccess method to determine if the userMask input parameter has the read and write bits set.

(Bad Code)
#define BIT_READ 0x0001 // 00000001
#define BIT_WRITE 0x0010 // 00010000

unsigned int mask = BIT_READ & BIT_WRITE; /* intended to use "|" */

// using "&", mask = 00000000
// using "|", mask = 00010001

// determine if user has read and write access
int hasReadWriteAccess(unsigned int userMask) {
// if the userMask has read and write bits set
// then return 1 (true)
if (userMask & mask) {
return 1;

// otherwise return 0 (false)
return 0;

However the bit operator used to initialize the mask variable is the AND operator rather than the intended OR operator (CWE-480), this resulted in the variable mask being set to 0. As a result, the if statement will always evaluate to false and never get executed.

The use of bit masks, bit operators and bitwise operations on variables can be difficult. If possible, try to use frameworks or libraries that provide appropriate functionality and abstract the implementation.

Example 3

In the following example, the updateInventory method used within an e-business inventory application will update the inventory for a particular product. This method includes an if statement with an expression that will always evaluate to false. This is a common practice in C/C++ to introduce debugging statements quickly by simply changing the expression to evaluate to true and then removing those debugging statements by changing expression to evaluate to false. This is also a common practice for disabling features no longer needed.

(Bad Code)
int updateInventory(char* productNumber, int numberOfItems) {

int initCount = getProductCount(productNumber);

int updatedCount = initCount + numberOfItems;

int updated = updateProductCount(updatedCount);

// if statement for debugging purposes only
if (1 == 0) {

char productName[128];
productName = getProductName(productNumber);

printf("product %s initially has %d items in inventory \n", productName, initCount);
printf("adding %d items to inventory for %s \n", numberOfItems, productName);

if (updated == 0) {
printf("Inventory updated for product %s to %d items \n", productName, updatedCount);

else {
printf("Inventory not updated for product: %s \n", productName);


return updated;

Using this practice for introducing debugging statements or disabling features creates dead code that can cause problems during code maintenance and potentially introduce vulnerabilities. To avoid using expressions that evaluate to false for debugging purposes a logging API or debugging API should be used for the output of debugging messages.

+ Potential Mitigations

Phase: Testing

Use Static Analysis tools to spot such conditions.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness VariantWeakness Variant561Dead Code
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory569Expression Issues
Development Concepts699
ChildOfCategoryCategory747CERT C Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory998SFP Secondary Cluster: Glitch in Computation
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingMSC00-CCompile cleanly at high warning levels
CERT C++ Secure CodingMSC00-CPPCompile cleanly at high warning levels
Software Fault PatternsSFP1Glitch in computation
+ Content History
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative_Examples, Other_Notes, Potential_Mitigations
2009-10-29CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

More information is available — Please select a different filter.
Page Last Updated: January 18, 2017