1. <programming> An {address}, from the point of view of a
	programming language.  A pointer may be typed, with its {type}
	indicating the type of data to which it points.

	The terms "pointer" and "reference" are generally
	interchangable although particular programming languages often
	differentiate these two in subtle ways.  For example, {Perl}
	always calls them references, never pointers.  Conversely, in
	C, "pointer" is used, although "a reference" is often used to
	denote the concept that a pointer implements.

	{Anthony Hoare} once said:

	Pointers are like jumps, leading wildly from one part of the
	data structure to another.  Their introduction into high-level
	languages has been a step backward from which we may never
	recover.

	[C.A.R.Hoare "Hints on Programming Language Design", 1973,
	Prentice-Hall collection of essays and papers by Tony Hoare].

	2. <operating system> (Or "mouse pointer") An {icon}, usually
	a small arrow, that moves on the screen in response to
	movement of a {pointing device}, typically a {mouse}.  The
	pointer shows the user which object on the screen will be
	selected etc. when a mouse button is clicked.

	(1999-07-07)

<memory management> /kash/ A small fast memory holding
	recently accessed data, designed to speed up subsequent access
	to the same data.  Most often applied to processor-memory
	access but also used for a local copy of data accessible over
	a network etc.

	When data is read from, or written to, {main memory} a copy is
	also saved in the cache, along with the associated main memory
	address.  The cache monitors addresses of subsequent reads to
	see if the required data is already in the cache.  If it is (a
	{cache hit}) then it is returned immediately and the main
	memory read is aborted (or not started).  If the data is not
	cached (a {cache miss}) then it is fetched from main memory
	and also saved in the cache.

	The cache is built from faster memory chips than main memory
	so a cache hit takes much less time to complete than a normal
	memory access.  The cache may be located on the same
	{integrated circuit} as the {CPU}, in order to further reduce
	the access time.  In this case it is often known as {primary
	cache} since there may be a larger, slower {secondary cache}
	outside the CPU chip.

	The most important characteristic of a cache is its {hit rate}
	- the fraction of all memory accesses which are satisfied from
	the cache.  This in turn depends on the cache design but
	mostly on its size relative to the main memory.  The size is
	limited by the cost of fast memory chips.

	The hit rate also depends on the access pattern of the
	particular program being run (the sequence of addresses being
	read and written).  Caches rely on two properties of the
	access patterns of most programs: temporal locality - if
	something is accessed once, it is likely to be accessed again
	soon, and spatial locality - if one memory location is
	accessed then nearby memory locations are also likely to be
	accessed.  In order to exploit spatial locality, caches often
	operate on several words at a time, a "{cache line}" or "cache
	block".  Main memory reads and writes are whole {cache lines}.

	When the processor wants to write to main memory, the data is
	first written to the cache on the assumption that the
	processor will probably read it again soon.  Various different
	policies are used.  In a {write-through} cache, data is
	written to main memory at the same time as it is cached.  In a
	{write-back} cache it is only written to main memory when it
	is forced out of the cache.

	If all accesses were writes then, with a write-through policy,
	every write to the cache would necessitate a main memory
	write, thus slowing the system down to main memory speed.
	However, statistically, most accesses are reads and most of
	these will be satisfied from the cache.  Write-through is
	simpler than write-back because an entry that is to be
	replaced can just be overwritten in the cache as it will
	already have been copied to main memory whereas write-back
	requires the cache to initiate a main memory write of the
	flushed entry followed (for a processor read) by a main memory
	read.  However, write-back is more efficient because an entry
	may be written many times in the cache without a main memory
	access.

	When the cache is full and it is desired to cache another line
	of data then a cache entry is selected to be written back to
	main memory or "flushed".  The new line is then put in its
	place.  Which entry is chosen to be flushed is determined by a
	"{replacement algorithm}".

	Some processors have separate instruction and data caches.
	Both can be active at the same time, allowing an instruction
	fetch to overlap with a data read or write.  This separation
	also avoids the possibility of bad {cache conflict} between
	say the instructions in a loop and some data in an array which
	is accessed by that loop.

	See also {direct mapped cache}, {fully associative cache},
	{sector mapping}, {set associative cache}.

	(1997-06-25)

<testing> The process of exercising a product to identify
	differences between expected and actual behaviour.  Typically
	testing is bottom-up: {unit testing} and {integration testing}
	by developers, {system testing} by testers, and {user
	acceptance testing} by users.

	{Test coverage} attempts to assess how complete a test has
	been.

	2. The second stage in a {generate and test} search
	{algorithm}.

	[{Jargon File}]

	(2003-09-24)

