In Band Signal

When you get a busy signal, it comes through the same band (using the same bandwidth) as the voice you hoped to hear. This in-band signal is convenient because it appears just where you were listening and you know what to do.

It also ties up a lot of switching equipment and trunk capacity for a rather small bit (BooleanRepresentation) of information. And it isn't all that easy to interpret when it's a machine placing the call. Finally, in-band signals are subject to spoofing which has been the mechanism of considerable telephone fraud.


Compare these two idioms ...

The former uses an in-band signal for end-of-input, the latter sends it through a separate band. One is easily made atomic, though not idempotent. The other conserves type-space even though it is hardly in short supply.


In WritingSolidCode by SteveMaguire, he spends a chapter discussing InBandSignal(s), and how, especially in the C libraries, they make it easy to write bad code. Two examples from the book:

1) The getchar() function mentioned above. Because of the name, it's easy to think that it returns a char, even though it returns an int because of the InBandSignal

2) Memory management functions like realloc, which return the InBandSignal NULL which indicates an "unable to complete operation" signal. If a programmer isn't careful, the signal will be ignored, leading to memory leaks, e.g.

  pbBuf = realloc(pbBuf, sizeNew);
  if (bpBuf != NULL)
	/* use the larger buffer */

Modern languages generally use exceptions instead of in band signals.

A more recent example of an InBandSignal being used (in C) for nefarious purposes are FormatStringAttacks


CategoryJargon

EditText of this page (last edited June 19, 2010) or FindPage with title or text search