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)

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

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?


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.

  • 5
    +1 - unless you're talking to a client. Then it's a feature.
    – Telastyn
    Dec 1 '14 at 3:20

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.

  • 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 1 '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 2 '14 at 6: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 2 '14 at 16:12

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.