vaxocentrism /vak`soh-sen'trizm/ n. analogy with `ethnocentrism' a
   notional disease said to afflict c programmers who persist in coding
   according to certain assumptions that are valid esp. 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 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 `sizeofint == sizeoflong'.  problem: this
  fails on pdp-11s, 286-based systems and even on 386 and 68000
  systems under some compilers and on 64-bit    systems like the
  alpha, of course.
  
 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.


see also:
vaxen hll brain-damaged moby big-endian 

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 "sizeofint ==
        sizeoflong".  problem: this fails on pdp-11s, 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
     
     
see also:
vaxen hll brain-damaged moby big-endian pdp-11 
intel 80286 intel 80386 motorola 68000 c jargon file