A Catalogue of Software Bugs-I: Bugs Grounded in Common Misconceptions About Programming

Posted on March 17, 2011


This  four part  series is co-authored by Vikas Kumar and Sanjay Goel.  The second part is A Catalogue of Software Bugs–II: Bugs Grounded in Common Misconceptions About Operating Systems Resources

Vikas has been one of my most favourite students.   He can be approached at (http://www.linkedin.com/pub/vikas-kumar/a/658/500)


A software bug is an anomaly in behavior of running program. Detection and fixing of bugs is an ongoing process and a major task in software development and evolution. According to Humphrey (2008), more than half a typical software organization’s effort is devoted to finding and fixing defects.  Typically every software company consider debugging as a key skill for its engineers.  Proficiency in debugging is integral to deep understanding of software development. A majority of bugs can be traced to either design or implementation issues. These issues are because of misconceptions or lack of appropriate understanding on programmers’ part. These programmers’ misconceptions result in violation of restrictions or non fulfillment of expectations of  (i) Programming Fundamentals, (ii) Operating System’s resources, (iii) Compiler, (iv) Database Management System, or (v) Software Design. In this paper, we list some  common bugs resulting from incorrect usage or understanding of primitives provided by programming language.  The other kind of bugs are (will be) discussed in  other papers of this series.  Interested readers are encouraged to see the following papers: i.    ii.  iii.  Prograaming language related  bugs are  further classified as data loss bug, data overflow bug, operator precedence related bug, string handling bug, switch statement related bug, arithmetical function or operator related bugs and function like macro related bug. To elucidate bug code snippet in ‘C’ programming language is used.   In this catalogue, we don’t claim to have captured all the misconceptions related to programming fundamentals.  Hence, this catalogues is only partial. 1.  Data Loss bug Inadequate awareness about the importance of data type can cause bugs which at times can be subtle.

1.1 Storing float values in integer data type will result in truncation of decimal part.

1.2 Using unsigned data type when values can be negative will make negative value appear positive and hence result in unexpected behavior.

2.   Data Overflow bug

Initializing variable with value outside its range may result in unexpected behaviour (Vipindeep & Jalote,2005). int a,b,c,d; //…. if ((a=b*c) <d) return 1; else return 0; If value of b*c exceeds integer range then it causes an overflow resulting in setting of sign bit and hence the function will return 1 instead of 0.

3.   Operator Precedence related bug

Wrong assumption of operator precedence on part of programmer can result in subtle bugs. main() { int i=10; i=!i>14; printf(“i=%d”,i); } Output of this program will surprise programmer as they expect it to evaluate to false. To avoid such bugs programmer can use parentheses to explicitly indicate precedence.

4.   String handling bug

String handling bugs are mainly due to lack of validation checks in string functions provided by string library. These functions typically do not have NULL checks. So passing NULL arguments will result in program termination. Also, input arguments may not be NULL terminated or more than one input arguments point to same memory which may be problematic depending on implementation of different string functions. To avoid such bugs, programmer can writer wrapper functions on top of string library provided functions to do validation checks on input arguments and return errors gracefully on error conditions.

5.   Switch statement related bug

Programmer may code for only those cases which is normally expected during program execution. However, if any case other than explicitly coded in program occurs then program will silently ignore that case and may end up producing wrong output. Programmer can add default case with suitable prints for every switch statement to help quicker debugging.

6.   Logical Operators related bug

Use of logical operators in conditional statements may cause bug. int i=-1,j=-1; if (i++ || j++) printf (“true i=%d j=%d”, i, j); Output of program will surprise novice programmer because of their misconception of logical operators.

7.   Arithmetical function or operator related bug

These bugs are associated with violation of arithmetic model supported by programming language. Typically, division by zero, taking square root or log of negative numbers, and operations producing too large a number to be stored or too small a number to be stored can result in bug.

8.   Function like macro bug

Function like macro gives the convenience and readability of a function call without actually doing function call, thereby saving cost of function call. However, careless usage of it can introduce subtle bugs. Typical scenarios of these bugs are:

8.1 Using expression arguments in function like macro

Because of operator precedence, results can be inconsistent depending on exact expression argument used and the macro definition (Eckel, 2000, chap. 9). #define FLOOR(x,b) x>=b?0:1 if(FLOOR(a&0x0f,0x07))  // …the macro will expand to if(a&0x0f>=0x07?0:1) The precedence of & is lower than that of >=, so the macro evaluation will give unexpected result. In order to avoid such bugs everything in a macro should be parenthesized.

8.2 Side effects of evaluation of arguments in function like macro

Unlike normal function macro arguments are evaluated every time it is used. If arguments are ordinary variable there is no concern for unexpected result, but if evaluation of arguments have side effect then result can be surprising (Eckel, 2000, chap. 9). #define BAND(x) (((x)>5 && (x)<10) ? (x) : 0) BAND(++a); Depending on different values of ‘a’ it will be incremented once, twice or thrice. While a real function call would only do one increment. The only way to get correct behavior is to have real function in this scenario.

8.3 Multi line function like macro

When function like macros are used with conditional statements like ‘while’ and ‘if’, incorrect behaviour is likely (Cline, 1991). while(flag) MACRO(X); In this case only first line of MACRO(X) gets executed in while loop. Similar is the case of usage of MACRO(X) with if statement. One can use curly bracket to enclose multiple lines of MACRO(X). This would work with ‘while’ statement. But with ‘if-else’ statement compilation error would occur as when macro is expanded compiler will see ‘;’ before ‘else’ statement and complain. Recommended alternative are enclosing codes of MACRO(X) in a ‘do- while’ loop or ‘if-else’ statement: do { …} while(FALSE); if (TRUE) { … } else (void) 0;

8.4 Function like macro containing ‘if’ statement

If these macros are used with if statement, compiler can mismatch ‘else’ part of ‘if-else’ statement from which macro is called with ‘if’ statement contained in the macro. Just as with multi line macro, these macros can either be enclosed in do-while loop or ‘if’ statement of macro must be made to contain ‘else’ part with ‘(void) 0’. _________________________________________ Separate catalogues for bugs  grounded  in misconceptions about operating systems, compiler, and software archiotecture shall be posted in later articles. Programming community is invited to suggest the gaps in this catalogue. Faculty members are encouraged to use this catalogue in their programming courses.  We shall appreciate the feedback from working professionals, faculty members,  and students. Also Refer: Software Development Activities: A Catalogue of Technical and Technically Oriented Activities Software Developers’ Desired Competencies: A Comprehensive Distilled View  

Posted in: Uncategorized