The most extreme and dangerous form of vadding is `elevator
rodeo', a.k.a. `elevator surfing', a sport played by wrasslin'
down a thousand-pound elevator car with a 3-foot piece of
string, and then exploiting this mastery in various stimulating
ways (such as elevator hopping, shaft exploration, rat-racing, and
the ever-popular drop experiments). Kids, don't try this at home!
See also hobbit (sense 2).
It is sometimes claimed that this slogan was *not* actually
used by the Vax vacuum-cleaner people, but was actually that of a
rival brand called Electrolux (as in "Nothing sucks
like..."). It has been reliably confirmed that Electrolux (a
Swedish company) actually did use this slogan in the late 1960s; it
has apparently become a classic example (used in textbooks) of the
perils of not knowing the local idiom.
It appears, however, that the Vax people thought the slogan a
sufficiently good idea to copy it. Several British hackers report
that their promotions used it in 1986--1987, and we have one report
from a New Zealander that the infamous slogan surfaced there in TV
ads for the product as recently as 1992!
1. The assumption that dereferencing a null pointer is safe because it
is all bits 0, and location 0 is readable and 0. Problem: this may
instead cause an illegal-address trap on non-VAXen, and even on
VAXen under OSes other than BSD UNIX. Usually this is an implicit
assumption of sloppy code (forgetting to check the pointer before
using it), rather than deliberate exploitation of a misfeature.
2. The assumption that characters are signed.
3. The assumption that a pointer to any one type can freely be cast
into a pointer to any other type. A stronger form of this is the
assumption that all pointers are the same size and format, which
means you don't have to worry about getting the casts or types
correct in calls. Problem: this fails on word-oriented machines or
others with multiple pointer formats.
4. The assumption that the parameters of a routine are stored in
memory, on a stack, contiguously, and in strictly ascending or
descending order. Problem: this fails on many RISC architectures.
5. The assumption that pointer and integer types are the same size,
and that pointers can be stuffed into integer variables (and
vice-versa) and drawn back out without being truncated or mangled.
Problem: this fails on segmented architectures or word-oriented
machines with funny pointer formats.
6. The assumption that a data type of any size may begin at any byte
address in memory (for example, that you can freely construct and
dereference a pointer to a word- or greater-sized object at an odd
char address). Problem: this fails on many (esp. RISC)
architectures better optimized for HLL execution speed, and can
cause an illegal address fault or bus error.
7. The (related) assumption that there is no padding at the end of
types and that in an array you can thus step right from the last
byte of a previous component to the first byte of the next one.
This is not only machine- but compiler-dependent.
8. The assumption that memory address space is globally flat and that
the array reference `foo[-1]' is necessarily valid. Problem: this
fails at 0, or other places on segment-addressed machines like
Intel chips (yes, segmentation is universally considered a
brain-damaged way to design machines (see moby), but that is a
separate issue).
9. The assumption that objects can be arbitrarily large with no
special considerations. Problem: this fails on segmented
architectures and under non-virtual-addressing environments.
10. The assumption that the stack can be as large as memory. Problem:
this fails on segmented architectures or almost anything else
without virtual addressing and a paged stack.
11. The assumption that bits and addressable units within an object are
ordered in the same way and that this order is a constant of
nature. Problem: this fails on big-endian machines.
12. The assumption that it is meaningful to compare pointers to
different objects not located within the same array, or to objects
of different types. Problem: the former fails on segmented
architectures, the latter on word-oriented machines or others with
multiple pointer formats.
13. The assumption that an `int' is 32 bits, or (nearly equivalently)
the assumption that `sizeof(int) == sizeof(long)'. Problem: this
fails on PDP-11s, 286-based systems and even on 386 and 68000
systems under some compilers.
14. The assumption that `argv[]' is writable. Problem: this fails in
many embedded-systems C environments and even under a few flavors
of UNIX.
Note that a programmer can validly be accused of vaxocentrism
even if he or she has never seen a VAX. Some of these assumptions
(esp. 2--5) were valid on the PDP-11, the original C machine, and
became endemic years before the VAX. The terms `vaxocentricity'
and `all-the-world's-a-VAX syndrome' have been used synonymously.
In the 1990s, viruses have become a serious problem, especially
among IBM PC and Macintosh users (the lack of security on these
machines enables viruses to spread easily, even infecting the
operating system). The production of special anti-virus software
has become an industry, and a number of exaggerated media reports
have caused outbreaks of near hysteria among users; many
lusers tend to blame *everything* that doesn't work as
they had expected on virus attacks. Accordingly, this sense of
`virus' has passed not only into techspeak but into also popular
usage (where it is often incorrectly used to denote a worm or
even a Trojan horse). See phage; compare back door;
see also UNIX conspiracy.
There once was a system called VMS
Of cycles by no means abstemious.
It's chock-full of hacks
And runs on a VAX
And makes my poor stomach all squeamious.
--- The Great Quux