<object-oriented> In {object-oriented programming}, an
	instance of the data structure and behaviour defined by the
	object's {class}.  Each object has its own values for the
	{instance variables} of its class and can respond to the
	{methods} defined by its class.

	For example, an object of the "Point" class might have
	instance variables "x" and "y" and might respond to the "plot"
	method by drawing a dot on the screen at those coordinates.

	(2004-01-26)

<mathematics, data> A {directed acyclic graph}; i.e. a {graph}
	wherein there is only one route between any pair of {nodes},
	and there is a notion of "toward top of the tree" (i.e. the
	{root node}), and its opposite direction, toward the {leaves}.
	A tree with n nodes has n-1 edges.

	Although maybe not part of the widest definition of a tree, a
	common constraint is that no node can have more than one
	parent.  Moreover, for some applications, it is necessary to
	consider a node's {daughter} nodes to be an ordered {list},
	instead of merely a {set}.

	As a data structure in computer programs, trees are used in
	everything from {B-trees} in {databases} and {file systems}, to
	{game trees} in {game theory}, to {syntax trees} in a human or
	computer {languages}.

	(1998-11-12)

In {object-oriented programming} sending a message to an
	{object} (to invoke a {method}) is equivalent to calling a
	{procedure} in traditional programming languages, except that
	the actual code executed may only be selected at run time
	depending on the {class} of the object.  Thus, in response to
	the message "drawSelf", the method code invoked would be
	different if the target object were a circle or a square.

	(1995-02-16)

See {followup}.

<programming> (Or "remark") Explanatory text embedded in
	program {source} (or less often data) intended to help human
	readers understand it.

	Code completely without comments is often hard to read, but
	too heavily commented code isn't much better, especially if
	the comments are not kept up-to-date with changes to the code.
	Too much commenting may mean that the code is
	over-complicated.  A good rule is to comment everything that
	needs it but write code that doesn't need much of it.

	A particularly irksome form of over-commenting explains
	exactly what each statement does, even when it is obvious to
	any reasonably competant programmer, e.g.

		/* Open the input file */
		infd = open(input_file, O_RDONLY);

	(1998-04-28)

<software> 1. A temporary addition to a piece of code, usually
	as a {quick-and-dirty} remedy to an existing {bug} or
	{misfeature}.  A patch may or may not work, and may or may not
	eventually be incorporated permanently into the program.
	Distinguished from a {diff} or {mod} by the fact that a patch
	is generated by more primitive means than the rest of the
	program; the classical examples are instructions modified by
	using the front panel switches, and changes made directly to
	the binary executable of a program originally written in an
	{HLL}.  Compare {one-line fix}.

	2. To insert a patch into a piece of code.

	3. [in the Unix world] A {diff}.

	4. A set of modifications to binaries to be applied by a
	patching program.  {IBM} systems often receive updates to the
	{operating system} in the form of absolute {hexadecimal}
	patches.  If you have modified your OS, you have to
	disassemble these back to the {source code}.  The patches
	might later be corrected by other patches on top of them
	(patches were said to "grow scar tissue").  The result was
	often a convoluted {patch space} and headaches galore.

	There is a classic story of a {tiger team} penetrating a
	secure military computer that illustrates the danger inherent
	in binary patches (or, indeed, any patches that you can't - or
	don't - inspect and examine before installing).  They couldn't
	find any {trap doors} or any way to penetrate security of
	IBM's OS, so they made a site visit to an IBM office
	(remember, these were official military types who were
	purportedly on official business), swiped some IBM stationery,
	and created a fake patch.  The patch was actually the trapdoor
	they needed.  The patch was distributed at about the right
	time for an IBM patch, had official stationery and all
	accompanying documentation, and was dutifully installed.  The
	installation manager very shortly thereafter learned something
	about proper procedures.

	5. {Larry Wall}'s "patch" utility, which automatically applies
	a patch to a set of {source code} or other text files.  Patch
	accepts input in any of the four forms output by the {Unix}
	{diff} utility.  When the files being patched are not
	identical to those on which the diffs were based, patch uses
	{heuristics} to determine how to proceed.

	Diff and patch are the standard way of producing and applying
	updates under {Unix}.  Both have been ported to other
	{operating systems}.

	{Patch Home (http://www.gnu.org/software/patch/patch.html)}.

	[{Jargon File}]

	(2005-05-16)

{system administration}

<messaging> 1. {electronic mail}.

	2. The {Berkeley Unix} program for composing and reading
	{electronic mail}.  It normally uses {sendmail} to handle
	delivery.

	{Unix manual page}: mail(1)

	(1997-12-03)