.if n .pH rn4.chap7 @(#)chap7	40.36
.\" Copyright 1989 AT&T
.BK "Software Notes"
.CH "C Programming Language" "7"
.H 1 "C Programming Language Notes"
.IX istart UNIX System V Release 4, C Language notes
.H 3 "\f4su\fP Command"
.IX \f4su\fP(1M)
After a normal user executes \f4su\f1
to become superuser, the
.SM CCS
commands are no longer available
as they were in pre-SVR4.0 releases.  In SVR4.0 the default
super user path no longer includes the path to these commands;
therefore, the user should invoke these commands 
with a full pathname.  Alternately, the required path can 
be appended onto the \f4PATH\fP environment variable.
.H 3 "\f4dump\fP Command"
.IX \f4dump\fP(1)
The \f4dump\f1(1)
command will return a status code
indicating successful completion (return code set to zero),
despite the following cases of bad input:
.BL
.LI
number out of range
.LI
invalid range
.LI
filename not found
.LI
no such file or directory
.LI
invalid file type
.LI
bad line info section
.LE
.H 3 "\f4nm\fP Command"
.IX \f4nm\fP(1)
The \f4nm\f1(1)
command will return a status code
indicating successful completion (return code set to zero),
despite the following cases of bad input:
.BL
.LI
invalid file type
.LI
no such file or directory
.LI
truncated file
.LE
.H 3 "External Data/Automatics Order"
As always, the order of external data and automatics on the stack
should not be relied upon.
In particular, the compilation system is free to do register allocation.
.H 3 "\f4make\fP Command"
.IX \f4make\fP(1)
The \f4make\f1(1) command does not support file names
that are more than 14 characters long.
.H 3 "\f4nlist\fP Function"
.IX \f4nlist\fP(3E)
The \f4nlist\f1 function moved from the C library (\f4libc\f1) to the
.SM ELF
library (\f4libelf\f1).
This means the \f4make\f1 lines of those programs using
\f4nlist\f1 need to be changed to explicitly look in \f4libelf\f1:
.DS I UI
cc -o \f2prog prog\fP.c -lelf
.DE
Likewise, the manual page moved from \f4nlist\f1(3C) to \f4nlist\f1(3E).
.H 3 "Null Pointer References"
.IX null pointer
Not all null pointer references in the source code have been
fixed.
.H 3 "\f4ctrace\fP Command"
.IX \f4ctrace\fP(1)
The \f4ctrace\f1(1) command does not handle \f4asm\f1s.
.H 3 "\f4ld\fP Command"
.IX \f4ld\fP(1)
.BL
.LI
Error messages from the link editor that refer to I/O errors
may be caused by an inability to create a file.
This may be caused by file space limitation,
permission problems, or \f4ulimit\f1 problems.
.LI
Error messages from the link editor that specify
\f4vm stats\f1 errors or
\f4output file space\f1 may result from running out of system swap space.
.LE
.H 3 "\f4lint\fP Command"
.IX \f4lint\fP(1)
.BL
.LI
\f4lint -p\f1 gives the diagnostic ``\f4pointer cast may be troublesome\f1''
when two pointers differ only by a \f4const\f1.
(For example, \f4const int *\f1 versus \f4int *\f1.)
.LI
\f4lint\f1's \f4printf\f1 format checks do not recognize positional
parameters.
Therefore, \f4printf("$1", s);\f1 will yield the warning ``\f4too many
arguments for format\f1.''
.LE
.H 3 "\f4lprof\fP Command"
.IX \f4lprof\fP(1)
The \f4lprof\f1(1) command does not ignore C code included via a header file.
When it encounters a function that is defined in a header file,
it begins outputting line numbers and line counts.  Since this code does
not appear in the original C file, the line counts will be off.
A work-around to this problem is to place the C
functions from the header file(s) into \f4.c\f1 files and compile them
as separate modules.
.H 3 "\f4free\fP Function"
.IX \f4free\f1(3C)
A \f4malloc\f1'ed region of space can be freed
only once. Freeing the same region of space more
than once may cause unexpected behavior in SVR4.
.H 3 "\f4realloc\fP Function"
The \f4libmalloc\f1 version of \f4realloc\f1 has been changed for
.SM "ANSI C"
conformance.  If its size argument is zero, the object
pointed to by the first argument is freed.  (Previously, if
its size argument was zero, \f4realloc\f1 simply returned \f4NULL\fP.)
The previous libc version of \f4realloc\f1 had behavior
compatible with
.SM "ANSI C"
when the size argument was zero.
.H 3 "\f4sdb\fP Command"
.IX \f4sdb\fP(1)
.BL
.LI
Assembler language routines that use the frame pointer and argument
pointer registers in non-standard ways may cause erroneous stack traces in \f4sdb\f1.
The \f4__doprnt\f1 function is an example.
.LI
Header files that include executable code may cause confusion
with various tools (such as \f4sdb\f1) about line numbers.
The result is that output from the tools relating to
a function described in a header file may be associated with
the wrong line number.
.LI
When a process is grabbed (via "\f4sdb /proc/123\f1", for example), you
may examine variables, instruction step, quit, continue, or kill
the process.
However, breakpoints and some statement steps will not work.
The process will be killed if it hits a breakpoint\(emeither one
you explicitly set or one set by \f4sdb\f1 to statement step over a
function call.
.LE
.H 3 "Optimizer"
.IX optimizer
The optimizer has a problem that manifests itself when
a program does certain comparisons on \f4unsigned char\f1s.
.BL
.LI 
The problem will only occur if an \f4unsigned char\f1 is compared
to a quantity requiring more than one byte of storage.
.LI
It only appears if the compiler is run in \f4-Xt\f1 mode.
.LI
It can be fixed by explicitly casting the \f4unsigned char\f1
to the larger type.
.LI
The comparison in question will usually evoke a warning
from the compiler about changing semantics under
.SM "ANSI C" .
.LE
The following example illustrates the problem.  Correct code
should print \f4PASS\f1 twice.
.SS
main()
{
	foo(256);
	foo(255);
}

foo(i)
int i;
{
	unsigned char uc=1;
	if(uc<i) printf("PASS\en");
	else printf("FAIL\en");
	/* It is safer to cast uc to int here: (int)uc < i */
}
.SE
.H 3 "Performance Tradeoffs"
.IX \f4a.out\fP(4)
.P
The initialized arrays \f4__iob\f1 and \f4__ctype\f1 are defined
in the dynamic C library since they are referenced by many of the
the library functions.
They may also be referenced directly from the
user's code through macros such as \f4getchar\f1 and \f4isdigit\f1.
Since the user's code is not typically compiled as position 
independent, space for these symbols must be allocated in the
\f4a.out\f1's data segment.
At process startup time the dynamic
linker changes the global offset table entries in the library to
point to the \f4a.out\f1's symbols, if present, so that both
the library and the \f4a.out\f1 will be referencing the same object.
.P
\f4__iob\f1 and \f4__ctype\f1 are fairly large arrays, and the
method chosen to initialize the arrays in the \f4a.out\f1's
data segment can have an impact on overall system performance;
the method used in the porting base may not be the best choice
for other systems.
In the porting base, both \f4libc.so\f1 (the archive library)
and \f4libc.so.1\f1 (the shared object) are built with the files
(\f4data.o\f1 and \f4_ctype.o\f1) containing the initialized data.
Executable files linked with \f4libc.so\f1 will have the
initialized arrays in their \f4.data\f1 sections.
.P
The alternative is to replace the definitions in the archive \f4libc.so\f1
with uninitialized objects (\f4.bss\f1 symbols), and add code to
the run time linker to copy the initialized data from the shared library
into the \f4a.out\f1's \f4.bss\f1 section at process startup.
This alternative typically makes executable files smaller, and
trades off disk I/O for longer startup times.
.IX iend UNIX System V Release 4, C Language notes
