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).
A rival brand actually pioneered the slogan: its original form was "Nothing sucks like Electrolux". It has apparently become a classic example (used in advertising textbooks) of the perils of not knowing the local idiom. But in 1996, the press manager of Electrolux AB, while confirming that the company used this slogan in the late 1960s, also tells us that their marketing people were fully aware of the possible double entendre and intended it to gain attention.
And gain attention it did -- the VAX-vacuum-cleaner people thought the slogan a sufficiently good idea to copy it. Several British hackers report that VAX's 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 in 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
See also VAX, TOPS-10, TOPS-20, Unix, runic.