|
|
|
close_secdef(3) -- security defaults configuration file routines
|
|
open_secdef opens the security configuration file /etc/default/security. This function must be called prior to calling get_secdef_str or get_secdef_int. close_secdef closes the security configuration file. get_secdef_str and get_secdef_int return the value of the specified parameter defined in the security configuration file. See the security(4) manpage. Programs using these routines must be compi... |
|
Composite(3) -- The Composite widget class
|
|
Composite widgets are intended to be containers for other widgets and can have an arbitrary number of children. Their responsibilities (implemented either directly by the widget class or indirectly by Intrinsics functions) include: + Overall management of children from creation to destruction. + Destruction of descendants when the composite widget is destroyed. + Physical arrangement (geometry man... |
|
|
Constraint(3) -- The Constraint widget class
|
|
Constraint widgets maintain additional state data for each child. For example, client-defined constraints on the child's geometry may be specified. When a constrained composite widget defines constraint resources, all of that widget's children inherit all of those resources as their own. These constraint resources are set and read just the same as any other resources defined for the child. This ... |
|
copydvagent(3) -- manipulate device assignment database entry for a trusted system
|
|
getdvagent, getdvagnam, and copydvagent each return a pointer to an object with the following structure containing the broken-out fields of an entry in the Device Assignment database. Each database entry is returned as a dev_asg structure, declared in the header file: struct dev_field { char *fd_name; /* external name */ char **fd_devs; /* device list */ mask_t fd_type[1]; /* tape, printe... |
|
Core(3) -- The Core widget class
|
|
Core is the Xt Intrinsic base class for windowed widgets. The Object and RectObj classes provide support for windowless widgets. |
|
crt0(3) -- execution startup routines
|
|
The C, aC++, and FORTRAN compilers link in the object file crt0.o for statically-bound programs to provide startup capabilities and environments for program execution. It contains startup code that must be linked using ld to every statically-bound program. In a dynamically linked program (the default method), the crt0.o object file is not used, and all actions normally associated with it are inste... |
|
crt0.o(3) -- execution startup routines
|
|
The C, aC++, and FORTRAN compilers link in the object file crt0.o for statically-bound programs to provide startup capabilities and environments for program execution. It contains startup code that must be linked using ld to every statically-bound program. In a dynamically linked program (the default method), the crt0.o object file is not used, and all actions normally associated with it are inste... |
|
crt0.o_ia(3) -- execution startup routines
|
|
The C, aC++, and FORTRAN compilers link in the object file crt0.o for statically-bound programs to provide startup capabilities and environments for program execution. It contains startup code that must be linked using ld to every statically-bound program. In a dynamically linked program (the default method), the crt0.o object file is not used, and all actions normally associated with it are inste... |
|
crt0.o_pa(3) -- 64-bit ELF uses crt0.o only
|
|
PA-RISC 32-bit SOM The C, Pascal, and FORTRAN compilers link in the object files crt0.o, gcrt0.o, or mcrt0.o to provide startup capabilities and environments for program execution. All are identical except that gcrt0.o and mcrt0.o provide additional functionality for gpro profiling support respectively. The following symbols are defined in these object files: _environ An array of character pointer... |
|
crt0_ia(3) -- execution startup routines
|
|
The C, aC++, and FORTRAN compilers link in the object file crt0.o for statically-bound programs to provide startup capabilities and environments for program execution. It contains startup code that must be linked using ld to every statically-bound program. In a dynamically linked program (the default method), the crt0.o object file is not used, and all actions normally associated with it are inste... |
|
crt0_pa(3) -- execution startup routines; PARISC
|
|
PA-RISC 32-bit SOM The C, Pascal, and FORTRAN compilers link in the object files crt0.o, gcrt0.o, or mcrt0.o to provide startup capabilities and environments for program execution. All are identical except that gcrt0.o and mcrt0.o provide additional functionality for gpro profiling support respectively. The following symbols are defined in these object files: _environ An array of character pointer... |
|
cr_close(3) -- close a crash dump descriptor
|
|
The cr_close() function closes the crash dump descriptor structure pointed to by crash_cb. The crash_cb structure is a crash dump descriptor filled in by a cr_open(3) call. All associated resources (memory and files) are released. |
|
cr_info(3) -- retrieve crash dump information
|
|
The cr_info() function returns a pointer to a cr_info_t structure with information about an open crash dump. cr_info_t The cr_info_t structure contains the following fields. Note that there is no necessary correlation between the placement in this list and the order in the structure, and the structure may contain other, reserved fields. In the future, this structure may change in size and should n... |
|
cr_isaddr(3) -- validate whether physical page number was dumped
|
|
The cr_isaddr() checks to see if the specified page number, pagenum, is present in the open crash dump represented by crash_cb. It sets the Boolean to which avail points to indicate the presence (1) or absence (0) of the page. |
|
cr_open(3) -- open crash dump for reading
|
|
The cr_open() library call opens a crash dump and passes back a crash dump descriptor. The path argument points to a path name naming a crash dump directory or file, and must not exceed PATH_MAX bytes in length. The CRASH * to which crash_cb points is set to a crash dump descriptor, which can then be passed to the other cr_*() functions to access the crash dump. flags is a bitmask of zero or more ... |
