JavaScriptMessages
APEC
Asia Pacific Economic Cooperation
News
Rss Feeds
SiteMap
Login
Glossary
Filter:
#
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
All
Return to List
V
V Model
V7
Vaccines
Vadding
Valid Password
Valid period
Validation
Validation (Testing)
Value of protection
Value Of The Represented
Value-Added Networks
Vanilla
Vannevar
Vaporware
Var
Variable Length Buffer
Variant
VAX
VAXectomy
VAXen
Vaxherd
Vaxism
Vaxocentrism
VBscript
Vdiff
VDT
Veeblefester
Vendor diversity
Vendor Security Analyst
Ventilator Card
Venus Flytrap
Verbage
Verbiage
Verifiable Identification Forwarding
Verification
Verification And Validation Process
Verified Design
Verifier
Version 7
Vgrep
Vi
Victimization software
Video Display Terminal
Video Display Unit
Video recorder
Video Signal
Videotex
Videotext
View
Viewdata
Violation
Violations
Virgin
Virtual
Virtual Call
Virtual Call Capability
Virtual Call Facility
Virtual Carrier Frequency
Virtual Circuit
Virtual Circuit Capability
Virtual Connection
Virtual Friday
Virtual Memory
Virtual Network
Virtual Password
Virtual private network (VPN)
Virtual Reality
Virtual Shredder
Virtual Storage
Virus
Visionary
VMS
Vocoder
Voice
Voice Communications Security
Voice Mail Security
Voice recognition
Voice-Net
Volatile Memory
Volatility
Volume
Voluntary tunneling
Voodoo Programming
VPN (virtual private network)
VR
VSA
VST
VTT
Vulcan Nerve Pinch
Vulnerability
Vulnerability Analysis
Vulnerability Assessment
Vulnerability assessment tools
Vulnerability reporters
Vulnerability testing
Vulnerability testing contract
Vulture Capitalist
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 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