Date: 8 Feb 2002 20:35:32 -0400

 Somewhere in your program, you assigned a value through a pointer
 without first assigning a value to the pointer. (This might have been
 something like a strcpy() or memcpy() with a pointer as its first
 argument, not necessarily an actual assignment statement.)

 Your program may look like it ran correctly, but if you get this message
 you can be certain that there's a bug somewhere.

 Microsoft and Borland C, as part of their exit code (after a call to
 exit() or a return from your main function), check whether the location
 0000 in your data segment contains a different value from what you
 started with. If so, they infer that you must have used an uninitialized
 pointer. This implies that the message will appear at the end of
 execution of your program regardless of where the error actually
 occurred.

 To track down the problem, you can put exit() calls at various spots in
 the program and narrow down where the uninitialized pointer is being
 used by seeing which added exit() makes the null-pointer message
 disappear. Or, if your program was compiled with small or medium models,
 which use 16-bit data pointers, tell the debugger to set a watch at
 location 0000 in your data segment. (If data pointers are 32 bits, as in
 the compact and large models, a null pointer will overwrite the
 interrupt vectors at 0000:0000 and probably lock up your machine.)

 Under MSC/C++ 7.0, you can declare the undocumented library function:
 extern _cdecl _nullcheck(void);

 Sprinkle calls to _nullcheck() through your program at regular
 intervals.

 Borland's TechFax document TI726 discusses the null pointer assignment
 from a Borland point of view. It's one of many documents downloadable as
 part of: <http://www.simtel.net/pub/pd/50843.html>
 <ftp://garbo.uwasa.fi/pc/turbopas/>