Source : Free On-Line Dictionary of Computing

vaxocentrism
     
        /vak"soh-sen"trizm/ [analogy with "ethnocentrism"] A notional
        disease said to afflict C programmers who persist in coding
        according to certain assumptions that are valid (especially
        under Unix) on {VAXen} but false elsewhere. Among these are:
     
        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 (especially RISC) architectures better optimised
        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-11}s, {Intel
        80286}-based systems and even on {Intel 80386} and {Motorola
        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 flavours 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 (especially 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.
     
        [{Jargon File}]