1. n. A temporary addition to a piece of code,
usually as a quick-and-dirty remedy to an existing bug or
misfeature. A patch may or may not work, and may or may not
eventually be incorporated permanently into the program.
Distinguished from a diff or mod by the fact that a patch
is generated by more primitive means than the rest of the program;
the classical examples are instructions modified by using the front
panel switches, and changes made directly to the binary executable
of a program originally written in an HLL. Compare
one-line fix. 2. vt. To insert a patch into a piece of code.
3. [in the Unix world] n. A diff (sense 2). 4. A set of
modifications to binaries to be applied by a patching program. IBM
operating systems often receive updates to the operating system in
the form of absolute hexadecimal patches. If you have modified
your OS, you have to disassemble these back to the source. The
patches might later be corrected by other patches on top of them
(patches were said to "grow scar tissue"). The result was often
a convoluted patch space and headaches galore. 5. [Unix] the
patch(1) program, written by Larry Wall, which automatically
applies a patch (sense 3) to a set of source code.
There is a classic story of a tiger team penetrating a secure
military computer that illustrates the danger inherent in binary
patches (or, indeed, any patches that you can't -- or don't --
inspect and examine before installing). They couldn't find any
trap doors or any way to penetrate security of IBM's OS, so
they made a site visit to an IBM office (remember, these were
official military types who were purportedly on official business),
swiped some IBM stationery, and created a fake patch. The patch
was actually the trapdoor they needed. The patch was distributed
at about the right time for an IBM patch, had official stationery
and all accompanying documentation, and was dutifully installed.
The installation manager very shortly thereafter learned something
about proper procedures.
