.PP
.SS Library Routines:
.PP
.nf
  1) sigstack is not supported.
  2) alloca() returns memory allocated by `malloc()'.
.fi
.PP
No error checking is done with common library functions such as 
strcpy().
.PP
.SS Loading Object Code:
.PP
Loading object code files with debugging information  (the
file was compiled with the `-g` switch passed to the compiler)
may not work occassionally.
If this problem occurs, load the files with the -G switch.
If this happens with an object code file from a library,
set the -G switch in the 
.FL load_options
option, or load the library with the -G switch.
.PP
Variables declared with the 
.KW register 
storage class and loaded as object code may not be viewed from the environment.
.PP
All object code functions in an object code file should
be fully resolved before ANY of the functions in the file
are called.  \*n will always warn the user before a call into an 
unresolved compiled function.
The reason for this is that \*n cannot always detect calls
between object code functions in the same file.
Therefore, \*n creates an implied reference between any two functions
in the same object code file.
The 
.CO unres
and
.CO link
commands list these references as `(implied)'.
.PP
.SS Using '#undef':
.PP
If a macro is undefined using the
.PD undef
preprocessor directive in any loaded source file or
by the user in the environment, the macro cannot
be subsequently viewed.
This is true even if the scope is set to a location
where the macro should be defined.
The user can explicitly define the macro in the
environment to correct this situation.
.PP
.SS Name Conflicts:
.PP
If the user program tries to use the name of a \*n command, either
as a global variable or a function, the \*n command must be renamed
with the
.CO rename
command.  Confusion may still result if a macro or an automatic variable 
has the same name as a \*n command, as the value of the macro or 
variable name will be used instead of invoking the \*n function.
.PP
.SS Miscellaneous:
.PP
The use of absolute addresses in compiled
code is not supported.  This is not an issue when using the 
.LF cc
compiler.
.PP
Programs that change the terminal states can produce adverse
side-effects on the output of \*n commands.  These programs should 
set the 
.FL win_io 
option to have the program output sent to another terminal or window.
The problem can also be remedied by using the
.CO reset
command.
.PP
Programs that set the real or virtual unix timers will note strange
behavior when stopped at a break level.  The timer will still trigger,
but the effect will not be seen until the next statement is executed
in the environment.
.PP
The return value of the system call 
.LF getdtablesize
is slightly less than when a program is executing outside of \*n.
.PP
The
.CO where
function will sometimes miss one stack frame if interrupted in the middle of 
a system call which was called from another compiled function.  
E.g: if 'main' calls function 'foo' which calls compiled function 'fum' 
which calls 'read', and 'read' is interrupted, 
the stack trace will appear as: 
.nf
  read(arg1, arg2, arg3)
  /* missing function fum() here */
  foo(arg)
  main(argc,argv)
.fi
.PP
Some of the error and warning numbers may not exactly match what is printed
in the error appendix of the users guide.  An accurate listing can
always be seen by entering `help("errors");' to the \*n prompt.
.PP
Listings of statements entered into the environment may not be accurate
if multiple processes are being debugged.
