Is there a name for an internal incorrect behaviour that does not manifest itself as a bug?

Question

To put this in context, I have the following scenario. I am writing a Common Lisp program that works with strings and lists of characters.

In a certain function foo, the value of a variable suff is a list of characters. Further on in the code, I forgot that suff was a list and treated it as a string, calling

(subseq suff 0 1)

I did not notice the mistake, because subseq works both on strings and lists:

CL-USER> (subseq "abc" 0 1)
"a"

CL-USER> (subseq '(#\a #\b #\c) 0 1)
(#\a)

So in the subsequent code I assumed I was working with strings while in fact I was moving around lists of characters.

These wrongly-typed results were finally formatted by the program's output function using (concatenate 'string .... I was lucky, because concatenate happily produces a string when given lists of characters as arguments.

I only discovered this mistake when adding more tests (yes, I know, TDD, but that's another topic) and testing foo directly.

Since my program was running properly - at the time my output function was the only piece of code that was using the corrupted data - I cannot say that the program as a whole contained a bug even though function foo, taken separately, was buggy.

Is there a special name to describe such an incorrect internal behaviour that does not manifest externally as a bug?

I would call it an "internal bug" or even a "masked bug", but that's just my opinion — SJuan76, Nov 30 '14 at 23:08
Can the downvoter please give me a hint as to how I can improve this question? — Giorgio, Dec 01 '14 at 07:24
Related: [What's the difference between fault, error and defect?](http://programmers.stackexchange.com/q/184412/1033) — mouviciel, Dec 01 '14 at 09:51

score 12 · Accepted Answer · answered Nov 30 '14 at 23:09

A bug is a bug even when no one has found it.

According with this wikipedia article:

A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

The behavior was not what you intended, so it's a bug. You may call it a latent bug, a dormant bug, etc.

Some bugs have only a subtle effect on the program's functionality, and may thus lie undetected for a long time.

According to that article, the bug you talk about could be classified as a "resource bug", meaning:

Using an otherwise valid instruction on the wrong data type

In conclusion, what hasn't yet manifested itself externally, is really a dormant bug, waiting for an specific situation to manifest itself, usually in a production environment and during a weekend.

+1 - unless you're talking to a client. Then it's a feature. — Telastyn, Dec 01 '14 at 03:20

score 6 · Answer 2 · answered Dec 01 '14 at 02:51

6

I've always heard them called "latent bugs".

On all the teams I've worked on, it's good practice to identify latent bugs and fix them before someone experiences them.

In the situation you describe, it may or may not be a problem, if the language is just working around the oversight. But if the way it's working causes a performance problem because it's breaking things up and reassembling them the long way, then that is undesirable behavior, and is fair game to flag as a bug, even if the explicit output is correct.

answered Dec 01 '14 at 02:51

sea-rob

6,841
1
24
47

In my case the language is not working around the problem, it is just a chance that two false assumptions cancel each other out. So, I would consider it a bug. – Giorgio Dec 01 '14 at 12:57
Agree. The risk is that because the assumptions are off, you might hit a circumstance where the false assumptions *don't* cancel each other out, and something unexpected happens. – sea-rob Dec 02 '14 at 06:34
Exactly: the first function is buggy. Event if it were private and the public functions used it in a way that does not produce any observable defect, there is still a bug lying around. – Giorgio Dec 02 '14 at 16:12

score 3 · Answer 3 · edited May 23 '17 at 11:33

You are describing a semantic error. One that was not caught by your language and did not cause a problem with the proper execution of the software.

Whenever you write code you are writing for many audiences that need to be satisfied. You satisfied your language and your user. You failed to satisfy your maintenance developer.

Semantics are about meaning. By forgetting to treat suff as a list you wrote code whose meaning is difficult to understand. The fact that the end result is identical is no more correct than if you got the correct answer on a math test by forgetting a negative twice. Most professors would mark you down for that because they are looking for meaning in your answer, not luck.

Anyone looking at your code later (including you) will feel the same way. Code that works but makes no sense is a special kind of frustrating.

Unfortunately if you search on semantic errors you'll mostly find the ones that the programming languages catch for you. As you've discovered, not every kind of semantic error can be caught automaticly.

If you had violated the semantics intentionally, just to make something that works, then it could easily be called a kludge. Infact, anyone reading your code and not knowing your intent could justifiably call it one.

score -2 · Answer 4 · answered Nov 30 '14 at 23:07

-2

That'd be a logic error. See the wiki article for more information.

answered Nov 30 '14 at 23:07

Defenestrator

7
2

Is there a name for an internal incorrect behaviour that does not manifest itself as a bug?

4 Answers4