vaxocentrism
vaxocentrism
1. The assumption that dereferencing a null pointer is safebecause it is all bits 0, and location 0 is readable and 0.Problem: this may instead cause an illegal-address trap onnon-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 thandeliberate exploitation of a misfeature.
2. The assumption that characters are signed.
3. The assumption that a pointer to any one type can freely becast into a pointer to any other type. A stronger form ofthis is the assumption that all pointers are the same size andformat, which means you don't have to worry about getting thecasts or types correct in calls. Problem: this fails onword-oriented machines or others with multiple pointerformats.
4. The assumption that the parameters of a routine are storedin memory, on a stack, contiguously, and in strictly ascendingor descending order. Problem: this fails on many RISCarchitectures.
5. The assumption that pointer and integer types are the samesize, and that pointers can be stuffed into integer variables(and vice-versa) and drawn back out without being truncated ormangled. Problem: this fails on segmented architectures orword-oriented machines with funny pointer formats.
6. The assumption that a data type of any size may begin atany byte address in memory (for example, that you can freelyconstruct and dereference a pointer to a word- orgreater-sized object at an odd char address). Problem: thisfails on many (especially RISC) architectures better optimisedfor HLL execution speed, and can cause an illegal addressfault or bus error.
7. The (related) assumption that there is no padding at theend of types and that in an array you can thus step right fromthe last byte of a previous component to the first byte of thenext one. This is not only machine- but compiler-dependent.
8. The assumption that memory address space is globally flatand that the array reference "foo[-1]" is necessarily valid.Problem: this fails at 0, or other places on segment-addressedmachines like Intel chips (yes, segmentation is universallyconsidered a brain-damaged way to design machines (seemoby), but that is a separate issue).
9. The assumption that objects can be arbitrarily large withno special considerations. Problem: this fails on segmentedarchitectures 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 almostanything else without virtual addressing and a paged stack.
11. The assumption that bits and addressable units within anobject are ordered in the same way and that this order is aconstant of nature. Problem: this fails on big-endianmachines.
12. The assumption that it is meaningful to compare pointersto different objects not located within the same array, or toobjects of different types. Problem: the former fails onsegmented architectures, the latter on word-oriented machinesor others with multiple pointer formats.
13. The assumption that an "int" is 32 bits, or (nearlyequivalently) the assumption that "sizeof(int) ==sizeof(long)". 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: thisfails in many embedded-systems C environments and even under afew flavours of Unix.
Note that a programmer can validly be accused of vaxocentrismeven if he or she has never seen a VAX. Some of theseassumptions (especially 2--5) were valid on the PDP-11, theoriginal C machine, and became endemic years before the VAX.The terms "vaxocentricity" and "all-the-world"s-a-VAXsyndrome' have been used synonymously.