Editing Software bug (section)

== Types ==

Some notable types of bugs:

=== Design error ===

A bug can be caused by insufficient or incorrect design based on the specification. For example, given that the specification is to alphabetize a list of words, a design bug might occur if the design does not account for symbols; resulting in incorrect alphabetization of words with symbols.

=== Arithmetic ===

Numerical operations can result in unexpected output, slow processing, or crashing.<ref>{{cite conference
|author1=Anthony Di Franco
|author2=Hui Guo
|author3=Cindy Rubio-González
|title=A comprehensive study of real-world numerical bug characteristics
|conference=2017 32nd [[IEEE]]/[[Association for Computing Machinery |ACM]] International Conference on Automated Software Engineering (ASE)
|date=November 23, 2017
|publisher=[[IEEE]]
|doi=10.1109/ASE.2017.8115662}}</ref>
Such a bug can be from a lack of awareness of the qualities of the data storage such as a [[arithmetic precision|loss of precision]] due to [[rounding]], [[numerically unstable]] algorithms, [[arithmetic overflow]] and [[underflow]], or from lack of awareness of how calculations are handled by different software coding languages such as [[Division by zero#Computer arithmetic|division by zero]] which in some languages may throw an exception, and in others may return a special value such as [[NaN]] or [[Infinity#Computing|infinity]].

=== Control flow ===
{{See also|Logic error}}

A [[control flow]] bug, a.k.a. logic error, is characterized by code that does not fail with an error, but does not have the expected behavior, such as [[infinite loop]]ing, infinite [[Recursion (computer science)|recursion]], incorrect comparison in a [[Conditional (computer programming)|conditional]] such as using the wrong [[comparison operator]], and the [[off-by-one error]].

=== Interfacing ===
* Incorrect API usage.
* Incorrect protocol implementation.
* Incorrect hardware handling.
* Incorrect assumptions of a particular platform.
* [[Software incompatibility|Incompatible]] systems. A new [[API]] or [[communications protocol]] may seem to work when two systems use different versions, but errors may occur when a function or feature implemented in one version is changed or missing in another. In production systems which must run continually, shutting down the entire system for a major update may not be possible, such as in the telecommunication industry<ref name="Kimbler1998">{{cite book|first=K. |last=Kimbler|title=Feature Interactions in Telecommunications and Software Systems V|url={{google books |plainurl=y |id=q7BSGKJrWxsC|page=8}}|year=1998|publisher=IOS Press|isbn=978-90-5199-431-5|page=8}}</ref> or the internet.<ref name="Rahman2001">{{cite book|last=Syed |first=Mahbubur Rahman|title=Multimedia Networking: Technology, Management and Applications: Technology, Management and Applications|url={{google books |plainurl=y |id=e3rAmuQSUXkC|page=398}}|date=2001|publisher=Idea Group Inc (IGI)|isbn=978-1-59140-005-9|page=398}}</ref><ref name="WuIrwin2016">{{cite book|first1=Chwan-Hwa (John) |last1=Wu|first2=J. David|last2= Irwin|title=Introduction to Computer Networks and Cybersecurity|url={{google books |plainurl=y |id=bInNBQAAQBAJ|p=500}}|date=2016|publisher=CRC Press|isbn=978-1-4665-7214-0|page=500}}</ref><ref>[[rfc:1263|RFC 1263]]: "TCP Extensions Considered Harmful" quote: "the time to distribute the new version of the protocol to all hosts can be quite long (forever in fact). ... If there is the slightest incompatibly between old and new versions, chaos can result."</ref> In this case, smaller segments of a large system are upgraded individually, to minimize disruption to a large network. However, some sections could be overlooked and not upgraded, and cause compatibility errors which may be difficult to find and repair.
* Incorrect code annotations.

=== Concurrency ===
* [[Deadlock (computer science)|Deadlock]] {{endash}} a task cannot continue until a second finishes, but at the same time, the second cannot continue until the first finishes.
* [[Race condition]] {{endash}} multiple simultaneous tasks compete for resources.
* Errors in [[critical section]]s, [[mutual exclusion]]s and other features of [[Concurrent programming#Coordinating access to resources|concurrent processing]]. [[Time-of-check-to-time-of-use]] (TOCTOU) is a form of unprotected critical section.

=== Resourcing ===
{{See also|Runtime error}}
* [[Null pointer]] dereference.
* Using an [[uninitialized variable]].
* Using an otherwise valid instruction on the wrong [[data type]] (see [[packed decimal]]/[[binary-coded decimal]]).
* [[Access violation]]s.
* Resource leaks, where a finite system resource (such as [[memory leak|memory]] or [[handle leak|file handles]]) become exhausted by repeated allocation without release.
* [[Buffer overflow]], in which a program tries to store data past the end of allocated storage. This may or may not lead to an access violation or [[storage violation]]. These are frequently [[security bug]]s.
* Excessive recursion which—though logically valid—causes [[stack overflow]].
* Use-after-free error, where a [[Pointer (computer programming)|pointer]] is used after the system has freed the memory it references.
* Double free error.

=== Syntax ===
{{See also|Syntax error}}
* Use of the wrong [[Lexical analysis#Token|token]], such as performing assignment instead of [[==#Equality|equality test]]. For example, in some languages <nowiki>x=5</nowiki> will set the value of x to 5 while <nowiki>x==5</nowiki> will check whether x is currently 5 or some other number. Interpreted languages allow such code to fail. Compiled languages can catch such errors before testing begins.

=== Teamwork ===
* Unpropagated updates; e.g. programmer changes "myAdd" but forgets to change "mySubtract", which uses the same algorithm. These errors are mitigated by the [[Don't Repeat Yourself]] philosophy.
* Comments out of date or incorrect: many programmers assume the comments accurately describe the code.
* Differences between documentation and product.