The Hacker's Dictionary - - (the best novels to read .txt) 📗

next day hacking. "I need to go home and crash; I'm starting to get a lot of parity errors." Derives from a relatively common but nearly always correctable transient error in RAM hardware.

:Parkinson's Law of Data: prov. "Data expands to fill the space available for storage"; buying more memory encourages the use of more memory-intensive techniques. It has been observed over the last 10 years that the memory usage of evolving systems tends to double roughly once every 18 months. Fortunately, memory density available for constant dollars tends to double about once every 12 months (see {Moore's Law}); unfortunately, the laws of physics guarantee that the latter cannot continue indefinitely.

:parm: /parm/ n. Further-compressed form of {param}. This term is an IBMism, and written use is almost unknown outside IBM

shops; spoken /parm/ is more widely distributed, but the synonym {arg} is favored among hackers. Compare {arg}, {var}.

:parse: [from linguistic terminology] vt. 1. To determine the syntactic structure of a sentence or other utterance (close to the standard English meaning). "That was the one I saw you." "I can't parse that." 2. More generally, to understand or comprehend. "It's very simple; you just kretch the glims and then aos the zotz." "I can't parse that." 3. Of fish, to have to remove the bones yourself. "I object to parsing fish", means "I don't want to get a whole fish, but a sliced one is okay". A parsed fish' has been deboned. There is some controversy over whetherunparsed' should mean bony', or also meandeboned'.

:Pascal:: n. An Algol-descended language designed by Niklaus Wirth on the CDC 6600 around 1967--68 as an instructional tool for elementary programming. This language, designed primarily to keep students from shooting themselves in the foot and thus extremely restrictive from a general-purpose-programming point of view, was later promoted as a general-purpose tool and, in fact, became the ancestor of a large family of languages including Modula-2 and {{Ada}} (see also {bondage-and-discipline language}). The hackish point of view on Pascal was probably best summed up by a devastating (and, in its deadpan way, screamingly funny) 1981 paper by Brian Kernighan (of {K&R} fame) entitled "Why Pascal is Not My Favorite Programming Language", which was turned down by the technical journals but circulated widely via photocopies. It was eventually published in "Comparing and Assessing Programming Languages", edited by Alan Feuer and Narain Gehani (Prentice-Hall, 1984). Part of his discussion is worth repeating here, because its criticisms are still apposite to Pascal itself after ten years of improvement and could also stand as an indictment of many other bondage-and-discipline languages. At the end of a summary of the case against Pascal, Kernighan wrote: 9. There is no escape

This last point is perhaps the most important. The language is inadequate but circumscribed, because there is no way to escape its limitations. There are no casts to disable the type-checking when necessary. There is no way to replace the defective run-time environment with a sensible one, unless one controls the compiler that defines the "standard procedures". The language is closed. People who use Pascal for serious programming fall into a fatal trap. Because the language is impotent, it must be extended. But each group extends Pascal in its own direction, to make it look like whatever language they really want. Extensions for separate compilation, FORTRAN-like COMMON, string data types, internal static variables, initialization, octal numbers, bit operators, etc., all add to the utility of the language for one group but destroy its portability to others. I feel that it is a mistake to use Pascal for anything much beyond its original target. In its pure form, Pascal is a toy language, suitable for teaching but not for real programming.

Pascal has since been almost entirely displaced (by {C}) from the niches it had acquired in serious applications and systems programming, but retains some popularity as a hobbyist language in the MS-DOS and Macintosh worlds.

:pastie: /pay'stee/ n. An adhesive-backed label designed to be attached to a key on a keyboard to indicate some non-standard character which can be accessed through that key. Pasties are likely to be used in APL environments, where almost every key is associated with a special character. A pastie on the R key, for example, would remind the user that it is used to generate the rho character. The term properly refers to nipple-concealing devices formerly worn by strippers in concession to indecent-exposure laws; compare {tits on a keyboard}.

:patch: 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 that you can't --- or don't --- inspect and examine before installing). They couldn't find any {trap door}s 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.

:patch space: n. An unused block of bits left in a binary so that it can later be modified by insertion of machine-language instructions there (typically, the patch space is modified to contain new code, and the superseded code is patched to contain a jump or call to the patch space). The widening use of HLLs has made this term rare; it is now primarily historical outside IBM

shops. See {patch} (sense 4), {zap} (sense 4), {hook}.

:path: n. 1. A {bang path} or explicitly routed {{Internet address}}; a node-by-node specification of a link between two machines. 2. [UNIX] A filename, fully specified relative to the root directory (as opposed to relative to the current directory; the latter is sometimes called a relative path'). This is also called apathname'. 3. [UNIX and MS-DOS] The `search path', an environment variable specifying the directories in which the {shell} (COMMAND.COM, under MS-DOS) should look for commands.

Other, similar constructs abound under UNIX (for example, the C preprocessor has a search path' it uses in looking for#include' files).

:pathological: adj. 1. [scientific computation] Used of a data set that is grossly atypical of normal expected input, esp. one that exposes a weakness or bug in whatever algorithm one is using. An algorithm that can be broken by pathological inputs may still be useful if such inputs are very unlikely to occur in practice.

When used of test input, implies that it was purposefully engineered as a worst case. The implication in both senses is that the data is spectacularly ill-conditioned or that someone had to explicitly set out to break the algorithm in order to come up with such a crazy example. 3. Also said of an unlikely collection of circumstances. "If the network is down and comes up halfway through the execution of that command by root, the system may just crash." "Yes, but that's a pathological case." Often used to dismiss the case from discussion, with the implication that the consequences are acceptable since that they will happen so infrequently (if at all) that there is no justification for going to extra trouble to handle that case (see sense 1).

:payware: /pay'weir/ n. Commercial software. Oppose {shareware}

or {freeware}.

:PBD: /P-B-D/ [abbrev. of `Programmer Brain Damage'] n. Applied to bug reports revealing places where the program was obviously broken by an incompetent or short-sighted programmer. Compare {UBD}; see also {brain-damaged}.

:PC-ism: /P-C-izm/ n. A piece of code or coding technique that takes advantage of the unprotected single-tasking environment in IBM PCs and the like, e.g., by busy-waiting on a hardware register,