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 ...

• while ((ch=getchar()) != EOF) { ... }
• [aStream atEnd] whileFalse: [aCharacter := aStream next. ...]

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