stdsyms(5)stdsyms(5)NAMEstdsyms - description of named defines and other specifications for
namespace from HP-UX header files
DESCRIPTION
is a description of "named defines" and other specifications that must
be set by the application to obtain the appropriate namespace from the
HP-UX header files.
HP-UX header files are organized in a manner that allows for only a
subset of the symbols available in that header file to be visible to an
application that conforms to a specific standard. The ANSI-C, POSIX.1,
POSIX.2, XPG4 and subsequent enhanced versions of ANSI-C/POSIX/XPG each
reserve a certain set of symbols for that standard's namespace. In
addition, the HP-UX implementation of XPG3 and the "OSF AES/OS" pro‐
vides for a clean namespace although this is not a specific requirement
of those standards.
The following rules apply in determining what symbols are reserved for
any standard. These symbols are reserved for the standard and for use
by the implementation, and must be either avoided altogether, or used
exactly as defined by the specified standard.
· All symbols defined by the desired standard are reserved. Refer to
the appropriate standards documentation for a complete list of
reserved symbols.
· All symbols beginning with an underscore followed by another under‐
score or an uppercase letter are reserved for the implementation.
· All external identifiers beginning with an underscore are reserved
for the implementation.
The following is a list of feature test macros which must be defined to
obtain the appropriate namespace from the header files.
This symbol is automatically defined by the ANSI-C preprocessor and is
automatically defined when specifying an ANSI-C compile Using the
strict ANSI option requests a pure ANSI-C namespace, which is the
smallest subset of the HP-UX namespace available. The option also
enables the inclusion of ANSI-C-style function prototypes for increased
type checking. Note that the default namespace when using the option
is the ANSI-C namespace; therefore a broader namespace must be
requested if it is desired.
This symbol is automatically defined by the
ANSI-C preprocessor on some implementations. If defined, it
indicates the version of the standard it is complying with.
As documented in the IEEE POSIX.1 standard, the programmer is required
to define the feature test macro to obtain the POSIX.1 namespace
and POSIX.1 functionality. This feature test macro can be
defined, either by using compiler options or by using directives
in the source files before any directives. Note that the
default POSIX namespace is the POSIX.1-1990 namespace. It is
necessary to define the feature test macro in addition to the
macro in order to obtain the POSIX.1-1988 namespace.
As documented in the IEEE POSIX.2
standard, the programmer is required to define the feature test
macro with a value of 2 to obtain the POSIX.1 and POSIX.2 names‐
paces and functionality. This feature test macro can be
defined, either by using compiler options or by using directives
in the source files before any directives.
As documented in the X/Open Portability Guide
the programmer is required to define the feature test macro to
obtain X/Open functionality. This feature test macro can be
defined, either by using compiler options or by using directives
in the source files before any directives. Although XPG3 does
not specify any namespace pollution rules, XPG4 and its subse‐
quent versions have instituted such rules. Therefore, the HP-UX
operating system provides clean namespaces whenever is defined.
The current default X/Open namespace is that corresponding to
XPG4. Broader namespace can be requested by setting to a value
as specified by the standard document.
As documented in the XPG, the programmer is required
to define the feature test macro to obtain namespace and func‐
tionality. This feature test macro can be defined either by
using compiler option or by using directives in the source files
before any directives.
As documented in the "OSF AES/OS"
standard, the programmer is required to define the feature test
macro to obtain OSF functionality. This feature test macro can
be defined, either by using compiler options or by using direc‐
tives in the source files before any directives. Although the
AES does not specify any namespace pollution rules, the other
standards have instituted such rules. Therefore HP-UX provides
a clean namespace whenever is defined. Use of is strongly dis‐
couraged as this functionality will be removed in a future
release of HP-UX.
The programmer can define the
feature test macro to obtain the HP-UX namespace and complete
HP-UX functionality. Note that the HP-UX namespace is currently
a superset of all of the above mentioned namespaces. When using
the compiler with default options or the compiler with compati‐
bility-mode options command without the option), the HP-UX
namespace is provided by default (see cc(1)). The programmer
must request one of the other namespaces as described above to
obtain the appropriate subset of the HP-UX namespace. When
using the strict ANSI-C-mode compiler the programmer must
specifically request a broader namespace.
The feature test macro can be defined, either by using compiler
options or by using directives in the source files before any
directives.
The following is a list of miscellaneous feature test macros that pro‐
vide various additional features.
This symbol is automatically defined by the HP C++ compiler. Defining
this macro enables the C++ function prototypes in system header files.
The default namespace for HP C++ is the ANSI-C namespace. To
obtain another namespace define the appropriate feature test
macro.
HP C++ uses the ANSI-C preprocessor by default. To get the com‐
patibility mode preprocessor, use the option of the command (see
cc(1)). The compatibility mode preprocessor uses the HP-UX
namespace
This feature test macro should be defined
when the namespace is required. It should be used in conjunc‐
tion with the macro if the default namespace is not desired.
This macro is defined automatically whenever or is requested.
The feature test macro is provided so that the programmer can obtain
the XPG3 namespace, since it differs slightly from the names‐
pace. In order to obtain the XPG3 namespace, the programmer
must define both the and feature test macros. The and feature
test macros can be defined, either by using compiler options or
by using directives in the source files before any directives.
Use of this macro is strongly discouraged as this functionality
will be removed in a future release of HP-UX.
The feature test macro is defined automatically if the programmer
has requested the XPG4 namespace (that is, defined but not some
other conflicting namespace such as
The macro can be defined when using the compatibility mode compiler
to obtain SVID2 function return types in the HP-UX namespace.
The default return types of many functions have since been
changed in the HP-UX operating system to align with the ANSI-C,
POSIX, X/Open, and OSF standards. Use of this macro is strongly
discouraged as this functionality will be removed in a future
release of HP-UX.
The SVID3 macro can be defined to obtain SVID3 function prototypes.
The compiler flag, needs to be defined to indicate that an
application is written to meet SVID3 requirements. At the time
the function prototypes were introduced in ANSI C, the functions
exposed by this flag were only defined in SVID3.
SEE ALSOcc(1), cpp(1), pathconf(2), sysconf(2), standards(5).
stdsyms(5)
