:OS: /O-S/ 1. [Operating System] n. An abbreviation heavily used in email, occasionally in speech. 2. n.,obs. On ITS, an output spy. See "{OS and JEDGAR}" (in {appendix A}).
:OS/2: /O S too/ n. The anointed successor to MS-DOS for Intel 286- and 386-based micros; proof that IBM/Microsoft couldn't get it right the second time, either. Mentioning it is usually good for a cheap laugh among hackers —- the design was so {baroque}, and the implementation of 1.x so bad, that 3 years after introduction you could still count the major {app}s shipping for it on the fingers of two hands —- in unary. Often called `Half-an-OS'. On January 28, 1991, Microsoft announced that it was dropping its OS/2 development to concentrate on Windows, leaving the OS entirely in the hands of IBM; on January 29 they claimed the media had got the story wrong, but were vague about how. It looks as though OS/2 is moribund. See {vaporware}, {monstrosity}, {cretinous}, {second-system effect}.
:out-of-band: [from telecommunications and network theory] adj. 1. In software, describes values of a function which are not in its `natural' range of return values, but are rather signals that some kind of exception has occurred. Many C functions, for example, return either a nonnegative integral value, or indicate failure with an out-of-band return value of -1. Compare {hidden flag}, {green bytes}. 2. Also sometimes used to describe what communications people call `shift characters', like the ESC that leads control sequences for many terminals, or the level shift indicators in the old 5-bit Baudot codes. 3. In personal communication, using methods other than email, such as telephones or {snail-mail}.
:overflow bit: n. 1. [techspeak] On some processors, an attempt to calculate a result too large for a register to hold causes a particular {flag} called an {overflow bit} to be set. 2. Hackers use the term of human thought too. "Well, the {{Ada}} description was {baroque} all right, but I could hack it OK until they got to the exception handling … that set my overflow bit." 3. The hypothetical bit that will be set if a hacker doesn't get to make a trip to the Room of Porcelain Fixtures: "I'd better process an internal interrupt before the overflow bit gets set".
:overflow pdl: [MIT] n. The place where you put things when your {pdl} is full. If you don't have one and too many things get pushed, you forget something. The overflow pdl for a person's memory might be a memo pad. This usage inspired the following doggerel:
Hey, diddle, diddle
The overflow pdl
To get a little more stack;
If that's not enough
Then you lose it all,
And have to pop all the way back.
—The Great Quux
The term {pdl} seems to be primarily an MITism; outside MIT this term would logically be replaced by `overflow {stack}', but the editors have heard no report of the latter term actually being in use.
:overrun: n. 1. [techspeak] Term for a frequent consequence of data arriving faster than it can be consumed, esp. in serial line communications. For example, at 9600 baud there is almost exactly one character per millisecond, so if your {silo} can hold only two characters and the machine takes longer than 2 msec to get to service the interrupt, at least one character will be lost. 2. Also applied to non-serial-I/O communications. "I forgot to pay my electric bill due to mail overrun." "Sorry, I got four phone calls in 3 minutes last night and lost your message to overrun." When {thrash}ing at tasks, the next person to make a request might be told "Overrun!" Compare {firehose syndrome}. 3. More loosely, may refer to a {buffer overflow} not necessarily related to processing time (as in {overrun screw}).
:overrun screw: [C programming] n. A variety of {fandango on core} produced by scribbling past the end of an array (C implementations typically have no checks for this error). This is relatively benign and easy to spot if the array is static; if it is auto, the result may be to {smash the stack} —- often resulting in {heisenbug}s of the most diabolical subtlety. The term `overrun screw' is used esp. of scribbles beyond the end of arrays allocated with `malloc(3)'; this typically trashes the allocation header for the next block in the {arena}, producing massive lossage within malloc and often a core dump on the next operation to use `stdio(3)' or `malloc(3)' itself. See {spam}, {overrun}; see also {memory leak}, {memory smash}, {aliasing bug}, {precedence lossage}, {fandango on core}, {secondary damage}.
= P = =====