On 4 Aug 99, at 16:26, Dean Kukral wrote:

> When you program in C or C++, the two most common languages
> in non-business computing, you use what are known as "pointers,"
> which are, simply put, addresses in memory.  A frequent error is
> to forget to set the value of a pointer, which then gets the default
> value of zero.  When the code goes to the zero memory location,
> the system traps it (because the system owns that location), and
> gives you an error, usually "general protection fault."  You can get
> the same error for other problems, too.  This is a "null data pointer
> variable," i.e. null=zero; data pointer variable = address.
> null = zero = default "unitialized" value.
>
> If a pointer erroneously has a value that is outside of the memory
> that the program "owns," then a protection fault can also occur.

  "Faults" occur when such errors are detected by the CPU hardware.

  One could reasonably ask why the software doesn't check for these things.
There are two basic reasons:

1.  The check would take time -- even in the 99.9% of cases where there is
nothing wrong.  Despite accusations of "code bloat", many programmers do
still, out of habit, try not to waste program cycles.

2.  The code that was running when the fault was detected may have been part
of the OS, but a bad pointer here is usually something it was handed by some
other *trusted* piece of code -- very often, a driver of some sort.  The
writers of the OS have no basis (except experience...) to expect such a
trusted module to hand the OS a bogus pointer.
  But it happens, wither because the driver is misconfigured or has gotten
corrupted or is for a different piece of hardware from what's actually
installed....




David G

                  Visit our website regularly for FAQs,
               articles, how-to's, tech tips and much more
                  http://nospin.com - http://nospin.org