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?
3
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
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.
3
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.
That’d be a logic error. See the wiki article for more information.