C/C++ Programmer's Guide for NonStop Systems HP Part Number: 429301-017 Published: August 2012 Edition: J06.03 and subsequent J-series RVUs, H06.08 and subsequent H-series RVUs, and G06.
© Copyright 2012 Hewlett-Packard Development Company, L.P. Legal Notice Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. The information contained herein is subject to change without notice.
Contents About This Document...................................................................................16 Supported Release Version Updates (RVUs)................................................................................17 Intended Audience..................................................................................................................17 New and Changed Information................................................................................................
Visual Inspect Symbolic Debugger........................................................................................42 TNS/E Native Object File Tool (enoft Utility)..........................................................................42 NonStop SQL/MP Compiler and NonStop SQL/MX Compiler.................................................42 TNS/E Native C and C++ Migration Tool.............................................................................43 TNS/E Code Profiling Utilities.................
Changes Required to Interoperable Compilation Modules at D44.............................................77 EDIT File Functions..................................................................................................................78 SQL Data-Type Conversion Functions.........................................................................................78 Startup Information Retrieval Functions.......................................................................................
Using a Function Prototype and a FUNCTION Pragma.........................................................123 Using an Interface Declaration...........................................................................................123 Examples........................................................................................................................124 Considerations When Interfacing to pTAL.................................................................................125 Using Identifiers.....
Feature-Test Macros...............................................................................................................162 Preprocessor Operators.........................................................................................................164 Operator #.....................................................................................................................165 Operator ##.........................................................................................................
Usage Guidelines............................................................................................................194 FORCE_STATIC_TYPEINFO....................................................................................................195 Usage Guidelines............................................................................................................195 FORCE_STATIC_VTBL............................................................................................................
MIGRATION_CHECK............................................................................................................217 Usage Guidelines............................................................................................................217 Examples........................................................................................................................218 MIGRATION_CHECK 32TO64...............................................................................................
RVU....................................................................................................................................234 Usage Guidelines............................................................................................................235 SAVEABEND........................................................................................................................235 Usage Guidelines................................................................................................
Usage Guidelines............................................................................................................259 XMEM................................................................................................................................259 Usage Guidelines............................................................................................................259 XVAR....................................................................................................................
18 Using the Native C/C++ Cross Compiler on the PC..................................312 NSDEE................................................................................................................................312 ETK.....................................................................................................................................312 Capabilities of ETK..........................................................................................................
22 Handling TNS Data Alignment...............................................................383 Misalignment Tracing Facility.................................................................................................383 Sampling........................................................................................................................384 Misalignment Handling.........................................................................................................
G.3.11 Declarators...........................................................................................................410 G.3.12 Statements............................................................................................................410 G.3.13 Preprocessing Directives.........................................................................................410 G.3.14 Library Functions ...................................................................................................410 G.
Designated Initialization for Structures.....................................................................................458 Example.........................................................................................................................458 Nonconstant Aggregate Component Initializers........................................................................459 Example.........................................................................................................................
About This Document This guide describes the implementation of the C and C++ programming languages for HP NonStop systems. This guide describes these products: • TNS C compiler in the Guardian and G-series OSS environments. • TNS C preprocessor (Cprep) and TNS C++ translator (Cfront) in the Guardian and G-series OSS environments. • TNS/R and TNS/E native C and C++ compilers in the Guardian and OSS environments. • TNS/R and TNS/E native C/C++ cross compiler on the PC in NSDEE, ETK and TDS.
The SCREEN COBOL product is also excluded from COBOL discussions in this guide unless specifically mentioned. To reduce confusion between the current product name and compiler-specific or platform-specific behaviors, this guide now uses “COBOL” to see the language when a more specific distinction is not needed or is obvious from context. “COBOL85” is used only to refer to the HP product or to the TNS compiler in the Guardian environment.
• Added a new chapter “LP64 Data Model” (page 391) that contains information on the 64-bit data model.
0x70000000 to 0x80000000. Refer to the HP NonStop S-Series Server Description Manual for a description of how this space is allocated. Changes for February 2007 (429301-012) This manual contains information about some of the following G-series development tools. These tools are supported only in H06.05 and subsequent H-series RVUs.
Documentation Set Organization The HP C and C++ D-series documentation set for NonStop servers evolved to support the Open System Services (OSS) environment and native mode C and C++, as shown in Figure 1: Organization of HP C and C++ Documentation Set. • At the D30.
Figure 1 Organization of HP C and C++ Documentation Set Document Organization Table 1 summarizes the contents of this guide. Table 1 Summary of Contents Chapter This chapter . . . Chapter 1: Introduction to HP C and C++ for NonStop Systems Provides an overview of the HP C and C++ product set. It also describes how to write portable programs and to port programs to HP C and C++. It explains Guardian and OSS environment interoperability.
Table 1 Summary of Contents (continued) Chapter This chapter . . . Chapter 6: Accessing Middleware Using HP C and C++ for NonStop Systems Describes how to use the Tools.h++ class library from HP C++ applications. Chapter 7: Mixed-Language Programming for Describes the Common Run-Time Environment (CRE) and the C interface TNS Programs declarations that are necessary to interface to other programming languages.
Table 1 Summary of Contents (continued) Chapter This chapter . . . Appendix F: MIGRATION_CHECK Messages Lists the warnings from the TNS/R native C++ compiler when run with the MIGRATION_CHECK pragma to verify whether source code contains VERSION2 functions that might need to change to migrate to VERSION3.
A group of items enclosed in brackets is a list from which you can choose one item or none. The items in the list can be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines. For example: FC [ num ] [ -num ] [ text ] K [ X | D ] address { } Braces A group of items enclosed in braces is a list from which you are required to choose one item.
$process-name.#su-name Line Spacing If the syntax of a command is too long to fit on a single line, each continuation line is indented three spaces and is separated from the preceding line by a blank line. This spacing distinguishes items in a continuation line from items in a vertical list of selections.
p-register process-name [ ] Brackets Brackets enclose items that are sometimes, but not always, displayed. For example: Event number = number [ Subject = first-subject-value ] A group of items enclosed in brackets is a list of all possible items that can be displayed, of which one or none might actually be displayed. The items in the list can be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines.
Table 2 Program Development Manuals and Online Help Manual Title Description Accelerator Manual Describes how to use the Accelerator to optimize TNS object code for the TNS/R execution environment. Binder Manual Describes the Binder program, an interactive linker that enables you to examine, modify, and combine object files and to generate load maps and cross-reference listings.
Table 2 Program Development Manuals and Online Help (continued) Manual Title Description Standard Compliant C++ Library Reference Describes the functions and elements in the VERSION3 Standard C++ Library (also see Using the Standard C++ Library). TNS/R Native Application Migration Guide Describes the TNS/R native development and execution environments and describes how to migrate existing TNS applications to TNS/R native applications. Tools/h++ Class Reference; Tools.h++ Manual; Tools.h++ 7.
HP Encourages Your Comments HP encourages your comments concerning this document. We are committed to providing documentation that meets your needs. Send any errors found, suggestions for improvement, or compliments to docsfeedback@hp.com. Include the document title, part number, and any comment, error found, or suggestion for improvement you have concerning this document.
1 Introduction to HP C and C++ for NonStop Systems TNS C Language System The HP TNS C language system for NonStop servers generates TNS C programs for the Guardian and G-series OSS environments. The C preprocessor, C compiler, C run-time library, and Binder comprises the TNS C language system. Optional components of this system include the Accelerator, the TNS Object Code Accelerator (OCA), the Inspect or Visual Inspect symbolic debuggers, and the NonStop SQL/MP compiler.
Inspect Symbolic Debugger The Inspect symbolic debugger is an interactive tool that enables you to identify and correct programming errors in programs.You can use the Inspect debugger to: • Step through code • Set breakpoints • Display source • Display variables For more details on TNS program debugging capabilities, see the Inspect Manual and the G-series Debug Manual.
In the Guardian environment, support is also provided for: • Mixed language programming using interface declarations • Completion codes for error detection Exception Handling Is Not Supported Exception handling is described in The Annotated C++ Reference Manual. However, exception handling is not implemented in either USL Cfront or HP Cfront. Compilation Steps for C++ Code To compile C++ code in the Guardian and OSS environments, use these steps: 1.
The native C compiler can be run in the Guardian and OSS environments or on a PC: • In the Guardian environment, use the NMC command to run the native compiler. The NMC command line syntax is similar to that of the C command for running the TNS C compiler. For syntax information, see Compiling a C Module (page 263). • In the OSS environment, use the native c89 utility to run the TNS/R native C compiler. The native c89 utility syntax is similar to that of the TNS c89 utility.
five steps (running Cprep, Cfront, the TNS C compiler, Binder, and the Accelerator). In comparison, to create an executable native C++ program, you run only the native C++ compiler and a TNS/R native linker. TNS/R Native C Run-Time Library The native C run-time library provides functions conforming to the ISO/ANSI C Standard. It also contains functions conforming to the X/OPEN UNIX 95 specification and HP extensions to these standards. The native C run-time library supports Guardian and OSS processes.
C++ Header Files Combined at G06.20 At the G06.20 RVU, the C++ header files for all three versions were combined into one product number, T2824. Built-in checking enforces the use of the correct header files with each version. This change did not affect how you use the header files; the change is transparent to the user. Tools.h++ version 7 headers remain in product T5894.
• Provides source-level debugging for servers executing in NonStop environment; provides additional application navigation features that allow a higher level of abstraction • Supports both TNS and native machine architectures and compilers (that is, C, C++, COBOL85, NMCOBOL, ECOBOL, EpTAL, TAL, pTAL, D-series Pascal, and FORTRAN), in the Guardian and OSS executing environments • Is available also as a stand-alone product For more details about enabling and using Visual Inspect, see the Visual Inspect
Features of TNS/R Native C and C++ Over the years, TNS/R native C and C++ have evolved as the languages themselves were changing. • At the D40 release, the TNS/R native C/C++ compiler accepted the language as defined by The Annotated C++ Reference Manual by Ellis and Stroustrup (excluding support for the exception handling). • At D45, some features were updated to match the language specification in the 1996 X3J16/WG21 Working Paper. VERSION2 of the native C++ compiler is based on the 1996 standard.
• ◦ Terminals ◦ $RECEIVE Two file-reference models There are two sets of input and output routines; each set has its own method of tracking, maintaining, and referring to a file. These methods are called file-reference models, they are: ◦ The ANSI model, which uses FILE pointers to identify the files. ◦ The alternate or UNIX-style model, which uses file descriptors to identify the files.
TNS/E Native C Compiler The TNS/E native C compiler accepts: • C language source files that comply with the ISO/ANSI C Standard (ISO/IEC 9899:1990, Programming Languages–C or ANSI C X3.159-1989, Programming Language C) or Common-Usage C (sometimes called Kernighan and Ritchie C, or K&R C). • For H06.08 and later H-series RVUs and J06.
The TNS/E native C++ compiler can be run in the Guardian and OSS environments, and on a PC using NSDEE or ETK: • In the Guardian environment, use the CPPCOMP command to run the native C++ compiler. CPPCOMP command syntax is similar to that of the NMCPLUS command for running the TNS/R C++ compiler. For syntax information, see Compiling a C Module (page 263). • In the OSS environment, use the native c89 utility or the c99 utility to run the TNS/E native C compiler.
VERSION3 Standard C++ Library ISO/IEC For C++ VERSION3 (the default version), these libraries are available: • The HP NonStop C run-time library (file ZCRTLDLL) • The VERSION3 library, which includes: ◦ The HP NonStop C++ common run-time library (product T2831, file ZCPPCDLL) ◦ The VERSION3-specific ratified Standard C++ Library ISO/IEC from Dinkumware, based on the standard document: ISO/IEC 14882:1998(E) (product T2833, file ZCPP3DLL).
Visual Inspect Symbolic Debugger Visual Inspect is an optional PC-based (GUI) symbolic debugger designed to work in complex distributed environments.
TNS/E Native C and C++ Migration Tool The native C and C++ migration tool, NMCMT, scans source files and produces a diagnostic listing. The listing identifies most C and C++ language source code changes required to migrate from TNS C (D20 or later product versions) to native C or C++. The native mode migration tool is available in both the Guardian and OSS environments, and it is integrated into ETK on the PC.
• Working Paper for Draft Proposed International Standard for Information Systems–Programming Language C++. X3, Information Processing Systems. 2 Dec 1996. X3J16/96-0225 WG21/N1043 (the standard on which the NonStop VERSION2 of the Standard C++ Library is based). • International Standard ISO/IEC 14882:1998(E) Programming Languages -- C++ (the 1998 standard on which the NonStop VERSION3 of the Standard C++ Library is based).
Writing Portable Programs A portable application is an application designed using open, industry-standard languages, application program interfaces (APIs), and middleware, such as the C language and POSIX.1 API. A portable application can be moved between hardware systems and middleware environments from different vendors. This subsection provides guidelines for writing portable C programs.
Following Good Programming Practices In general, the more you follow good programming practices, the easier it will be to port your program to other hardware and software environments. A few of the most important good programming practices are: • Use strictly conforming C language features as described in the ISO/ANSI C standard as much as possible. Isolate HP defined and extended C language features into specific modules. • Use function prototypes.
• Lapin, J. E. Portable C and UNIX System Programming. Rabbit Software, 1987. • Rabinowitz, Henry, and Chaim Schaap. Portable C. Prentice Hall, Inc., 1989. Porting Programs to HP C and C++ for NonStop Systems HP C complies with the ISO/ANSI C standard. Any C program that strictly conforms with this standard and does not use features beyond this standard can immediately be compiled in HP C.
An application program can be compiled to run in either the OSS or Guardian environment and can use services from each environment, including the API, tools, and utilities.
2 C and C++ Extensions This chapter describes the language extensions to the ISO/ANSI C standard that are supported by the HP native C and C++ compilers, the TNS C compiler, and the TNS C++ preprocessor. Keywords A keyword is a word symbol that has a special predefined syntactic or semantic meaning in a programming language. Table 5 lists the reserved keywords that HP has added as extensions to the C and C++ languages.
Storage Class Specifier The _lowmem and export-attribute storage-class specifiers are HP extensions. storage-class-specifier is one of: typedef extern static auto register export-attribute _lowmem typedef, extern, static, auto, and register are described in the ISO/ANSI C standard. _lowmem specifies that arrays and structures in the declaration are to be stored in the user data space instead of the extended segment (only for TNS C and C++).
and the structure t1 specify _lowmem, storage for them is not allocated in the extended segment. Instead, storage is allocated in the user data space. Export Attribute (Native C and C++ Only) The export$ and import$ keywords are supported only on native C/C++. These keywords export and import functions and data to and from a DLL, SRL, or PIC program. They specify whether a defined or declared class is to be exported or imported, respectively.
class-specific data (CGD). When given for specific members, only those members are exported or imported. Within a single compilation unit, a class is not allowed to both export and import members. • When you declare a class export$, all of its member functions, static data members, and any CGDs are exported. Definitions for these member functions and static data members must be provided. An error is issued for missing definitions. Exported member functions are never inlined.
int I; int foo (void) {return I;} export$ static int J; // Member function // neither exported nor imported // Exported static data member }; int C3a::J = 1; //Definition for exported static data member class C3b { public : int I; int foo (void) {return I;} import$ static int J; }; // Member function // neither exported nor imported // Imported static data member // Error to selectively export/import members of an exported/imported class class export$ C4 { public : int I; import$ int foo (void) {retur
Implementation-Defined Behavior. Note that the bool type became available at the D45 release, but it is available only with native C++ using the VERSION2 directive. _cc_status indicates that a procedure does not return a value but does set a condition code. struct-or-union-specifier, enum-specifier, and typedef-name are described in the ISO/ANSI C standard.
... } else if (cc == CCG) { ... } /* D40 method */ if (_status_lt(cc)) { ... } else if (_status_gt(cc)) { ... } Type Qualifier The _cspace type qualifier is an HP extension. The _cspace type qualifier is applicable only in the TNS Guardian environment. _cspace is unnecessary in the native environment; however the native compilers recognize the _cspace keyword to provide source-level compatibility with the TNS compiler.
language-specifier is one of: _c | _cobol | _fortran | _pascal | _tal | _unspecified attribute is one of: _alias ( "external-name " ) | _extensible [ ( param-count ) ] _resident | _variable language-specifier A language-specifier for a function prototype specifies the language of the body of the external routine being declared. Considerations for the Native Compilers Only • Native C and C++ support mixed-language programs with modules written in the C, C++, native COBOL85, and native pTAL languages.
“unioned.” Two declarations for a function are deemed to agree, with respect to the attributes, if: ◦ Either both or neither are specified to be _extensible. ◦ Either both or neither are specified to be _variable. ◦ If both have a language-specifier, they must either specify the same language or one language-specifier must be _unspecified. ◦ They do not result in any illegal combination as is discussed under the following attribute syntax descriptions.
Considerations for the native compilers only: • An _extensible function is limited to 31 parameters. If more are supplied an error message is generated. • _extensible and _variable are treated the same, _variable is a synonym for _extensible Considerations for the TNS compilers only: • A function with no prototype declaration or definition under pragma OLDCALLS cannot be _extensible.
Considerations for the native compilers only: • _extensible and _variable are treated the same; _variable is a synonym for _extensible. Considerations for the TNS compilers only: • A function with no prototype declaration or definition under pragma OLDCALLS cannot be _extensible. Considerations for both the native and TNS compilers: • _extensible and _variable attributes cannot be specified for the same function. • C-style variable argument lists (...) are not allowed.
[ modifier-list ] * [ type-qualifier-list ] pointer modifier-list: modifier [ modifier-list ] modifier: _far | _near | _baddr | _waddr | _procaddr type-qualifier-list is described in the ISO/ANSI C standard.
• If _near is used to modify a pointer and neither _waddr or _baddr is specified, the pointer can contain either a byte address or a TNS word address: If Type Pointed To Is Then Pointer Contains 8-bit scalar1 byte address 1 greater than an 8-bit scalar TNS word address void byte address struct TNS word address array Pointer is the same as a pointer to an element of the array. 1 Arithmetic types and pointer types are called scalar types.
_arg_present() The _arg_present() operator is an HP extension. _arg_present() is used to determine the presence of a parameter in an extensible or variable function. The compiler generates code to determine whether the supplied operand is present in the actual function call. If the operand is present, 1 is returned; otherwise, 0 is returned. unary-expression: _arg_present (formal-parameter-name) formal-parameter-name defines the operand on which the _arg_present() operator operates.
Usage Guidelines • The _optional() operator can be used only as an actual argument to a variable or extensible function. • The first expression must be scalar. Examples 1. This example shows a caller of an extensible function that dynamically decides to pass one of its arguments. _extensible foo (int, int, int); void bar (int i) { /* Pass a third argument of 30 to foo only if i is not zero. */ foo (10, 20, _optional (i, 30)); } 2.
Table 8 Predefined Data Types (continued) Long forms Abbreviated forms long long int long long decimal decimal float float double double long double long double 1 The bool type became available at the D45 release with native C++ using the VERSION2 directive. decimal The data type decimal is an HP extension. decimal is applicable only for the native C and TNS C languages, which use the pragma SQL. decimal specifies the predefined decimal type, which is used to access data in an SQL database.
Table 9 shows the size of the short, int, and long types when you omit or specify the WIDE pragma in TNS C. Table 9 Relationship Between WIDE Pragma and Types short, int, and long Data Type Size Without WIDE Pragma Specified Size With WIDE Pragma Specified short 16 bits 16 bits int 16 bits 32 bits long 32 bits 32 bits For TNS C and C++, relative sizes of the types short, int, and long depend on whether you compile the program under the 32-bit (wide) data model.
3 Interfacing to Guardian Procedures and OSS Functions This chapter describes how to declare and call Guardian procedures and OSS functions in C and C++ programs. Use Guardian procedures when you cannot accomplish a task with C functions. For example, to get the file code of a Guardian file, use a Guardian file-system procedure, such as FILE_GETINFO_ or FILE_GETINFOBYNAME_. (See also Procedures With 16-Bit Addressable Parameters (page 69).
The $SYSTEM.ZSYSDEFS.ZSYSC file contains a set of declarations, consisting mainly of named constants (literals) and data structure definitions, that can be used for parameters to Guardian procedures. Like the Guardian procedure header files, the ZSYSC file is divided into sections that allow you to include only those declarations that your program needs. This directive includes only the process-creation and system-message constant declarations: #include "$system.zsysdefs.
Example 1 Calling a Guardian Procedure That Returns a Return Value #include #include #include #include char *filename; short typeinfo[5]; int main(int argc, char *argv[]) { short retcode, physreclen; /* Note 1 */ /* Get Guardian filename and pass it to the Guardian procedure. */ if(argc > 1) filename = argv[1]; else filename = "$system.system.
Example 2 Calling a Guardian Procedure That Returns a Condition Code #include #include #include #include #include /* Note 1 */ _cc_status CC; /* Note 2 */ short filenum, bytesread, retcode; char *filename; char buffer[1024]; int main(int argc, char *argv[]) { int i; /* Get Guardian filename and open the file. */ if (argc > 1) filename = argv[1]; else filename = "$system.system.
parameters. Use the Guardian procedures with 32-bit addressable parameters in new code and consider converting old code as well. Parameters located in the user data segment need to be declared and passed properly. Small-memory model TNS C programs only support 16-bit addressable data so no changes are required.
4 Using the C Run-Time Library Versions of the C Run-Time Library There are four versions of the C run-time library: • Guardian TNS C run-time library • Open System Services (OSS) G-series TNS C run-time library • Guardian and OSS TNS/R native C run-time library • Guardian and OSS TNS/E native C run-time library The library version used depends on the environment (NonStop) and mode (TNS or native) of a program.
models, are the ANSI model, which uses FILE pointers to identify files, and the alternate model, which uses file descriptors for this purpose. The ANSI model is the same for the Guardian and OSS environments. For TNS C, the alternate model is different between the Guardian and OSS environments. In the Guardian TNS environment, the alternate model is an HP extension to the ISO/ANSI C standard.
Table 10 Buffer Sizes (continued) File Type Maximum Length of Buffer in Bytes C file accessed as binary-type logical file 4096 Process accessed as text-type logical file 256 Process accessed as binary-type logical file 32,767 $RECEIVE 32,767 Physical File Types As mentioned earlier, the C run-time library provides input and output access to several types of physical files, including C files, EDIT files, processes, and terminals.
$RECEIVE When you are accessing $RECEIVE, HP recommends that you use Guardian system procedures, rather than the ANSI or alternate I/O C functions, for: • Performing interprocess communication • Opening $RECEIVE and reading or replying to system messages ANSI-Model I/O As mentioned earlier, the ANSI-model I/O functions use FILE pointers to identify files.
There are conditions defined in these standards that could not occur in the HP implementation on older systems. These conditions include an argument or return value of NaN (not-a-number) and positive and negative infinity. Because these conditions could not occur, the Tandem floating-point format variants of the mathematical functions do not take actions defined in the standards. For example, the XPG4 cos() function definition requires that NaN be returned if the parameter to the function is NaN.
Table 11 Comparison of IEEE and Tandem Floating-Point Formats Characteristic IEEE float Tandem float IEEE double Tandem double Total bits in format 32 32 64 64 Bits of exponent 8 9 11 9 Bits of stored fraction 23 22 52 54 Nominal precision, including hidden bit 24 23 53 55 Active Backup Programming Functions The term “fault tolerant” means that a single failure does not cause processing to stop.
Table 12 C Functions for Active Backup Programming (continued) __ns_fget_file_open_state() Called by the primary process to obtain open state information for a file. __ns_fopen_special() Called by the primary process to open a file with a specified sync depth. These functions are described in the Guardian TNS C Library Calls Reference Manual and Guardian Native C Library Calls Reference Manual.
The TNS/R native C modules that must be recompiled and the source code changes you need to make are summarized in this table: Type of Compilation Unit Type of Executable Unit Change Required SYSTYPEGUARDIAN OSS process Use _guardian variant of the function in compilation unit. SYSTYPEOSS Guardian process Use _oss variant of the function in compilation unit.
fopen_std_file() terminate_program() For more details, see the Guardian TNS C Library Calls Reference Manual, Guardian Native C Library Calls Reference Manual, or Open System Services Library Calls Reference Manual. These functions are HP extensions that a 64-bit data model process can use to access a secondary 32-bit addressable heap space: calloc32() free32() malloc32() realloc32() heap_check32() heap_check_always32() For more details, see the Open System Services Library Calls Reference Manual.
5 Using the Standard C++ Library Three versions of the Standard C++ Library are available on NonStop systems, as listed in Table 14: Versions of the Standard C++ and C++ Run-Time Libraries . CAUTION: All modules of an application must be built using the same version of the Standard C++ Library dialect. The native linkers and the NonStop OS perform version checking. Attempting to mix versions will yield an error or a warning at link time, and a run-time error at load time. Beginning with the G06.20 and H06.
User Documentation Available in the NonStop Technical Library (NTL): • VERSION3: Standard C++ Library Reference ISO/IEC (VERSION3) CAUTION: The VERSION3 documentation contains descriptions of an underlying C library that is not the same in every case as the C library supported on HP NonStop systems. The descriptions of those C functions might not apply to the NonStop C run-time library.
Contents of the Standard C++ Library VERSION3 For VERSION3, the Standard C++ Library ANSI/ISO/IEC is a port of the Dinkumware C++ Library, a conforming implementation of the Standard C++ library by P.J. Plauger. The library enforces the ISO/IEC IS 14882:1998(E) standard for C++, plus a number of fixes ratified by the C++ Standards Committee and documented in corrigenda before the NonStop VERSION3 code was developed and finalized.
The VERSION2 C++ Library includes: • A large set of data structures and algorithms formerly known as the Standard Template Library (STL) • A locale facility • A templatized string class • A templatized complex class for representing complex numbers • A uniform framework for describing the execution environment through the use of a template class named numeric_limits and specializations for each fundamental data type • Memory management features • Language support features • Exception handling
Table 15 Installation Details for Standard C++ Library ISO/IEC (VERSION3) (continued) Environment PC running Windows and ETK release 3.0 or later Location of Headers Location of Libraries release 1.1 are required.To use TNS/E compilers or linkers, ETK release 3 is required. To use TNS/E compilers or linkers, ETK release 3 is required. C:\Program Files\Compaq C:\Program Files\Compaq ETK-NSE\rel\usr\includewhere rel ETK-NSE\rel\usr\libwhere rel is the is the release identifier, such as H06.
Several Standard C++ Library header files have been renamed in the VERSION2 implementation for TNS/R-targeted compilations (the Guardian names, inside parentheses, are derived from the first seven letters plus the last letter of the header file name): Documented Name Name in VERSION2 Standard C++ Library (TNS/R-targeted Compilations only) exception (EXCEPTIN) rwexcept (RWEXCEPT) new (NEW) rwnew (RWNEW) stdexcept (STDEXCET) rwstdex (RWSTDEX) This renaming avoids conflicts between the C++ run-time he
Table 17 VERSION2 Standard C++ Library Example Files (continued) 86 Example File Description of Contents LINKIT Contains instructions to nld for linking each test. This file is used by CPLUS. You need to modify this file to reflect your own environment.
Table 17 VERSION2 Standard C++ Library Example Files (continued) Example File Description of Contents MULTIMAC Manual Example Source File MULTISEC Manual Example Source File NEGATORC Manual Example Source File NTHELEMC Manual Example Source File PQUEUEC Manual Example Source File PARTSORC Manual Example Source File PARTSUMC Manual Example Source File PERMUTEC Manual Example Source File PNT2FNCC Manual Example Source File PRTITIOC Manual Example Source File QUEUEC Manual Example Source
Table 17 VERSION2 Standard C++ Library Example Files (continued) Example File Description of Contents ALG6C Tutorial Example Source File ALG7C Tutorial Example Source File AUTTESTC Tutorial Example Source File CALCC Tutorial Example Source File COMPLXC Tutorial Example Source File CONCORDC Tutorial Example Source File EXCEPTNC Tutorial Example Source File ICECREAC Tutorial Example Source File RADIXC Tutorial Example Source File SIEVEC Tutorial Example Source File SPELLC Tutorial Examp
#pragma mapinclude file #pragma mapinclude file #pragma mapinclude file #pragma mapinclude file #pragma mapinclude file #pragma mapinclude file #pragma mapinclude file #pragma mapinclude file #endif /* __SLMAP */ "list.cc" "string.cc" "tree.cc" "vector.cc" "sys/types.h" "sys/stat.h" "hash_map" "hash_set" = = = = = = = = "listcc" "stringcc" "treecc" "vectorcc" "systypeh" "sysstath" "hashmap" "hashset" Note that this SLMAP file can be used with both VERSION2 and VERSION3.
◦ stdin, stdout, and stderr ◦ errno ◦ class std::exception ◦ class std::bad_alloc For example: To create and link a library that uses the neutral C++ dialect and can be used by either a VERSION2 or VERSION3 program, enter: CPPCOMP / IN ZCPPCDLL, OUT $S.#LIST / mydll; SHARED, & VERSION3, BUILD_NEUTRAL_LIBRARY where ZCPPCDLL contains only interfaces common to both a VERSION2 and VERSION3 program; this is the low-level Standard C++ Library.
6 Accessing Middleware Using HP C and C++ for NonStop Systems • Information about using NonStop SQL/MP and NonStop SQL/MX, which previously appeared in this section, is now contained only in these manuals: ◦ SQL/MP Programming Manual for C ◦ SQL/MX Programming Manual for C and COBOL Using Tools.h++ The Tools.h++ class library is a C++ foundation class library, an industry standard available in the Guardian environment, in the OSS environment, and on the PC (Windows environment). Two versions of Tools.
• Generic collection classes • Smalltalk-like collection classes • XDR streams for the OSS environment • Other features of interest include: ◦ RWFile class encapsulates standard file operations. ◦ B-tree disk retrieval uses B-trees for efficient keyed access to disk records. ◦ File Space Manager allocates, deallocates, and coalesces free space within a file. ◦ A complete error handling facility takes advantage of C++ exceptions.
Table 18 Installation Details for G06.20 Tools.h++ Environment Location of Header Files Location of SRLs or DLLS Guardian Version 6.1: $SYSTEM.ZRW Version 6.1: $SYSTEM.SYSnn.ZTLHGSRL, $SYSTEM.SYSnn.ZTLHOSRL Version 7: $SYSTEM.ZINCRW70 G-series Version 7: $SYSTEM.SYSnn.ZTLHSRL H-series Version 7: $SYSTEM.ZDLLnnn.ZTLH7DLL OSS Version 6.1: /usr/rogue6.1/rw In the Guardian namespace: Version 6.1: $SYSTEM. SYSnn.ZTLHGSRL, $SYSTEM.SYSnn.ZTLHOSRL Version 7: /usr/rogue/rw G-series Version 7: $SYSTEM.
Table 19 Tools.h++ Example Files for Version 6.1 Example File Description of Contents BUSC BUS example source file BUSH BUS example header file TEXTFILE Example data file For Version 7 of Tools.h++, the example files are located in the subphylum $system.zrw70 on the NonStop system. Table 20 lists the example files that are provided with Version 7. Table 20 Tools.h++ Example Files for Version 7 Example File Description of Contents MAKEEXAM MAKE file for the examples. It is an OBEY command file.
tells C or C++ to modify any #include name fully matching the "from" string. The effect is to replace the "from" string with the "to" string. • This example treats #include "sys/types.h" as #include "$system.system.systypeh": PRAGMA MAPINCLUDE "sys/types.h"="$system.system.systypeh" • This example treats #include as #include : PRAGMA MAPINCLUDE "sys/types.h"="systypeh" This version of the pragma covers all cases where an exact match is required. 2.
The contents of a CPATHEQ file should be in this suggested format: #PRAGMA MAPINCLUDE "sys/type.h" #PRAGMA MAPINCLUDE PATH "rw/" = "systypeh" = "$system.zincrw70." #PRAGMA MAPINCLUDE FILE "strstream.h" = "strstreh" /*Standard C++ iostream header*/ #PRAGMA MAPINCLUDE FILE "iostream.h" /*Standard C++ iostream header*/ = "iostreah" #PRAGMA MAPINCLUDE FILE "rw/cacheman.h" /*Rogue Wave Tools.
7 Mixed-Language Programming for TNS Programs This chapter describes the Common Run-Time Environment (CRE) and the C interface declarations that are necessary to interface to other programming languages. The CRE and C interface declarations are HP features for NonStop systems that are not available in standard ISO/ANSI C. TNS programs in the Guardian environment can contain routines written in TNS COBOL, FORTRAN, TAL, TNS C, and D-series Pascal.
then a C routine has limited access to the TNS C run-time library. • If a program uses the CRE, each routine in the program appears to be running in its own language-specific run-time environment, regardless of the language of the main routine. For example, if: ◦ The main routine of a mixed-language program is written in COBOL ◦ The program runs in the CRE then a C routine has complete access to the TNS C run-time library.
The older method for declaring procedures is to declare the procedure just as you would a C function, except that you include: • A language attribute specifier (_c, _cobol, _fortran, _pascal, _tal, or _unspecified) to identify the language of the external procedure. • An _alias attribute specifier to assign the external name, or rather the name as known to other language. The syntax for these older-style interface declarations is described under Attribute Specifier (page 55).
• Parameter types When creating an interface declaration for a non-C procedure, you must ensure that the declared C type of a parameter matches the defined type of that parameter. The TNS C compiler cannot perform this task automatically, because it does not have direct access to each language’s definition. The TNS C compiler does, however, check that the type of an argument in a call to a non-C procedure matches its corresponding parameter’s type.
if (__status_eq(c_code)) return( (short *)blk_addr ); else return( NULL ); } 5. This function prototype and FUNCTION pragma: void segment_allocate (short, long, short *, short); ... #pragma function segment_allocate (tal, alias (“SEGMENT_ALLOCATE_”), variable) is equivalent to this interface declaration: _tal _variable short SEGMENT_ALLOCATE_ (short, long, short *, short); 6.
In Inspect sessions: • Use uppercase for TAL identifiers • Use the given case for C identifiers In Binder sessions, use mode noupshift for lowercase C identifiers. Matching Data Types Use data types that are compatible between languages for: • Shared global variables • Formal or actual parameters • Function return values Table 22 lists compatible TAL and C data types for each TAL addressing mode.
Memory Models A TNS C program can use the small-memory model or the large-memory model, depending on the amount of data storage required. The large-memory model is recommended and is the default setting. All examples in this subsection illustrate the large-memory model unless otherwise noted.
array[2] := "B"; status := c_func (array); array[1] := "B"; END; A C-series TNS C module called by a TAL module has limited access to the C run-time library. If the TNS C module needs full access to the C run-time library, you can either: • Modify the program to run in the CRE as described in this section. • Specify a C MAIN routine that calls the original TAL main routine.
The return type value can be any of these: Return Type Value Meaning void The TAL routine does not return a value. fundamental-type The TAL routine returns a value. Specify one of, or a pointer to one of, the character, integer, or floating-point types. _cc_status The TAL routine does not return a value but does set a condition code. The tal.
To access a TAL procedure that both returns a value and sets a condition code, you must write a “jacket” procedure in TAL that is directly callable by your TNS C program.
In a large-memory-model TNS C module, you can use the _lowmem storage class specifier to allocate a C array or structure that can be represented by a 16-bit address if needed in a call to a TAL routine or a system procedure. Using pointers to share data is easier and safer than trying to match declarations in both languages. Using pointers also eliminates problems associated with where the data is placed.
!Do lots of work END; Sharing TNS C Data With TAL Using Pointers To share TNS C global data with TAL modules, follow these steps: 1. In the TNS C module, declare the data using TAL-compatible identifiers, data types, and alignments. (Alignments depend on byte or word addressing and variable layouts as described in Variables and Parameters (page 109).) C arrays and structures are automatically indirect. 2. 3. 4. 5. In the TAL module, declare pointers to the data, using C-compatible data types.
Sharing TAL Data With TNS C Using BLOCK Declarations As of the D20 release, TAL modules can share global data with TNS C modules by declaring each shared variable in its own BLOCK declaration and giving both the variable and the BLOCK the same name. The TNS C modules must also declare each shared variable; the layout of the variable must match in both the TAL and C modules.
STRING and char Variables TAL STRING and C char simple variables each occupy one byte of a word. These are STRING and char compatibility guidelines: • Share variables of type TAL STRING and C char by using pointers. • Declare TAL STRING and C char formal parameters as reference parameters to avoid these value-parameter incompatibility: ◦ When you pass a STRING parameter to a C routine, the actual byte value occupies the left byte of the word allocated for the C char formal parameter.
Structures All TAL and C structures begin on a word boundary. These are guidelines for sharing TAL and C structures and passing them as parameters: • Specify the same layout for corresponding TAL and C structures. • Specify compatible data types for each item of both structures. • In TAL, pass structures by reference. • In C, use the & (ampersand) operator. • In TAL, a routine cannot return a structure as a return value.
END; }; STRUCT .EXT tcell(cell)[0:9]; struct cell ccell [10]; PROC honey (c); void JOANIE INT .EXT c (cell); (struct cell *); EXTERNAL; Redefinitions and Unions Variant records are approximated by TAL structure redefinitions and C unions. A TAL redefinition declares a structure item that uses the same memory location as an existing structure item.
Each language can call the other, passing the address in the pointer by value: TAL Code CALL caledonia (joes); C Code TONGA (joe); Here are examples of TAL and TNS C structure pointers (large-memory model) that implement a linked list: TAL Code C Code STRUCT rec (*); BEGIN INT x; INT .EXT strptr (rec); END; STRUCT .EXT joe (rec); PROC callme (param1); INT .
In C, you can use either: • Bit-wise operators & (and) and | (or) • Defines This TAL bit-deposit operation and C bit-wise operation are equivalent: TAL Code C Code INT x := -1; INT y := 0; short a = -1; short b = 0; short temp = 0; PROC example; BEGIN y.<0:2> := x.<10:12>; END; void example () { /* you can combine these */ /* with wider margins */ temp = a & 070; temp = temp << 10; b = (b & 017777)|temp; } Bit extractions and bit deposits are not portable to future software platforms.
UNSIGNED(3) x; UNSIGNED(3) y; IF x + y ... ; IF x '+' y ... ; !TAL code !Signed operation !Unsigned operation UNSIGNED arrays that contain 8-bit or 16-bit elements are compatible with C arrays that contain elements of like size. UNSIGNED arrays that contain 1-bit, 2-bit, or 4-bit elements are incompatible with C arrays. TAL Routines as Parameters to TNS C You can call TNS C routines and pass TAL routines as parameters. You can pass any TAL routine except EXTENSIBLE or VARIABLE routines as parameters.
TNS C Routines as Parameters to TAL You can call TAL routines and pass TNS C routines as parameters. You can call a TAL entry-point identifier as if it were the routine identifier. TNS C routines cannot be nested. When a called TAL routine in turn calls a TNS C routine received as a parameter, the TAL routine assumes that all required parameters of the TNS C routine are value parameters. The TAL compiler has no way of checking the number, type, or passing method expected by the TNS C routine.
NOTE: There are two types of extended data segments: flat segments and selectable segments. This section uses the term “extended data segment” to refer to a selectable segment. It does not describe flat segments, although much of the information is the same for flat segments. Flat segments provide many benefits over selectable segments. Flat segments are easier to program, provide better performance, and allow access to more virtual memory than selectable segments.
If you do not restore the automatic extended data segment before you manipulate data in it, any of these actions can result: • An assignment statement is beyond the segment’s memory limit and causes a trap. • All assignments within range occur in the hardware base and limit registers of the automatic extended segment. Data in the currently active extended data segment is overwritten. The error is undetected until you discover the discrepancy at a later time.
/* next two statements depend on the automatic extended */ /* data segment being restored after the call to TAL */ sarr[1] = *s; arr[1] = arr[0] + 5; } Interfacing to TNS COBOL Your TNS C/C++ programs can call functions written in TNS COBOL. The general procedure consists of these steps: • Use the TNS COBOL compiler (COBOL85 in the Guardian environment or cobol in the OSS environment) to compile the COBOL function. • Use the TNS C/C++ compiler (named c) to compile the C/C++ program.
Example 4 COBOL Function Called by a C Program ?env common ?SYMBOLS IDENTIFICATION DIVISION. PROGRAM-ID. XCOBFUNC. AUTHOR. ETREJO. DATE-WRITTEN. 7/25/00. ENVIRONMENT DIVISION. CONFIGURATION SECTION. SOURCE-COMPUTER. TANDEM-K2006. OBJECT-COMPUTER. TANDEM-K2006. DATA DIVISION. WORKING-STORAGE SECTION. 01 D-RESULT PIC S9(09) COMP. LINKAGE SECTION. 77 D-STRING PIC X(20). 77 D-SHORT NATIVE-2. 77 D-LARGE NATIVE-4. PROCEDURE DIVISION USING D-STRING, D-SHORT, D-LARGE. 000-INIT. CONFIGURATION SECTION.
cobol85 /in testcob / testcobo 2. Compile the C program named testc using the TNS C compiler: c / in testc/ testco 3. Link the object files using Binder and the file BINDIN: bind / in bindin, out listfile / 4. To run the executable named testexe: run testexe I AM DOING COBOL NOW D-STRING = Displayed in COBOL.
8 Mixed-Language Programming for TNS/R and TNS/E Native Programs This chapter describes the Common Run-Time Environment (CRE) and the interface declarations that are necessary to interface from native C or C++ to other programming languages. The CRE and the interface declarations are HP features for NonStop systems that are not available in standard ISO/ANSI C. You can write native mixed-language programs targeted for the NonStop environment.
is unknown. If no language attribute specifier is provided, the external procedure is assumed to be written in the same language as the compilation. After providing an interface declaration, your C or C++ program uses normal function calls to access the procedure written in the other language. However, remember that these calls cross language boundaries; therefore, there are restrictions beyond those of normal C function calls.
#define #define #define #define _status_eq(x) _status_ge(x) _status_gt(x) _status_ne(x) ((x) ((x) ((x) ((x) == >= > != 0) 0) 0) 0) Before you can use these macros, you must include the tal.h header. Note that you should avoid designing pTAL procedures that return a condition code because that is an outdated programming practice. Guardian system procedures must retain this interface for reasons of compatibility.
#pragma function C_GETPOOL (tal, alias("C^GETPOOL")) short *pool_alloc ( short *my_pool, long size ) { _cc_status c_code; long blk_addr; c_code = C_GETPOOL(my_pool, size, &blk_addr); if (_status_eq(c_code)) return( (short *)blk_addr ); else return( NULL ); } 4. This function prototype and FUNCTION pragma: void segment_allocate (short, long, short *, short); ...
You can declare pTAL-only, or C-only routine identifiers and satisfy both compilers by using the public name option in: • Interface declarations in C • EXTERNAL procedure declarations in pTAL In G-series Inspect or H-series Native Inspect sessions: • Use uppercase for pTAL identifiers • Use the given case for C identifiers Matching Data Types Use data types that are compatible between languages for: • Shared global variables • Formal or actual parameters • Function return values Table 23 Compat
Incompatibilities between pTAL and C data types include: • pTAL has no numeric data type that is compatible with C unsigned long type. • pTAL UNSIGNED is not compatible with the C unsigned short type. pTAL UNSIGNED(16), INT, or INT(16) can represent signed or unsigned values. For more details on C and pTAL data types, see Parameters and Variables (page 134). Calling C Routines From pTAL Modules A pTAL module must include an EXTERNAL procedure declaration for each C routine to be called.
Specifying a FUNCTION Pragma To declare an external routine by using a function prototype and a FUNCTION pragma, include: • The keyword _tal • The variable or extensible attribute, if any, of the pTAL routine • A public name if the pTAL identifier is not a valid C identifier Specifying an Interface Declaration To declare an external routine by using an interface declaration, include: • The keyword _tal • The variable or extensible attribute, if any, of the pTAL routine • The data type of the retu
PROC TAL^NAME (a); INT .EXT a; BEGIN a[2] := 10; END; !32-bit pointer pTAL Procedures That You Cannot Call Directly Your C program cannot directly call a pTAL procedure that returns both a value and a condition code. To access a pTAL procedure that returns both a value and a condition code, you must write a “jacket” procedure in pTAL that is directly callable by your C program.
Sharing Data Using pointers to share data is easier and safer than trying to match declarations in both languages. Using pointers also eliminates problems associated with where the data is placed. The default code generation for pointer dereferencing operations (REFALIGNED 8) expects the pointer to contain an address that satisfies the alignment requirements of the object being pointed to. For example, a 4-byte object should have an address that is a multiple of 4.
return 1; } /* Access the pTAL arrays by using the pointers */ pTAL Code STRUCT rec (*); BEGIN INT x; STRING tal_str_array[0:9]; END; INT tal_int_array[0:4]; !pTAL data to share with C STRUCT tal_struct (rec); !pTAL data to share with C INT status := -1; INT PROC init_c_ptrs (tal_intptr, tal_strptr) LANGUAGE C; INT .EXT tal_intptr; STRING .EXT tal_strptr; EXTERNAL; PROC tal_main MAIN; BEGIN status := init_c_ptrs (tal_int_array, tal_struct.
pTAL Code INT .EXT tal_int_ptr; !Pointer to C data STRING .EXT tal_char_ptr; !Pointer to C data PROC init_tal_ptrs (c_addr1, c_addr2); !Called from C INT .EXT c_addr1; STRING .
In addition, if ?BLOCKGLOBALS is in effect and a data block contains one data declaring item, the name exported to C/C++ is the name of the block. This method makes it easy to change the name of a global declaration which cannot be described in C/C++ to a legal C/C++ name. With this method, you do not need to change all uses of the global declaration in the pTAL source. For pTAL programs, P-relative arrays allocate space in the read-only data area of process memory space.
If variable definitions are desired to be in the C++ source, remove the extern specifier and change the pTAL source to ?NOEXPORTGLOBALS. Parameters and Variables This subsection provides guidelines for declaring compatible pTAL and C variables and parameters. These guidelines supplement those given in Sharing Data (page 130).
Structures The FIELDALIGN C pragma controls the component layout of structures for compatibility between TNS and native structure layout and for compatibility with native mixed-language structure layout. Therefore, you need to: • Use the FIELDALIGN SHARED2 pragma to share data between TNS programs and native programs. • Use the FIELDALIGN SHARED8 pragma to share data between native C/C++ programs and pTAL programs that run on different platforms.
END; STRUCT .EXT tma(rec1)[0:9]; !Sample access! tma[8].y[3] := 100; /* sample access */ cma[8][3] = 100; Arrays of Structures If you specify bounds when you declare a pTAL structure, you create an array of structures. This pTAL and C arrays of structures are equivalent. Each declaration contains an array of ten structure occurrences: pTAL Code STRUCT cell (*); BEGIN INT x; STRING y; END; STRUCT .EXT tcell(cell)[0:9]; PROC honey (c); INT .
pTAL Code STRUCT rec (*); BEGIN INT d; INT .p (rec); END; BLOCK joe; INT .EXT joes (rec); END BLOCK; PROC tonga (p); INT .
BEGIN !Lots of code IF n = yes THEN ... ; !Lots of code END; main () { answer = yes; TAL_PROC (answer); /* lots of code */ } pTAL Routines as Parameters to C You can call C routines and pass pTAL routines as parameters. You can pass any pTAL routine except EXTENSIBLE or VARIABLE routines as parameters. A passed pTAL routine can access the routine’s local variables and global pTAL variables. The passed routine can contain subprocedures, but they cannot be passed as parameters.
routine requires a reference parameter, the pTAL routine must explicitly pass the address by using the $XADR standard function for a parameter. In this example, a C module contains C routine C_PARAM_FUNC, which is to be passed as a parameter. The pTAL module contains: • An EXTERNAL procedure declaration for C_PARAM_FUNC • TAL_PROC, which expects C_PARAM_FUNC as a parameter • TAL_CALLER, which calls TAL_PROC and passes C_PARAM_FUNC as a parameter pTAL Module INT i; STRING .
Memory Models The native C and C++ compilers support the large-memory model. The TNS C compiler supports the small-memory model or the large-memory model, depending on the amount of data storage required. However, the large-memory model is recommended and is the default setting. The size of a pointer in the large-memory model is 32 bits. The size of a pointer in the small-memory model is 16 bits.
Example 7: C Program That Calls a COBOL Function , Example 8: COBOL Function Called by a C Program , and Example 9: Include File (Prototype Function) shows the contents of three files: a C program, a COBOL program, and a header file: File Type OSS Name Guardian Name C program testc.c testc COBOL program testcob.cob testcob Header or include file containing prototype function cobincl.h cobincl In the example files shown on the following pages, file names appear as the OSS versions.
77 D-LARGE NATIVE-4. PROCEDURE DIVISION USING D-STRING, D-SHORT, D-LARGE. 000-INIT. DISPLAY "I AM DOING COBOL NOW". COMPUTE D-RESULT = D-LARGE / D-SHORT. DISPLAY "D-STRING = " D-STRING. DISPLAY "D-LARGE = " D-LARGE. DISPLAY "D-SHORT = " D-SHORT. DISPLAY "D-RESULT = " D-RESULT. DISPLAY "LEAVING COBOL PROGRAM NOW". EXIT-PROGRAM. Example 9 Include File (Prototype Function) ================================================================ The include file for OSS (cobincl.
nld $system.system.crtlmain testco testcobo -o testexe -obey $system.system.libcobey -l zcobsrl or eld $system.system.ccplmain testco testcobo -o testexe -l zcobdll 4.
9 System-Level Programming System-level programming refers to the ability to write TNS C and C++ functions that reside in system code, system library, or user library. It also refers to native C and C++ functions that reside in user library. Customer-written native C and C++ functions cannot reside in system code or system library. System-level programming is available only in the Guardian environment.
blocks. Without relocatable data blocks, static data is not allowed. Therefore, the compiler allocates static data items such as constants in the user code space instead of the user or system data spaces.) To pass pointers to such constants in TNS C and C++ programs, you must use the CSADDR pragma. (Native C programs do not require the CSADDR pragma.) The CSADDR pragma directs the compiler to allocate sufficient space on the stack for each code space data object pointed to by a function argument.
for (p = name; i <= LAST_NAME ; i++, p = &name[i]) if (!strcmp(p, "kevin")) return TRUE; return FALSE; } Note the inclusion of pragma inline in the preceding compilation unit. Because the passing of pointers to code space is hazardous for the run-time function call of strcmp, generation of inline code is safer. You can also place constants in the code space with the _cspace type qualifier. However, the _cspace type qualifier is effective only on the specified data constant.
Specify the FUNCTION pragma at function declaration, not at function definition. When you call a variable function, the compiler allocates space in the parameter area for all the parameters. The compiler also generates a parameter mask, which indicates which parameters are actually passed. You use the _arg_present() built-in operator to test for the presence of actual parameters.
{ /* Lots of code */ } void anotherproc (int i); { int total; total = 259; /* Some code */ someproc (23,,,total); /* Omit length and limit parameters } */ Converting Variable Functions to Extensible Functions You can convert a TNS C or C++ variable function into an extensible function. When you do so, the compiler converts the _variable parameter mask into an _extensible parameter mask.
10 Converting C-Series TNS Programs to Use the Current TNS Compiler This chapter lists the C language-specific changes that you must make to C-series TNS programs to compile and run them as TNS programs on current systems. Most of these changes were made to TNS C to make it compliant with the ISO/ANSI C standard. For a description of Guardian-specific changes, see the Guardian Application Conversion Guide. NOTE: Do not convert a C-series TNS C program to a current native C program directly.
the ISO/ANSI C standard and results in code that is not portable. The current TNS compiler does not generate these function prototypes for you. • Change code that is affected by the behavioral changes of the sscanf(), fflush(), or fcntl() functions: ◦ For C-series compilers, sscanf() returns a -1 if no conversion takes place. For the current compilers, sscanf() returns a 0 if no conversion takes place.
SELECT SEARCH clib ADD * FROM clib These additional changes were made to HP C for the D-series releases. It is highly unlikely that you must change your programs because of these changes: • The definition of the object-like macro NULL was removed from the C header files asserth, ctypeh, errnoh, floath, limitsh, mathh, and setjmph. These header files now conform to the ISO/ANSI C standard. • The number of parameters allowed for a nonextensible and nonvariable functions increased from 200 to 252.
11 Migrating Programs to TNS/R or TNS/E Native Mode HP NonStop native mode enables you to write programs that are fully optimized for TNS/R or TNS/E systems such as NonStop servers. The term TNS/R native means the program uses the process, memory, and instruction set architectures that are native to RISC processors. The term TNS/E native means the program uses the process, memory, and instruction set architectures that are native to Intel Itanium processors.
12 Preprocessor Directives and Macros The preprocessor is a macro processor that processes the source text of a program before the compiler parses the program. The preprocessor is controlled by preprocessor directive lines that appear in your source text. Preprocessor directive lines always begin with a number sign (#) in column one. The name of the directive follows the number sign. The remainder of the line can contain arguments for the directive. Table 25 summarizes the preprocessor directives.
replacement-list is the text that the preprocessor substitutes for the macro name when you invoke the macro later in the translation unit. The replacement-list must be valid in the context where you invoke it, not where you define it. If the macro is function-like and has defined parameters, the preprocessor substitutes each instance of a parameter identifier in the replacement-list with its corresponding argument specified in the macro invocation. The second example illustrates parameter substitution.
#error preprocessor-tokens preprocessor-tokens specifies the tokens to be included in the message text. Example This example causes the string following #error to be printed as the error message: #error This message will be issued by the compiler #if, #elif, #ifdef, #ifndef, #else, and #endif The four if directives, together with the #else and #endif directives, define the bounds of an if section, which conditionally includes or excludes source text.
The constant expression must evaluate to an integral value; also, it cannot include sizeof or cast operators or an enumeration constant. #elif int-constant-expression newline [ source-text ] introduces an if section that conditionally includes source text based on the value of a constant expression. The new line following the constant expression terminates the #elif directive line, and source-text is the text included if int-constant-expression has a nonzero value.
printf("Function prototypes not supported.\n"); #endif 2. This example shows how the #elif directive works. The #if, #elif, and #else directives are used to make one of three choices, based on the value of XCOORD and YCOORD. Note that XCOORD and YCOORD must be defined constants. #define XCOORD 5 #define YCOORD 5 #if XCOORD == 10 printf("Intersection at (10,5).\n"); #elif YCOORD == 10 printf("Intersection at (5,10).\n"); #else printf("Intersection at (5,5) \n"); #endif 3.
source_file is the file name of the source file you want to include. In the Guardian environment, the compiler searches for source_file using the SSV search list. In the OSS environment, the compiler searches for source_file using operands specified in the c89 or c99 utility -I flag. library_header_file is the name of the library header file you want to include.
If pragma SSV< n> (for Guardian) or the c89 or c99 -I flag (for OSS or Windows) is used, the Guardian subvolumes or the OSS or Windows directories are then searched. • The compiler searches for files: File File Search #include The specified standard header file is searched for in the location of the compiler (see details in following bullets).
#line The #line directive causes the compiler to renumber the lines of the source text so that the next line has the specified number and causes the compiler to believe that the current source file name is file-name. If file-name is not specified, only the renumbering of lines takes place. #line number [file-name] #pragma The #pragma directive instructs the preprocessor to pass a compiler pragma on to the compiler. #pragma compiler-pragma [ , compiler-pragma ]...
Table 26 Predefined Macros Macro What It Expands To __DATE__ A string literal representing the date of compilation. This string has the form Mmm dd yyyy, where the first character of the day (dd) is a blank if the day is less than 10. __FILE__ A string literal representing the name of the current source file. The file name is qualified up to the volume (or device) name if the file is on the same system as the compiler; otherwise, the file name is qualified up to the system name.
Variadic Macros Two variants of variadic macro definitions can be invoked in native C with a variable number of arguments. To use these extensions, you must compile with extensions enabled. • One variant of variadic macro is the C9X form, described in section 6.8.3 of the Working Draft, 1997-11-21, WG14/N794 J11/97-158 of the Proposed ISO C Standard. For example: #define D(fmt, ...) printf(fmt, __VA_ARGS__) /* The "...
Table 27 Predefined Feature-Test Macros (continued) Macro What It Defines __G_SERIES_RVU Declarations that depend on a specific G-series RVU and have the value G06.nn. Defined only for the TNS/R native C/C++ compilers. __H_SERIES_RVU Declarations that depend on a specific H-series RVU and have the value H06.nn. Defined only for the TNS/E native compilers. For J-series RVUs, use the equivalent H-series RVU.
The _GUARDIAN_TARGET and _OSS_TARGET macros identify a module’s execution environment. The compiler uses this information to resolve references to external functions in the C run-time library. For the TNS compilers, the pragma SYSTYPE GUARDIAN defines the _GUARDIAN_TARGET and _TANDEM_SOURCE macros. For the native compilers, the pragma SYSTYPE GUARDIAN defines only the _GUARDIAN_TARGET macro, while the EXTENSIONS pragma defines the _TANDEM_SOURCE macro.
allows you to concatenate two tokens in a macro definition. Both of these operators are used in the context of the #define directive. Operator # The unary operator # is used only with function-like macros, which take arguments. If the # operator precedes a formal parameter in the macro definition, the actual argument passed by the macro invocation is enclosed in quotation marks and treated as a string literal.
13 Compiler Pragmas Compiler pragmas enable you to control various elements of compiler listings, code generation, and building of the object file.
Table 28 Compiler Pragma Descriptions (continued) Pragma Purpose C99LITE Enables the ISO/IEC 9899:1999 features listed in Appendix G: c99 Selected Features (C99LITE). CALL_SHARED Directs the native compilers to generate PIC (Position-Independent Code) (shared code). This is the default for the TNS/E native compilers. CHECK Controls the inclusion of run-time error-checking code in the object file.
Table 28 Compiler Pragma Descriptions (continued) Pragma Purpose HIGHREQUESTERS Specifies that the object file supports high PIN requesters if the object file includes the main function. ICODE Controls whether the compiler listing includes the instruction-code mnemonics generated for each function immediately following the source text of the function. IEEE_FLOAT New at the G06.06 RVU.
Table 28 Compiler Pragma Descriptions (continued) Pragma Purpose NEUTRAL Specifies a struct, class, or union definition and marks it as being available in the neutral C++ standard library on TNS/E systems. NLD(arg) Specifies arguments to be passed to the nld utility. NOEXCEPTIONS Disables support for exception handling by the native C++ compiler when you are also using the VERSION2 or VERSION3 directive.
Table 28 Compiler Pragma Descriptions (continued) 170 Pragma Purpose RUNNAMED Specifies that the object file runs as a named process. RVU Sets the value of the _H_SERIES_RVU or _G_SERIES_RVU feature-test macro. SAVEABEND Controls whether the system creates a save file if the program terminates abnormally during execution. SEARCH Directs the Binder or linker to search a given object file when attempting to resolve external references in a program compiled with the RUNNABLE pragma.
Table 28 Compiler Pragma Descriptions (continued) Pragma Purpose TRIGRAPH Controls whether the TNS C compiler or Cfront translate trigraphs for the current compilation. VERSION1 Directs the TNS/R native C++ compiler to compile according to the D40 version or dialect of C++. Disables all new features added from the D45 RVU onward. VERSION1 is the default compilation mode for D45 and all RVUs until the G06.20 RVU.
Examples // /* C++ comment (to end of line) C comment (between delimiters; can span several lines) */ ALLOW_EXTERN_EXPLICIT_INSTANTIATION The ALLOW_EXTERN_EXPLICIT_INSTANTIATION command-line option specifies an extern to be applied to an explicit template instantiation. This option will suppress the instantiation of the template. The default behavior is to instantiate the template. ALLOW_EXTERN_EXPLICIT_INSTANTIATION The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.
• • For ISO/ANSI C standard compliance checking, the compiler: ◦ Disables arithmetic overflow traps. ◦ Flags HP C language extensions for NonStop systems. ◦ Checks for conformance to the #define preprocessor directive. For a description of the difference between HP C and the ISO/ANSI C standard, see Chapter 10: Converting C-Series TNS Programs to Use the Current TNS Compiler. The native C and C++ compilers do not support this pragma; use the NOEXTENSIONS pragma instead.
The BASENAME option is intended for use only with the PROFGEN option and is supported only by the TNS/E native compilers. BASENAME For more information about the code profiling and the use of the BASENAME and PROFUSE options, see the Code Profiling Utilities Manual. The BASENAME default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A. G-series TNS c89 utility N.A. N.A. TNS/R native C and C++ compilers N.A. N.A.
In this mode, all bitfields are packed into ints defined by their base type. The compiler accepts any integer type for a bitfield. This provides compatibility with how some other compilers pack bitfields. To see how the use of all can change the packing of a structure, consider this struct: struct { short int a : 10; short int b : 10; short int c : 10; } s; With int or long containers, the compiler tries to pack the bitfields into 32-bit ints.
Usage Guidelines • BUILD_NEUTRAL_LIBRARY is a command-line directive that must be entered on the compiler RUN command line, not in the source text. • The BUILD_NEUTRAL_LIBRARY directive can also be specified with the -Wbuild_neutral_library flag of the c89 or the c99 utility. This flag is valid only for TNS/E-targeted C++ compilations and only when the -Wversion2 or -Wversion3 flag is also used. • For other guidelines, see Using the Neutral C++ Dialect (page 89).
CALL_SHARED The CALL_SHARED pragma directs the native C and C++ compilers to generate shared code, which is PIC (Position-Independent Code). The loadfile that results can access PIC library files (DLLs). Compare the action of CALL_SHARED with that of the two related pragmas: • NON_SHARED directs the compiler to generate a TNS/R non-PIC loadfile that cannot be shared and cannot access PIC files. • SHARED directs the compiler to generate PIC and to invoke the eld or ld linker to create a PIC library file.
◦ For a TNS/R C++ version 2 program, CPPINIT2 (Guardian) or cppinit2.o (On OSS environment or PC) ◦ For TNS/R C++ version 3 program, CPPINIT4 (Guardian) or cppinit4.o (On OSS environment or PC) • The CALL_SHARED and SHARED pragmas cannot be used with the SRL or NON_SHARED pragmas. A warning is issued if these pragmas are combined. • EXTERN_DATA gp_ok is not compatible with generation of shared code.
• The run-time checks provided by the CHECK pragma can slow the execution of your program. Consequently, you should use CHECK only when developing and debugging your program. • The native C and C++ compilers do not support these pragmas. The native C run-time library does not provide the additional parameter checking provided by the TNS C run-time library.
SYSTYPE GUARDIAN SYSTYPE OSS TNS/R native C and C++ compilers Not set Not set Native c89 and c99 utilities Not set Not set TNS/E native C and C++ compilers Not set Not set Usage Guidelines • The COLUMNS pragma can be entered on the compiler RUN command line or in the source text. If it is included in the source file, the COLUMNS pragma must appear before any SECTION pragmas. • The OLUMNS pragma can also be specified with the -Wcolumns=c flag of the c89 or the c99 utility.
SYSTYPE GUARDIAN SYSTYPE OSS and PC TNS/R native C and C++ compilers Not set N.A. Native c89 and c99 utilities N.A. N.A. TNS/E native C and C++ compilers Not set N.A. Usage Guidelines • The CPATHEQ pragma can appear only on the compiler RUN command line for the native C and C++ compilers. For the TNS C compiler and Cfront, the CPATHEQ pragma can appear either on the compiler RUN command line or in the source file.
preprocessed output lines might get truncated. To prevent this problem, you should include the file option and specify a file of type 180 (a C disk file, an odd-unstructured file). CSADDR The CSADDR pragma directs the TNS C compiler to copy data objects from the current code space into the stack space. The CSADDR pragma enables you to pass an address pointing at the current code space to a function of a different code space.
Usage Guidelines • The ELD pragma is a command-line directive and must not be entered in the source text. • On Guardian environment, the ELD pragma must be entered on the compiler RUN command line for TNS/E native C/C++. On OSS environment, specify the ELD pragma by using the -Weld=arg flag for the c89 or the c99 utility. • The ELD pragma does not actually invoke the eld linker. To invoke eld, you must include other pragmas such as RUNNABLE, SHARED or LINKFILE.
LIBSPACE specifies that the module does not require resources provided by the CRE and that it meets the requirements to run in the user library space or system library space. You must verify that code does not use the C run-time library and other CRE resources. The compiler performs no verification. Specifying ENV LIBSPACE does not make code that uses the C run-time library and other CRE resources able to run in the user library space or system library space.
• For TNS C and C++, pragmas ENV LIBRARY and ENV LIBSPACE restrict relocatable data blocks. Without relocatable data blocks, static data is not allowed. Therefore, the compiler allocates constants (including character string constants and data declared with a const type qualifier) in the user code space instead of the user or system data space. Because the constants are in the user code space, you cannot pass pointers to these constants between code spaces without using the CSADDR pragma.
• If the specified file is an existing error file with file code 106, the compiler replaces the contents of the existing file with the new error file. • If the specified file is an existing file but is not an error file, the compiler terminates and displays the message: ERRORFILE not created • The error file contains one record for each error or warning message that the compiler found during compilation.
The pragma default settings are SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A. G-series TNS c89 utility N.A. N.A. TNS/R native C and C++ compilers Not set Not set Native c89 utility Not set Not set c99 utility N.A. N.A. TNS/E native C and C++ compilers N.A. N.A. Usage Guidelines • The EXCEPTION_SAFE_SETJMP pragma can be entered on the RUN command line (NMC, NMCPLUS) or be specified as the -Wexception_safe_setjmp flag of the c89 utility.
_alias _arg_present _atomic_get _procaddr _resident _sg _sgx _tal _unspecified _variable _waddr • The EXTENSIONS pragma extends the grammar for the ISO/ANSI C standard. • The EXTENSIONS pragma allows the #include directive to specify section names and nolist. • The EXTENSIONS pragma defines the feature-test macro _TANDEM_SOURCE. • The EXTENSIONS pragma changes the severity of some errors to warnings.
◦ An extra comma is allowed at the end of an enum list. A remark is issued. (C and C++ behavior is the same.) ◦ In an initializer, a pointer constant value can be cast to an integral type if the integral type is large enough to contain it. ◦ long float is accepted as a synonym for double. (C and C++ behavior is the same.) ◦ The #assert preprocessing extensions of AT&T System V release 4 are allowed. These allow definition and testing of predicate names.
The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A. G-series TNS c89 utility N.A. N.A. TNS/R native C and C++ compilers EXTERN_DATA NO_GP EXTERN_DATA NO_GP Native c89 utility EXTERN_DATA NO_GP EXTERN_DATA NO_GP c99 utility N.A. N.A. TNS/E native C and C++ compilers EXTERN_DATA NO_GP EXTERN_DATA NO_GP Usage Guidelines • The EXTERN_DATA pragma can be entered on the compiler RUN command line or in the source text.
extern int errno; #pragma extern_data no_gp errno FIELDALIGN The FIELDALIGN pragma controls the component layout of structures for compatibility between TNS and native structure layout and for compatibility with native mixed-language structure layout. FIELDALIGN align-attribute [ tag-list ] align-attribute: { AUTO | CSHARED2 | SHARED2 | SHARED8 | PLATFORM } tag-list: tag-name [ tag-list ] align-attribute specifies the alignment rules for the compiler to follow.
SYSTYPE GUARDIAN SYSTYPE OSS Native c89 and c99 utilities FIELDALIGN AUTO FIELDALIGN AUTO TNS/E native C and C++ compilers FIELDALIGN AUTO FIELDALIGN AUTO While the TNS compilers and the native compilers default to AUTO, the AUTO alignment rules are not the same for the TNS, TNS/R, and TNS/E native compilers. Usage Guidelines • The FIELDALIGN pragma can be entered on the compiler RUN command line or in the source text.
FIELDALIGN attribute as the non-template base or member class; otherwise the compilation of such instantiations will fail. • For TNS C++, there are additional restrictions: ◦ FIELDALIGN must be AUTO for inherited classes and their base classes and classes with virtual member functions. ◦ Templates cannot be specified in FIELDALIGN pragmas and always have FIELDALIGN AUTO. Nested structs are not implemented for templates. Templates can contain non-AUTO structs declared using tags.
| c1 | filler | ---------------------------------| <0:2=b1><3:5=b2><6:15=filler> | ---------------------------------| <0:11=b3><12:15=filler> | ---------------------------------| c2 | | ---------------------------------- 5. This example shows the alignment of a structure with an array member: #pragma fieldalign shared2 struct { char c1; struct { char c2; int i1; } a[2]; } s1; s1: ---------------------------------c1 | a[0].c2 | ---------------------------------|a[0].
the class. The FORCE_VTBL option differs from the default behavior in that it does not force the definition to be local. • See also the description of the SUPPRESS_VTBL (page 248) command-line option. FORCE_STATIC_TYPEINFO The FORCE_STATIC_TYPEINFO command-line option forces the typeinfo variables to be static to the file. This option is applicable only to variables that are not part of an exported or imported class.
attribute-specifier: c-function-name is the name used inside the program to refer to the external routine. language is the name of the language of the external routine. tal identifies both TAL and pTAL routines. attribute specifies a function attribute, which is one of: alias ("external-name") identifies the name of the external routine used by Binder or a linker. external-name can include any character that Binder or a linker recognizes.
Table 30 Effects of FUNCTION Attributes (continued) Language No attribute extensible resident variable alias fortran Valid Error Ignore Error Valid pascal Valid Valid Ignore Valid Valid tal Valid Valid Valid Valid Valid unspecified Valid Valid Ignore Valid Valid The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler Not set Not set G-series TNS c89 utility Not set Not set TNS/R native C and C++ compilers Not set Not set Native c89 and c99 utilit
• Extensible and variable functions in native C and C++ can have a maximum of 31 parameters. • Native C++ imposes these additional restrictions on the FUNCTION pragma: ◦ Extensible and variable functions cannot be overloaded. ◦ Extensible and variable functions cannot have default parameters. ◦ Extensible and variable functions cannot be used in function templates and member functions.
• Non-preemptable code is more efficient that preemptable code, and results in faster compilation and execution. You should specify the GLOBALIZED option only when building globalized DLLs or compiling code that will be linked into a globalized DLL. • If the linker is invoked by the compiler, the linker option -b globalized is automatically specified only when a DLL is being built by the linker. HEADERS The HEADERS pragma directs the native C and C++ compilers to print a list of included header files.
Usage Guidelines • If the RUNNABLE pragma is not specified, the HEAP pragma does not affect the compilation. • One page equals 2048 bytes (2 kilobytes). • If you do not use the HEAP pragma when compiling a TNS program with the RUNNABLE pragma, the compiler automatically provides a heap of one page.
HIGHPIN The HIGHPIN pragma specifies that the object file should be run at a high PIN (256 or greater) or at a low PIN (0 through 254)..
You can set the HIGHPIN flag of a native object file either: • ◦ During compilation by using the HIGHPIN pragma, if an executable file is produced by the compilation ◦ After compilation and linking of an executable object file by using an eld, ld, or nld command For more details on using high PINs and converting a C program to run at a high PIN, see the Guardian Programmer’s Guide.
The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler NOICODE NOICODE G-series TNS c89 utility NOICODE NOICODE TNS/R native C and C++ compilers N.A. N.A. Native c89 and c99 utilities N.A. N.A. TNS/E native C and C++ compilers N.A. N.A. Usage Guidelines • The instruction code listing does not show final G-plus addresses for global variables. Instead, the addresses are relative to the start of the block.
• You must also specify the VERSION2 directive if you specify IEEE_FLOAT with the TNS/R native C++ compiler. For more details, see VERSION2 (page 254). • If you specify the IEEE_FLOAT directive, you cannot also specify the SQL pragma. • Note these advantages of using IEEE floating-point: • ◦ IEEE floating-point format has a different range of values and different precision than Tandem floating-point format.
Table 31 IEEE and Tandem Floating-Point Macro Values in float.h (continued) • • Macro Name Tandem Format IEEE Format FLT_MAX 1.1579208e77 3.40282347E+38F DBL_MAX 1.15792089237316192e77 1.7976931348623157E+308 In addition to the differences shown in Table 31, note these: ◦ For the float type in IEEE floating-point format, the smallest positive nonzero number is approximately 1.40129846E-45. This is a denormalized number; Tandem floating-point format does not have denormalized numbers.
The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler NOINLINE NOINLINE G-series TNS c89 utility NOINLINE NOINLINE TNS/R native C and C++ compilers N.A. for C, INLINEfor C++ N.A. for C, INLINE for C++ Native c89 and c99 utilities N.A. for C, INLINE for C++ N.A. for C, INLINE for C++ TNS/E native C and C++ compilers N.A. for C, INLINE for C++ N.A.
The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A. G-series TNS c89 utility N.A. N.A. TNS/R native C and C++ compilers Not set Not set Native c89 and c99 utilities Not set Not set TNS/E native C and C++ compilers N.A. N.A. Usage Guidelines INLINE_COMPILER_GENERATED_FUNCTIONS can be entered on the compiler RUN command line (NMCPLUS) or be specified with the -Winline_compiler_generated_functions flag of the c89 or the c99 utility.
Usage Guidelines • INLINE_LIMIT can only be entered on the compiler RUN command line (NMCPLUS) or be specified with the -Winline_limit=n flag of the c89 utility. • This pragma is only valid for TNS/R-target compilations. INLINE_STRING_LITERALS The INLINE_STRING_LITERALS command-line option allows the compiler to inline functions that take the address of a string literal. INLINE_STRING_LITERALS The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A.
INSPECT The INSPECT pragma controls whether the symbolic debugger or the default system debugger is used as the default debugger for the object file. The INSPECT pragma specifies a symbolic debugger as the default debugger, and the NOINSPECT pragma specifies the system default debugger as the default debugger.
– ◦ INSPECT selects, in order of precedence: TNS/R system TNS/E system Visual Inspect Visual Inspect Inspect Inspect DEBUG Native Inspect For a native process: – – NOINSPECT selects, in order of precedence: TNS/R system TNS/E system DEBUG Native Inspect INSPECT selects, in order of precedence: TNS/R non-PIC TNS/R PIC TNS/E Visual Inspect Visual Inspect Visual Inspect Inspect DEBUG Native Inspect DEBUG When the TACL RUNV command or OSS runv utility is used, then this debugger pragma
The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A. G-series TNS c89 utility N.A. N.A. TNS/R native C and C++ compilers Not set for C, N.A. for C++ Not set for C, N.A. for C++ Native c89 utility Not set for C, N.A. for C++ Not set for C, N.A. for C++ c99 utility N.A. N.A. TNS/E native C and C++ compilers Not set for C, N.A. for C++ Not set for C, N.A.
Example Assume the header file defh contains: struct worddef { #ifdef MACHINE_WORDLEN_32 int intvar1; int intvar2; #else long intvar; #endif }; Further, assume that module1c includes the header file defh and that the structure worddef contains members intvar1 and intvar2. Also assume that module2c includes the header file defh and contains a single member intvar.
LINES The LINES pragma specifies the maximum number of output lines per page for the compiler listing file. LINES lines_per_page lines_per_page specifies the maximum number of text lines per page for the listing file. lines_per_page must be an integer in the range 10 through 32767.
Usage Guidelines • On Guardian environment, the LINKFILE pragma must be entered on the compiler RUN command line for native C and C++. • LINKFILE invokes eld or ld rather than nld if you include SHARED or CALL_SHARED. • Use the LINKFILE pragma to specify in a text file the names of the object files or linkfiles (not source files) that make up a program for linking with a linker utility. An example of LINKFILE appears in Examples (page 306).
LOC specifies load maps of functions and data blocks sorted by starting address. * specifies both ALPHA and LOC. The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler NOLMAP * NOLMAP * G-series TNS c89 utility NOLMAP * NOLMAP * TNS/R native C and C++ compilers N.A. N.A. Native c89 and c99 utilities N.A. N.A. TNS/E native C and C++ compilers N.A. N.A.
The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS and PC TNS C compiler Not set Not set G-series TNS c89 utility N.A. N.A. TNS/R native C and C++ compilers Not set Not set Native c89 and c99 utilities N.A. N.A. TNS/E native C and C++ compilers Not set Not set Usage Guidelines • The MAPINCLUDE pragma can be specified only in the source file.
Usage Guidelines • This pragma is only supported in TNS/E compilers. • This pragma applies only to definitions of a composite type. For C, composite types include array types, struct types, and union types. For C++, composite types also include classes. • You do not need to specify this pragma if it appears in the standard header file that supplies the data type declaration. • The size of the type is padded at the end if necessary to make the size an integral multiple of its alignment.
• • When MIGRATION_CHECK is specified, no object file is produced by NMCPLUS, CPPCOMP, or c89. The listing, if enabled, itemizes the functions called from the VERSION2 library that are not supported in VERSION3. ◦ On OSS environment, a listing is produced only if you also specify -Wnosuppress. Diagnostics are also sent to stderr. ◦ On Guardian environment, a listing is produced by default unless you also specify NOLIST on the command line.
The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A. G-series TNS c89 utility N.A. N.A. TNS/R native C and C++ compilers Not set Not set Native c89 and c99 utilities Not set Not set TNS/E native C and C++ compilers Not set Not set Usage Guidelines • MULTIBYTE_CHAR is a command-line directive that must be entered on the compiler RUN command line, not in the source text.
NEUTRAL The NEUTRAL pragma is only supported for use within HP NonStop system header files for TNS/E. It controls whether a struct, class, or union definition is considered as part of the C++ CPPNEUTRAL dialect and marks it as being available in the neutral C++ standard library. NEUTRAL This pragma is not recognized by the TNS/R compiler. There is no default setting for this pragma.
Usage Guidelines • On Guardian environment, the NLD pragma must be entered on the compiler RUN command line for TNS/R native C and C++. On OSS environment, specify the NLD pragma by using the -Wnld=arg option with the c89 utility. • If you are linking TNS/R PIC (Position-Independent Code), you must use the LD(arg) pragma to specify arguments to the ld utility.
NON_SHARED The NON_SHARED pragma directs the native C and C++ compilers to generate non-shared code (that is, not PIC (Position-Independent Code). Compare the action of NON_SHARED with that of the two related pragmas: • CALL_SHARED directs the compiler to generate PIC. • SHARED directs the compiler to generate PIC and to invoke the ld linker to create a PIC library file. NON_SHARED The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A. G-series TNS c89 utility N.A.
If you specify the OLDCALLS pragma, the TNS C compiler generates code for function parameters such that the parameters are stacked with the last parameter first and the first parameter last. Versions of the TNS C compiler released prior to C00 behave this way. If you specify NOOLDCALLS, the TNS C compiler generates code for function parameters such that the parameters are stacked with the first parameter first and the last parameter last. C00 and later versions of the TNS C compiler behave this way.
Usage Guidelines • This directive applies to TNS/R-targeted compilations only. • On Guardian environment, the OLIMIT pragma can appear only on the RUN command line for NMC or NMCPLUS . On OSS environment, the -Wolimit=[value] option can appear only on the RUN command line for the c89 utility. • When a routine has more basic blocks than value, the routine is not optimized and a warning message is issued.
SYSTYPE GUARDIAN SYSTYPE OSS Native c89 and c99 utilities Not set Not set TNS/E native C and C++ compilers Not set Not set Usage Guidelines • For the native C and C++ compilers, the OPTFILE pragma can be entered only on the compiler RUN command line. For OSS, the -Woptfile option pragma can be entered only in the c89 or the c99 command line. • Each line of the optimizer file can contain only one function name and the optimize level (0,1, or 2) that you want for that function.
boundaries, optimization level 1 is useful when you are developing and debugging your program. ◦ • Optimization level 2 provides both intrastatement and interstatement optimizations. Interstatement optimizations can affect statement boundaries, which, in turn, can make debugging a program more difficult. Consequently, you should use optimization level 2 only after your program is thoroughly debugged and tested.
Example #pragma NOOVERFLOW_TRAPS void NoTraps (void) { /* No trapping code generated */ } #pragma OVERFLOW_TRAPS void Traps (void) { /* Generates trapping code */ } #pragma NOOVERFLOW_TRAPS /* Again, no trapping code generated */ PAGE The PAGE pragma causes a page eject in the compiler listing and prints a page heading. The page eject occurs only when the output is being directed to a printer or spooler device. PAGE [ "title-string" ] title-string specifies the title to print on each subsequent page.
POP The POP pragma directs the native compilers to restore the value of certain pragmas that were stored earlier by a PUSH pragma. POP pragma-name pragma-name: { EXTERN_DATA | FIELDALIGN | LIST | OVERFLOW_TRAPS | REFALIGNED | WARN } There is no default setting for this pragma. Usage Guidelines • The POP pragma can be entered only in the source text. • Only the values EXTERN_DATA, FIELDALIGN, LIST, OVERFLOW_TRAPS, REFALIGNED, and WARN can be used as arguments to the POP pragma.
• When code that was generated from separate compilations will later be included in a single application, you should specify the same raw data file location for all the compilations. • In the OSS and Windows environments, the -Wprofdir flag has an effect only for -Wtarget=ipf or -Wtarget=tns/e. It is ignored (and no diagnostic is issued) for -Wtarget=mips or -Wtarget=tns/r. For more information on code profiling and the Code Profiling Utilities, see the Code Profiling Utilities Manual.
The default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A. G-series TNS c89 utility N.A. N.A. TNS/R native C and C++ compilers N.A. N.A. Native c89 and c99 utilities N.A. File name pgopti.dpi in the current working directory or file name pgodpi in the default subvolume TNS/E native C and C++ compilers File name pgodpi in the default subvolume N.A. Usage Guidelines • The PROFUSE option can be entered only on the compiler RUN command.
Usage Guidelines • The PUSH pragma can be entered only in the source text. • Only the values EXTERN_DATA, FIELDALIGN, LIST, OVERFLOW_TRAPS, REFALIGNED, and WARN can be used as operands to the PUSH pragma. The use of any other pragma as an operand is flagged as an error. • Each PUSH pragma has a separate stack, each of which holds up to 32 values. REFALIGNED The REFALIGNED pragma specifies the default reference alignment for pointers in native C and C++ programs.
• If you declare a TYPEDEF and it is of a type that has been given an explicit reference alignment, that REFALIGNED value is propagated to the new TYPEDEF. Otherwise, the new TYPEDEF gets the current global default REFALIGNED value. • When SHARED2 substructs are nested within AUTO, PLATFORM, or SHARED8 structs, the substruct contributes only a 1-byte or 2-byte alignment requirement to the overall struct, even when the substruct contains 4-byte or 8-byte field types.
• When you specify the RUNNABLE pragma, the native C and C++ compilers does: ◦ Invoke the appropriate linker for conventional or PIC (Position-Independent Code) ◦ Specify the $SYSTEM.SYSTEM.LIBCOBEY command file to a TNS/R linker – The LIBCOBEY file directs the linker to link to a set of standard shared run-time libraries (SRLs). For most C and C++ TNS/R programs, this set of libraries is sufficient to create an executable program.
Using the Binder SET command: ◦ Specify the Binder SET RUNNAMED ON command. The default state for the Binder is RUNNAMED OFF. ◦ The Binder SET RUNNAMED ON command takes precedence over any RUNNAMED pragmas that might or might not have been specified in individually compiled object files. • For native programs, you can set the HIGHREQUESTERS object-file attribute either during compilation using the HIGHREQUESTERS pragma or after compilation using a linker utility.
SYSTYPE GUARDIAN SYSTYPE OSS H-series or J-series native c89 or c99 The H-series RVU in which the compiler The H-series RVU in which the compiler was last released was last released utility TNS/E native C and C++ compilers The RVU in which the compiler was last released The RVU in which the compiler was last released Usage Guidelines • For the TNS/E native compilers in the Guardian environment, only the h-series-rvu option is supported.
• You can set the SAVEABEND object-file attribute after compilation using the Binder SET command (for TNS programs) or a linker utility (for native programs). • For this option to be effective at run time, the symbolic debugger must be available on the system on which the process runs. • The INSPECT and SAVEABEND pragmas are related: • ◦ If you specify NOINSPECT, the compiler automatically disables SAVEABEND (as though you had explicitly specified NOSAVEABEND).
Usage Guidelines • On Guardian environment, the SEARCH pragma must be entered on the compiler RUN command line. • The quotation marks enclosing object-file are required delimiters. • If the SEARCH pragma is specified in the same compilation unit with the XMEM, NOXMEM, WIDE, or SYMBOLS pragmas, the SEARCH pragma must be specified after these pragmas. SECTION The SECTION pragma gives a name to a section of a source file for use in an #include directive.
SHARED The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A. G-series TNS c89 utility N.A. N.A.
{ { { { [NO]SQLMAP RELEASE1 | RELEASE2 CHAR_AS_ARRAY | CHAR_AS_STRING CPPSOURCE "filename" } } } } [NO]WHENEVERLIST controls whether the compiler listing includes notification of active SQL WHENEVER clauses. WHENEVERLIST directs the compiler to provide a summary list of the WHENEVER clauses that are active when an SQL statement is processed. NOWHENEVERLIST directs the compiler to omit this summary list. If you do not specify either WHENEVERLIST or NOWHENEVERLIST, the C compiler assumes NOWHENEVERLIST.
The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler Not set Not set G-series TNS c89 utility Not set for C, N.A. for C++ Not set for C, N.A. for C++ TNS/R native C and C++ compilers Not set for C, N.A. for C++ Not set for C, N.A. for C++ Native c89 utility Not set for C, N.A. for C++ Not set for C, N.A. for C++ c99 utility N.A. N.A. TNS/E native C and C++ compilers Not set for C, N.A. for C++ Not set for C, N.A.
SQLMEM { USER | EXT } USER directs the compiler to place the SQL data structures in the user data segment, which is the global area addressable in 16 bits. The SQLMEM USER pragma improves the access time to the data structures but should be used judiciously, because it can exhaust the user data segment. EXT directs the compiler to place the SQL data structures in the extended segment.
Usage Guidelines • For the TNS/R native compilers, the SRL pragma can be entered only on the compiler RUN command line. In the OSS environment, the pragma can be specified with the -Wsrl flag of the c89 utility. • This pragma signifies that the code is being compiled to go into a SRL. This prevents the compiler from using GP-relative addressing for global data. (Global data can be either extern or static in scope.) This also causes the compiler to put anonymous literals into the read-only data area.
• SRLExportClassMembers PROTECTED exports all protected members of the class whose declaration textually precedes the pragma. • SRLExportClassMembers PUBLIC exports all public members of the class whose declaration textually precedes the pragma. • SRLExportClassMembers * exports all protected and all public members of the class whose declaration textually precedes the pragma. • This pragma is not valid for the TNS/E native compilers.
Usage Guidelines • This pragma is valid only for TNS/R-targeted compilations. • The SRLName pragma is used to determine whether a SRLExportClassMembers pragma provides a definition or a declaration for its exported functions. • The SRLName pragma must appear in the source file before any SRLExportClassMembers pragma. Example // inc.
volume is the name of the volume to search. subvolume is the name of the subvolume to search. The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler Current subvolume and then compiler Current subvolume and then compiler subvolume subvolume G-series TNS c89 utility N.A. TNS/R native C and C++ compilers Current subvolume and then compiler Current subvolume and then compiler subvolume subvolume Native c89 and c99 utilities N.A.
• If you use SSV pragmas with TNS C, the compiler subvolume is not searched. Consequently, if your program needs any standard header file, you must add a search subvolume (SSV) for the system library. For example, if you specify any SSV pragmas and your program contains a standard library file header such as #include , you must have an SSV pragma for “$system.system” (the location of the stdioh file on the NonStop host), because the compiler does not automatically search the compiler subvolume.
The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler STDFILES N.A. G-series TNS c89 utility STDFILES N.A. TNS/R native C and C++ compilers STDFILES N.A. Native c89 and c99 utilities STDFILES N.A. TNS/E native C and C++ compilers STDFILES N.A. Usage Guidelines • For the native compilers, the STDFILES pragma can be entered only on the compiler RUN command line.
• • The constructs that the STRICT pragma causes the compiler to diagnose include: ◦ Function declarations and definitions that do not use function-prototype syntax ◦ Calls to functions that do not have a function-prototype declaration or definition in scope ◦ Calls to functions that have no nonprototype declaration or definition in scope ◦ Calls to library routines that occur before inclusion of the library header that declares or defines the routine ◦ Object declarations that do not include a
such function, the default behavior is to make the definition a local static entity. This option is valid only for native TNS/R C++ only. SUPPRESS_VTBL The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A. G-series TNS c89 utility N.A. N.A.
programs, the SYMBOLS pragma must appear on the compiler RUN command line or at the start of the source text before any declarations or source code statements. • The SYMBOLS pragma affects the INSPECT pragmas: if you specify SYMBOLS, the compiler automatically enables Visual Inspect and the source-level symbolic debugger, as though you had explicitly specified INSPECT. • In native mode, the SYMBOLS pragma cannot include the NODEFINES option.
Usage Guidelines • The SYSTYPE pragma can be entered on the compiler RUN command line or be specified with the -Wsystype flag of the c89 or the c99 utility. A SYSTYPE pragma in the source text does not change the target environment; it is only an affirmation of the target environment. • The compiler issues an error if a SYSTYPE pragma specified in the source text differs from: ◦ The SYSTYPE pragma specified on the RUN command line. ◦ The -Wsystype flag of the c89 or the c99 utility.
G06.06, you can choose either Tandem floating-point format or IEEE floating-point format. For more details, see Compiling and Linking Floating-Point Programs (page 301). • For a high-level discussion of differences between IEEE and Tandem floating-point, see IEEE Floating-Point Arithmetic (page 75). • For more detailed information about differences between the IEEE and Tandem floating-point formats, see the pragma IEEE_FLOAT (page 203).
Usage Guidelines • As of G06.20, the default for native mode C++ compilation is VERSION3 (not VERSION1). If you are going to recompile an application that used the previous default (VERSION1), you must specify the VERSION1 pragma. See also VERSION2 (page 254) and VERSION3 (page 255). • You can enter the VERSION1 directive on the compiler RUN command line when specifying NMCPLUS on Guardian environment, or using the -Wversion1 flag when specifying c89 On OSS environment.
VERSION2 The VERSION2 pragma is a command-line directive for native mode C++ that instructs the C++ compiler to compile using the dialect or features available beginning with the D45 version of the HP C++ language. This pragma is not accepted by the TNS compilers. VERSION2 The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A. G-series TNS c89 utility N.A. N.A. TNS/R native C and C++ compilers VERSION3 for C++, N.A. for C VERSION3 for C++, N.A.
• Object files compiled using VERSION2 take advantage of the features available beginning at the D45 RVU and are incompatible with object files compiled using earlier or later versions of the native C++ compiler. ◦ If you compile an application composed of multiple modules, you must compile all modules using the same version directive. For example, if you use the VERSION2 directive to compile any module of a program, you must compile all modules of the program using the VERSION2 directive.
The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A. G-series TNS c89 utility N.A. N.A. TNS/R native C and C++ compilers VERSION3 for C++ N.A. for C VERSION3 for C++ N.A. for C Native c89 utility VERSION3 for C++ N.A. for C VERSION3 for C++ N.A. for C c99 utility VERSION3 VERSION3 TNS/E native C and C++ compilers VERSION3 for C++ N.A. for C VERSION3 for C++ N.A.
You can disable version checking by designating a loadfile CPPNEUTRAL using a linker. You can also display the C++ version of a loadfile by using the LISTATTRIBUTES command of enoft or noft.
WARN The WARN pragma controls the generation of all or selected warning messages. The WARN pragma enables the compiler to generate all or a selected set of warning messages, and NOWARN disables the compiler from generating all or a selected set of warning messages. [NO]WARN [ warning-list ] warning-list: ( warning-number [, warning-number ]... ) warning-list is a parenthesized, comma-separated list of warning-message numbers.
SYSTYPE GUARDIAN SYSTYPE OSS TNS/R native C and C++ compilers N.A N.A. Native c89 and c99 utilities N.A N.A TNS/E native C and C++ compilers N.A N.A Usage Guidelines • The WIDE pragma can be entered on the compiler RUN command line or in the source text. • The TNS C++ translator, Cfront, is WIDE by default. The TNS C compiler is effectively NOWIDE by default.
• The NOXMEM pragma compiles only under the 16-bit data model. The combination of the WIDE and NOXMEM pragmas is diagnosed as an error. • All translation units of a program must specify the same memory model. For more information about the two memory models, see Two Memory Models: Large and Small (page 323). • The preprocessor variable __XMEM is defined when the XMEM pragma is in effect.
14 Compiling, Binding, and Accelerating TNS C Programs The TNS C compiler takes as input a module (a translation unit) and generates an object file. A module is a source file and all the headers and source files it includes, except for any source lines skipped as the result of conditional preprocessor directives. The Binder collects and links object files generated by the C compiler and produces an executable object file (a program file).
Table 32 Development Platform Capabilities (TNS Programs) (continued) Run Guardian TNS programs? Yes Yes Run OSS TNS programs? No Yes (G-series only) These restrictions apply to developing Guardian TNS programs with OSS tools: • The TNS versions of OSS tools are not available on TNS/E systems. • You cannot use the NOWIDE, NOXMEM, and NOXVAR pragmas. Therefore, you can develop programs that use only the 32-bit or wide data model. • You cannot use the RUNNABLE and SEARCH pragmas.
While header files are optional (but strongly recommended) for programs that contain Guardian or OSS modules exclusively, header files are required for mixed-module programs. If you do not compile using header files, the Binder cannot correctly resolve external references to Guardian C and OSS functions. Working in the Guardian Environment In the Guardian environment, you can compile, bind, and accelerate C programs for either the Guardian or G-series Open System Services (OSS) environment.
compile-option modifies compiler operation by specifying a compiler pragma or defining a preprocessor symbol. pragma is any compiler pragma. If you want, you can abbreviate the pragma name. The rule is that you must specify enough letters of the pragma name to make the name unique. For example, you need at least RUNNAB for the RUNNABLE pragma, because otherwise it would be confused with the RUNNAMED pragma. define identifier [ integer-constant ] defines identifier as a preprocessor symbol.
5> BIND After starting Binder, you enter Binder commands to combine your object files and C run-time library object files to produce a program file.
Specifying Library Files To resolve references to external routines, Binder uses different model-dependent library files that depend on your program’s execution environment, data model, and memory model. Table 33 shows you how to select the correct library files for your programs.
SELECT SEARCH clib ADD * FROM clib Delete any old copies of CLIB from $SYSTEM.SYSTEM. Restrictions on Binding Caused by the ENV Pragma Binder categorizes the ENV pragma options into three groups: OLD, NEUTRAL, and COMMON. For the most part, these groups match the various ENV options. Table 34 shows how Binder classifies object files into one of three groups depending on the compiler version or specified ENV option.
The Accelerator and OCA take as input an executable TNS object file and produce as output an accelerated object file. The accelerated object file contains both the original TNS code and the logically equivalent optimized native instructions—accelerated object code. The 1. 2. 3. basic steps to accelerate a C program are: Compile and bind the program. Debug the program, if necessary. Run the Accelerator. On TNS/R systems, you do this with the AXCEL command. On TNS/E systems, you use the OCA command.
Components of the TNS c89 Utility The TNS c89 utility enables you to compile ISO-compliant C programs for NonStop environment. By default, c89 generates code for the OSS environment. c89 provides a simple interface to the components of the C compilation system: • C language preprocessor The preprocessor manipulates the text of the source file to prepare it for the C compiler, including the insertion of function prototypes from the specified header files.
Table 37 Commonly Used TNS c89 Flags and Guardian Environment Equivalents (continued) To direct c89 to: Specify this flag: Equivalent Guardian environment action Pass an argument string to the Accelerator -Waxcel [="arguments"] Specify arguments on the Accelerator command line or in a command file Pass an argument string to the Binder -Wbind [= "arguments"] Specify arguments in a Binder command file or run the Binder interactively Pass an argument string to the C compiler -Wccom [= "arguments"] Sp
You can also perform static binding for OSS programs. In static binding, the Binder resolves references to library functions by binding the functions into the program. Static libraries can be used for dynamic binding. The Binder resolves external references using all the specified static libraries before using the SRL. Binding Considerations • To bind a Guardian program with the TNS c89 utility, specify the libgwc.a library. libgwc.a is equivalent to the Guardian file CWIDE.
using the library mylib.a before using the standard library libc.a. The -O flag causes invocation of the Accelerator on the program file. 8. In this example, c89 produces a program made up of modules compiled for both the Guardian and OSS environments: c89 -Wsystype=guardian -o guard.o -c guard1.c guard2.c The command compiles the source files guard1.c and guard2.c for the Guardian environment and generates an object file guard.o. The -c flag suppresses the binding phase. The command: c89 oss1.c oss2.
15 Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment To create an executable TNS C++ program in the Guardian environment: 1. Run the C preprocessor Cprep 2. Run the C++ translator Cfront 3. Run the C compiler 4. Run the Binder 5.
To use this macro, the name of your C++ source file must end in the letter “c.” For example, the command syntax to compile a C++ program located in file helloc is: cplus hello If the name of your C++ source file does not end in the letter “c,” you should either rename your source file or modify the cplus macro. C Preprocessor Cprep Cprep is a general-purpose C preprocessor.
For subsequent lines in that file, the #line directive has the form: #line edit-line-number The timestamp given the first time a file is referenced represents the modification timestamp for the C++ source input file. This information is used by the symbolic debuggers to identify possible source code version inconsistencies.
For a detailed description of all the C compiler pragmas, see Chapter 13: Compiler Pragmas. define identifier [ integer-constant ] defines identifier as a preprocessor symbol. If identifier is followed by an integer or character constant, identifier is defined as an object-like macro that expands to the given value. Usage Guidelines • Remember that the output that is produced from running Cprep is kept in an intermediate file. Each time that you run Cprep, the output is added to the end of the file.
Pragma Use NOWARN(134, 135) disables the TNS C compiler from generating warning messages 134 and 135. C compiler messages 134 and 135 warn that a function was used before it was declared. Cfront turns off these warning messages because the #include preprocessor directives in your C++ source code that declare the standard C header files are expanded by Cprep. Therefore, the C compiler would not see the #include directives and would emit warning messages anytime your program calls a standard C function.
If your program has multiple compilation units, you use Binder to combine the TNS object files produced by the C compiler into one executable TNS object file. If your program comprises a single compilation unit, you can use the RUNNABLE pragma in the C++ source file or on the Cprep run command line to direct the TNS C compiler to produce an executable TNS object file without having to run the Binder.
Example In this example, the intermediate file intfile2, which was previously created by Cfront, is now input to the TNS C compiler. The TNS C compiler produces the TNS object file progo that you can now use to bind together with other TNS object files to produce an executable TNS object file for the C++ program. C/ IN intfile2, OUT $s.
cprep/in progcp, out intfile1/define __cplusplus, & SSV0 "$system.system" cfront/in intfile1, out intfile2/ c/in intfile2, out $s.#hold/progo To run this program, enter: run progo The program will respond with: Hello World Error Messages in the Guardian Environment This subsection provides information on the compile-time and run-time error messages that are generated in the Guardian environment.
Binding C++ Programs If you do not use the RUNNABLE pragma when compiling a single-module program or if your program comprises several separately compiled modules, you must use Binder to collect and combine the compiled modules into an executable C++ object file.
SET HEAP value PAGES specifies the heap size of the program. BUILD program-file directs Binder to build an executable object file using the files and options specified in the preceding commands. The program-file is the name of the executable object file that Binder builds. For more details regarding Binder and its commands, see the Binder Manual.
operand, is a valid c89 utility operand. TNS c89 Flags You can invoke Cfront through the TNS c89 utility with the -Wcfront flag using this syntax: -Wcfront[="args"] When TNS c89 sees the ="args" portion of the -Wcfront flag, c89 passes to Cprep the argument string enclosed in the double quotation marks. Table 39 lists other commonly used TNS c89 flags. Table 39 Commonly Used TNS c89 Flags Flag Function -c Compiles the specified source files but does not bind them.
Table 40 TNS c89 Operands (continued) file.so A shared run-time library produced by Binder. The shared run-time library is used by the Binder to resolve external references. -l library In the static binding mode, search for the library named liblibrary.a. In the dynamic binding mode, search for the library named liblibrary.so. If liblibrary.so is not found, liblibrary.a is used. For example, if you use the operand -l cre,the libraries searched for are libcre.a and libcre.so.
Error Messages in the OSS Environment When the TNS c89 utility encounters a compilation error that causes an object file to not be created, it writes a diagnostic to the standard error file and continues to compile other source code operands. TNS c89 does not perform program binding and returns a nonzero exit status. When a Binder operation is unsuccessful, a diagnostic message is written to the standard error file and TNS c89 exits with a nonzero status.
16 Compiling and Linking TNS/R Native C and C++ Programs The TNS/R native C and C++ compilers take as input a module (a translation unit) and generate an object file or linkfile. A module is defined as a source file with all the headers and source files it includes, except for any source lines skipped as the result of conditional preprocessor directives. The nld utility links object files generated by the compilers and produces an executable object file (a program file).
Table 41 Development Platform Capabilities (TNS/R Native C and C++ Programs) (continued) Compile programs with embedded SQL? Yes Yes Yes Yes Use PC-based development tools No for Guardian and OSS programs? No Yes Yes These restrictions apply to developing Guardian programs with OSS tools: • You cannot use the RUNNABLE and SEARCH pragmas. However, you can direct the c89 utility to bind implicitly after a compilation. You can also specify library files to be searched using the c89 -L flag.
for NonStop Systems. For information about including SRLs at link time, see Determining Which SRLs are Required (page 295). You can specify locations to search for header files: • In the Guardian environment, use the SSV pragma to specify a search list of subvolumes for files specified in #include directives. For more details, see pragma SSV (page 244). • In the OSS environment, use the -I flag to the c89 utility to specify a search list of directories for files specified in #include directives.
The native compilers set the floating-point format type in the generated object file. Two examples of compiling native C and C++ programs that use IEEE floating-point format: NMC / IN SOURCEA, OUT $.#LIST / OBJECTA; IEEE_FLOAT > NMCPLUS / IN SOURCEB, OUT $S.
Table 44 Floating-Point State as Determined by TNS/R Native Linker floattype Attribute (continued) Tandem IEEE Neutral -set Tandem -set IEEE -set Neutral the output object file is TANDEM_ FLOAT. the output object file is NEUTRAL_ file is IEEE_FLOAT. FLOAT. 0 1 or more 0 or more Warning message is generated and output object file is TANDEM_ FLOAT. No message is generated and the output object file is IEEE_FLOAT. Warning message is generated and the output object file is NEUTRAL_ FLOAT.
Even if the user library is marked with a floattype attribute that conflicts with the program file, the program can use the library if it doesn’t call anything in the user library that uses floating point. In this case, you need to mark the program file with the nld or ld -set float_lib_overrule on command to disregard the floattype attribute of the user library file. In fact, the run-time consistency check can be overruled by using the -set float_lib_overrule on flag of the TNS/R native linker utility.
Compiling a Module The native compilers translate the source text of a module and produce: • An extensive compiler listing. Several pragmas enable you to control the content of this compiler listing. • A nonexecutable object file, if the compiler encountered no errors during the compilation.
run-options is a comma-separated list of additional options for the RUN command. These options are described in the TACL Reference Manual. object specifies the file to which the TNS/R native C or C++ compiler writes the object code for the source text. If you do not specify an object file, the compiler writes the object code to the file OBJECT in your current default volume and subvolume.
> NMC /IN filec / fileo; RUNNABLE 5.
Some of the code configured in the system library for TNS processes is packaged in SRLs for TNS/R native processes. For example, the TNS/R C run-time library, the TCP/IP sockets library, the Tools.h++ class library, and much of the OSS API are packaged as SRLs for TNS/R native processes. HP supplies public SRLs; you cannot create your own public SRLs. Each processor loads its public SRLs at startup from the active SYSnn subvolume.
For a given version, you can link only to the SRLs listed in the column or stack for that version in Table 45: SRLs Available When Using VERSION1, VERSION2, and VERSION3. If you attempt to link to SRLs that are listed in another column, unexpected results can occur. The order of the column or stack is also important, especially for TNS/R native C++, because it represents the order in which libraries should be loaded and accessed at run time.
Table 46 Using the Guardian TNS/R Native Linker Utilities to Link SRLs If your program uses: You should specify these TNS/R native linker utility flags: C run-time library and runs in -OBEY $SYSTEM.SYSTEM.LIBCOBEY the Guardian environment or -l ZCRTLSRL -l ZCRESRL C run-time library and runs in -OBEY $SYSTEM.SYSTEM.
> NLD $SYSTEM.SYSTEM.CRTLMAIN MYOBJ -o MYEXEC & -l ZTLHSRL -l ZRWSLSRL -l ZCPLSRL -l ZCRTLSRL & -l ZCRESRL 2. The specified nld flags link a VERSION2 OSS C program: > NLD $SYSTEM.SYSTEM.CRTLMAIN MYOBJ -o MYEXEC -l ZTLHSRL -l ZRWSLSRL -l ZCPLSRL & -l ZOSSHSRL -l ZCRTLSRL -l ZCRESRL & -l ZOSSKSRL -l ZOSSFSRL -l ZSECSRL & -l ZI18NSRL -l ZICNVSRL -l ZOSSESRL & -l ZINETSRL -l ZSTFNSRL 3. & A simplified version of the previous example: > NLD $SYSTEM.SYSTEM.CRTLMAIN MYOBJ -o MYEXEC & -OBEY $SYSTEM.SYSTEM.
17 Compiling and Linking TNS/E Native C and C++ Programs The TNS/E native C and C++ compilers take as input a module (a translation unit) and generate an object file or linkfile. A module is defined as a source file with all the headers and source files it includes, except for any source lines skipped as the result of conditional preprocessor directives. The eld utility is the TNS/E native linker that links PIC (Position-Independent Code) linkfiles to produce PIC loadfiles.
Table 47 Development Platform Capabilities (TNS/E Native C and C++ Programs) (continued) Use OSS development tools for Guardian programs? No Yes No Yes Use OSS development No tools for OSS programs? Yes No Yes Run Guardian programs? Yes Yes No Yes Run OSS programs? No Yes No Yes Compile programs with embedded SQL? Yes Yes Yes Yes Use PC-based development tools for Guardian and OSS programs? No No Yes Yes These restrictions apply to developing Guardian programs with OSS tools: •
To specify header files, use the #include preprocessor directive. For example, to include the STDIO header file, specify in your object file: #include You might also need to specify header files for the TNS/E native Standard C++ Library and Tools.h++ library to use functions contained in those libraries. For examples of #include directives for these libraries, see Using the Standard C++ Library and Chapter 6: Accessing Middleware Using HP C and C++ for NonStop Systems.
Using Compiler Pragmas IEEE_Float and Tandem_Float • To use IEEE floating-point format, you can optionally specify the IEEE_FLOAT pragma on the command line when running the TNS/E native C or C++ compiler. IEEE_FLOAT is the default setting for TNS/E native compilations. If you are using TNS/E native C++, you also need to specify the VERSION2 or VERSION3 directive. For more details, see the pragmas IEEE_FLOAT (page 203), VERSION2 (page 254), and VERSION3 (page 255).
When the floattype attribute is explicitly specified with the -set flag, eld sets the floattype attribute value for the output object file to that specified value. If an inconsistency is detected, a warning message and an output object file are generated. If the floating-point state is invalid, no output object file is created. Any floating type combination is allowed if the user explicitly overrides the default with the set floattype flag.
Even if the user library is marked with a floattype attribute that conflicts with the program file, the program can use the library if it does not call anything in the user library that uses floating point. In this case, you need to mark the program file with the eld -set float_lib_overrule on command to disregard the floattype attribute of the user library file. In fact, the run-time consistency check can be overruled by using the -set float_lib_overrule on flag of the eld utility.
Compiling a Module The native compilers translate the source text of a module and produce: • An extensive compiler listing; several pragmas enable you to control the content of this compiler listing • A nonexecutable object file (if the compiler encountered no errors during the compilation) After compiling all the modules that compose your program, you collect and combine them into a program file (an executable object file) by using the eld utility.
compile-option modifies compiler operation by specifying a compiler pragma or defining a preprocessor symbol. pragma is any valid command-line compiler pragma. define identifier [ constant ] defines identifier as a preprocessor symbol. If identifier is followed by a constant, identifier is defined as an object-like macro that expands to the given value. define is equivalent to using the #define preprocessor directive in source text. undefine identifier deletes identifier as a preprocessor symbol.
Linking a TNS/E Module You need to use a linker to collect and combine object files into a program file (an executable object file or a loadfile) if you did not instruct the compiler to perform the linking (that is, if you did not use the RUNNABLE pragma when compiling a single-module program or if you did not use the RUNNABLE and LINKFILE pragmas when compiling a multiple-module program).
4. 5. Specify the DLLs used by your program. For complete details, see Determining Which SRLs are Required (page 295). If your program uses the active backup programming functions, such as __ns_start_backup(), specify the active backup programming support object code file $SYSTEM.SYSTEM.CRTLNSE. Command examples are shown in Examples (page 297). Shared Run-Time Libraries and Dynamic-Link Libraries (DLLs) The NonStop system implicit libraries are compatible with the use of dynamic-link libraries (DLLs).
Table 51 DLLs Available When Using VERSION2 and VERSION3 (continued) VERSION 2 VERSION 3 Guardian OSS Guardian OSS OS OS OS OS Notes: DLL names are shown without the leading Z and these DLL; therefore, CPPC represents ZCPPCDLL, and TLH7 represents ZTLH7DLL. OS represents the HP NonStop OS. OSS represents the Open System Services environment. CRTL represents the C run-time library. CRE represents the common run-time environment.
Table 52 Using the Guardian eld Utility to Link DLLs (continued) If your program uses: You should specify these eld utility flags: OSS nlist() function -l UTIL and other DLLs required by the program environment TCP/IP socket library -l INET and other DLLs required by the program environment For more details about the linker, see these manuals: • eld Manual • rld Manual Examples 1. The specified eld flags link a VERSION2 Guardian C++ program that uses the Tools.
return 31; } Compiler and Linker Commands: CCOMP / in NC, out NLST / NDLL; shared == Compile NC with shared (as a DLL); linkfile is PIC CCOMP / in MC, out MLST / MOBJ; call_shared == Compile MC module with call_shared; linkfile is PIC ELD / out LLST / mobj $SYSTEM.SYSTEM.CCPLMAIN -libvol $myvol.svol -lib NDLL & -o MEXE & == Build MEXE, specifying CCPLMAIN (CRE component).
18 Using the Native C/C++ Cross Compiler on the PC NSDEE The HP NonStop Development Environment for Eclipse (NSDEE) is a Windows hosted integrated development environment for NonStop applications. NSDEE supports building NonStop applications locally using Windows-hosted cross compilers and tools, or remotely using compilers and tools on a NonStop server.
• Deploy targets to a NonStop host automatically with project deployment or manually with the Transfer Tool • Create and maintain archive files • Modify the name of include files from the Guardian format to the PC format using the Fix Include Tool • Compile NonStop SQL/MP statements embedded in native C and COBOL source code • Compile NonStop SQL/MX statements embedded in native C/C++ and COBOL source code • Enter ADD, MODIFY, SET, and DELETE statements into a TACL DEFINE file • Configure exter
• To use the C/C++ cross compiler, the source files must reside in the PC namespace. Because the cross compiler runs on the PC, the compiler cannot see files located on NonStop server nodes. Therefore, you must transfer your source files from the server to the PC using file transfer protocol (FTP). When your source files are on the PC, they can be distributed anywhere in the PC namespace. Likewise, any files that are output from the PC cross compilers can be distributed anywhere in the PC namespace.
Usage Guidelines The TDS version of the TNS/R native C/C++ cross compiler produces object code that runs only on a TNS/R system in either the Guardian or the OSS environment. Source code that is compilable by the TNS/R native C and C++ compilers running on NonStop S-series system is also compilable by the native PC cross compiler, except for these differences: • The default target environment for the PC cross compiler is the Guardian environment.
TNS/E native object code that runs on TNS/E servers; TDS PC cross compiler produces TNS/R native object code that runs on TNS/R servers. You can invoke the cross compiler from the command line (DOS prompt): • If you are using the native C/C++ cross compiler named c89, version G06.14 and later. • If you are using the native C/C++ cross compiler named c99. The command-line input format is similar to that of c89 on the OSS platform.
For more details about EpTAL, see the pTAL Programmer’s Guide. COBOL85 Cross Compilers The native COBOL85 cross compilers are an option available with ETK and TDS, and separately as command-line cross compilers for the G06.14 and later RVUs.
language-specific menus, comment generation, and user customization. HP Extensions for Codewright: • Supports four project dictionaries (user, parameter, class, and system). Using templates and dictionaries, you can simplify source-code creation by supplying only arguments and directing TEC to build the code. • Provides language-specific programming support for C, C++, TAL, pTAL, and COBOL.
19 Running and Debugging C and C++ Programs Running Programs in the Guardian Environment When you run a C or C++ program, the NonStop OS creates a new process from the program file you specify. This new process passes through three phases of execution: 1. Program initialization: the C and C++ libraries and CRE perform startup tasks. 2. Program execution: the program controls the flow of execution. 3. Program termination: the C and C++ libraries and CRE perform shutdown tasks.
Running Programs in the OSS Environment To run a C or C++ program from the OSS environment, enter the program file name at the OSS shell prompt. You can also use the run command to run a process with HP specific attributes. For more details, see the run(1) reference page, available either online or in the Open System Services Shell and Utilities Reference Manual. Program Initialization Your program begins execution when the operating system transfers control to your program’s object code.
The three standard files for ANSI-model I/O are associated to physical files: • stdin denotes the physical file specified by the IN option of the RUN command. If you do not use the IN option, stdin denotes the command interpreter’s default input file, which is usually your home terminal. • stdout denotes the physical file specified by the OUT option of the RUN command. If you do not use the OUT option, stdout denotes the command interpreter’s default output file, which is usually your home terminal.
env is the environment array. Each element (except for the last) points to a null-terminated string containing the name and value of one environment parameter. The last element has the pointer value NULL. When declaring parameters to the function main(), note: • The parameters to main() are optional; you can declare no parameters, just argc and argv, or all three parameters. You cannot declare env alone.
• The destructors are invoked for global and static variables in C++. • The process is terminated with a certain completion code, depending on what caused termination. When your process returns from main() with no return value, your process completes with a completion code of 0, normal termination.
storage class static, which means that they retain their values throughout the execution of the entire program. Figure 2 Memory Models The size of the extended segment is the sum of the heap size you specify during compilation or binding and the sizes of all global and static aggregates. The physical limit of the extended segment is 127.5 MB; the practical limit depends on paging rates and disk space.
Two Data Models: 16-Bit and ILP32 This section applies to TNS C/C++ only. The data model determines the size of the type int. You cannot mix modules compiled with different data models; all modules in a program must be compiled for either the 16-bit data model or the ILP32 data model. Table 55 summarizes the characteristics of each data model.
The C compiler running in the OSS environment supports only the large-memory model and ILP32 data model. The memory model and data model selected determines the model-dependent library file that you bind into a program. For more details, see Chapter 14: Compiling, Binding, and Accelerating TNS C Programs, and Chapter 15: Compiling, Binding, and Accelerating TNS C++ Programs.
These subsections introduce some of the features of each debugger. Debug Debug provides machine-level process debugging; that is, it provides access to a process in terms of code and data addresses, hardware registers, and other machine-level quantities. To use Debug, you should have a thorough understanding of the HP NonStop architecture as described in the system description manual that corresponds to your NonStop system, such as the NonStop S-Series Server Description Manual.
the executable file using a linker or the strip utility. You can also use the SAVEABEND pragma to create a save file if your program terminates abnormally. For more details about enabling and using Visual Inspect, see the online help for Visual Inspect.
20 TNS C Compiler Messages This chapter presents the error and warning messages that can occur during the compilation of a C program using the TNS C compiler. Types of Compiler Messages The TNS C compiler scans the source code line by line and notifies you of an error or potential error by issuing an error or warning message: • An error message indicates an error that you must correct before C can successfully compile the source code.
5 number of actual and formal parameters in a macro are not matched, macro is not expanded Cause You specified a preprocessor #define macro with the wrong number of arguments. 6 line buffer overflow Cause Expansion of a #define macro caused the compiler’s line buffer to overflow. This error can occur if more than one lengthy macro appeared on a single input line. 7 file stack full Cause You exceeded the maximum depth of #include nesting; the compiler supports #include nesting to a maximum depth of 16.
Cause The compiler did not accept the expression preceding the period or arrow operator as a structure or pointer to a structure. This error can occur even for constructions that are accepted by other compilers. 13 member name missing Cause The compiler did not find an identifier following the period or arrow operator. 14 undefined member member-name Cause The indicated identifier was not a member of the structure or union to which the period or arrow operator referred.
20 invalid constant expression Cause The compiler encountered an expression that did not evaluate to a constant in a context that required a constant result. This error can occur if one of the operators not valid for constant expressions was present. 21 illegal use of aggregate Cause An identifier declared as a structure or union was encountered in an expression without being properly qualified by an aggregate reference.
Cause The context of the expression required an operand to be either arithmetic or a pointer. This error can occur for the logical OR and logical AND operators. 28 missing operand Cause During expression evaluation, the compiler encountered the end of an expression but not enough operands were available for evaluation. This error can occur if you improperly specified a binary operation.
of an expression that did not evaluate to a constant. This error might require some experimentation to determine its exact cause. 35 closing brace expected Cause During processing of an initializer list or a structure or union member declaration list, the compiler did not find a closing right brace. This error can occur if you specified too many elements in an initializer expression list, or if you improperly declared a structure member.
Cause The expression defining a case value did not evaluate to an int constant. 43 duplicate case value Cause The compiler encountered a case statement that defined a constant value already used in a previous case statement within the same switch statement. 44 continue not inside loop Cause The compiler detected a continue statement that was not within the scope of a while, do, or for loop. This error can occur due to an error in a preceding statement.
Cause The compiler did not find a statement label following the goto keyword. 51 label name conflict identifier Cause The indicated identifier, which appeared in a goto statement as a statement label, was already defined as an object within the scope of the current function. 52 invalid if expression Cause The expression following the if keyword was null (not present).
58 missing parenthesis Cause The compiler did not find a parentheses required by the syntax of the current statement (as in a while or for loop). This error can occur if you incorrectly specified the enclosed expression, causing the compiler to end the expression early. 59 invalid storage class Cause This error can occur for several reasons: • In processing external data or function definitions, the compiler encountered a storage class—such as auto or register—invalid for that declaration context.
65 invalid function definition Cause An attempt was made to define a function body when the compiler was not processing external definitions. This error can occur if a preceding error caused the compiler to “get out of phase” with respect to declarations in the source file. 66 invalid array limit expression Cause The expression defining the size of a subscript in an array declaration did not evaluate to a positive int constant.
Cause You declared an external item with attributes that conflict with a previous declaration. This error can occur if a function was used earlier, as an implicit int function, and was then declared as returning some other type of value. You must declare functions that return a value other than int before they are used so that the compiler is aware of the type of the function value.
80 invalid bit field Cause The number of bits specified for a bit field was invalid. Note that the compiler does not accept bit fields that are exactly the length of a machine word; you must declare these as ordinary int or unsigned objects. 81 preprocessor symbol loop Cause The current input line contained a reference to a preprocessor symbol that was defined with a circular definition or loop.
Cause The type of an argument in the function call disagrees with the type specified in the function prototype. 89 constant converted to required type Cause A constant in the function call did not have the type specified in the function prototype. The constant has been converted to the appropriate type. 90 invalid argument type specifier Cause The parameter type specifier within the function prototype is an invalid type specifier.
Cause The compiler encountered a function declaration or definition that does not use function-prototype syntax. Cause This warning occurs only when you have specified the STRICT pragma. 97 formal parameter was not declared: name Cause The compiler encountered a nonprototype function definition that does not define the type of one of its parameters. Consequently, that parameter defaults to type int. This warning occurs only when you have specified the STRICT pragma.
Cause A function definition declared more than 32 KB of automatic data. 104 constant converted to smaller type and significance lost Cause A constant was converted to a type that could not represent the value of the constant. 105 function declaration not in scope: func-name Cause The compiler encountered a reference to a function that does not have a function declaration in scope. This warning occurs only when you have specified the STRICT pragma.
112 alias name for external C routine expected Cause In a mixed-language program, the COBOL, FORTRAN, Pascal, or TAL procedure name is either illegal as a C identifier or conflicts with a predefined name in C. You must define an alternative procedure name using an external name. This error can also occur if the character string that defines the external procedure name is missing.
Cause A subsequent declaration or definition of a previously declared function specifies a different type for one of the parameters. 121 pragma directive specified but there is no main() function Cause You specified the RUNNABLE pragma in a program that contains no main function. 122 invalid object filename specified Cause You did not specify a valid file name for the object file in the compilation command. 123 specified heap size is too big Cause The value provided in the HEAP pragma is too large.
129 obsolete TAL declaration syntax - use prototype syntax Cause You used non-prototype syntax in a TAL interface declaration. 130 name is not a SQL variable Cause The C object you used in an embedded SQL string was not declared within an SQL Declare Section. 131 variable missing from SQL statement Cause The compiler encountered a colon (:) in an embedded SQL string, but the colon was not followed by a valid C identifier.
137 name is an obsolete feature Cause The specified feature is obsolete in this release of the C compiler. 139 arithmetic overflow/underflow detected in constant arithmetic Cause The resultant value of a constant expression exceeded the range of the object to which it was assigned. 143 filename has been truncated to file-name Cause The preprocessor encountered a file name longer than 8 characters in an #include directive and so truncated it to the specified name.
149 unknown pragma directive pragma Cause The compiler encountered an invalid pragma directive. This message is a warning message. 150 #error message-text-you-specify Cause The #error preprocessor directive allows you to force a compilation error and designate the text of the error message. This error message is printed as the message text of error 150.
use SEC. The abbreviation SE for either of the pragmas is not unique. If SE is specified, this error message occurs. 156 obsolete 'tal' keyword; use '_tal' instead Cause The C compiler encountered an interface declaration for a TAL procedure that uses the keyword tal. Replace the keyword tal with the keyword _tal. 157 only unqualified filenames allowed in #include with angle brackets Cause The C compiler encountered a qualified file name in a #include preprocessor directive with angle brackets.
163 macro expansion buffer overflow Cause During the macro expansion phase, the C compiler’s internal buffer experienced an overflow condition. Reduce the size of the macro text. 164 type is not defined or a comma is missing Cause The C compiler encountered a variable whose type is not defined, or the compiler encountered a situation where a comma is missing. In this example, if the type of the variable t is undefined, the error message is generated.
169 extra #endif Cause The compiler encountered an if section that contains a #endif preprocessing directive without a matching #if preprocessing directive to begin the if section. 170 character format in SQL directive was set twice; default is used Cause The default structure for a C string that is used as an SQL host variable is a null terminated array of characters. The char_as_array option of the SQL pragma directs the compiler to pass strings to SQL as an array of characters with no null terminator.
Cause Only one storage class specifier is allowed in each of these: • a simple variable declaration • an array declaration • a pointer declaration • a function definition or a function prototype. The compiler encountered one of these entities that contains two storage class specifiers. 176 two type qualifiers exist in the same declaration Cause A simple variable, an array, a pointer variable, and the return type of a function can have only one type.
181 _lowmem can only exist with extern/static/typedef keywords in a declaration Cause The storage class specifier _lowmem can only exist in the same declaration with the storage class specifier extern or static. In addition, the _lowmem storage class specifier can be used in a typedef.
For example, here is a structure without a tag: struct { ... }; /* structure with no tag */ Here is a structure with the tag point: struct point { ... }; /* structure with tag */ Here is a typedef declaration that has no name: typedef struct { ... }; /* typedef with no name */ Here is a typedef declaration with a name: typedef struct { ...
Cause Only variable functions (functions with the _variable attribute) can be converted to extensible functions. The number specified in the _extensible parameter count argument must be in the range of 1 through 15. 198 illegal number of parameters count/size Cause There are either more than 252 parameters specified for a C regular function or more than 128 parameter words specified for variable or extensible function.
Cause The address of an object that resides in code space is taken. Use of this address is valid only within the same code segment as the object. 208 string will be allocated within data space in this context, use pragma ENV LIBRARY/LIBSPACE Cause A pointer to the code space has been initialized with the address of a string that has been allocated in the data space. Pragma ENV LIBRARY or ENV LIBSPACE must be used to ensure allocation of the string in the code space.
Cause An address pointing to the code space is passed to a runtime routine under the small-memory model. This address is not valid in the code segment the runtime routine resides in. Pragmas CSADDR and NOINLINE must be used to ensure correct behavior. 216 main function not allowed under ENV EMBEDDED/LIBSPACE Cause The existence of the function main() is not meaningful under pragma ENV EMBEDDED or ENV LIBRARY.
int main(int argc, char *argv[]) { int argc; /* This line causes the warning } */ 226 invalid value for enum literal literal-name Cause Enumerated types must be compatible with the type int. Therefore, the value assigned to an enumerated type cannot exceed the range of integer for a given memory model. For example, an int in the large-memory model is 16 bits signed, so an enumerated value cannot exceed 32767.
236 Unable to read source text Cause The compiler cannot read the source text. 249 INTERNAL COMPILER ERROR Cause The compiler has detected an internal inconsistency. Contact your HP representative. 250 BINSERV or SYMSERV stopped Cause The compiler cannot communicate with the processes BINSERV or SYMSERV. 257 Compiler's heap space is totally full. Try breaking your program into smaller modules. Cause The compiler cannot compile the program unless you break it into smaller modules.
Cause The compiler requires that a tag specified in a FIELDALIGN pragma exist. Check to ensure that the correct tag was specified. Delete the FIELDALIGN pragma if it is not used. 295 0 bitfield not allowed under fieldalign shared2 and shared8 Cause An unnamed bit field is not allowed in a structure or union tag with the FIELDALIGN SHARED2 or SHARED8 pragma. 296 Data block too long, truncated to 126 characters Cause The maximum length of a global variable name is 126 characters.
308 controlling expression for iteration must have scalar type Cause The controlling expression for iteration is not a scalar type. 309 Passing unknown pragma directive Cause The compiler cannot identify the pragma directive. Check the pragma to ensure that it is a valid directive. 310 Invalid macro name Cause An invalid macro name is defined. 311 hexadecimal constant must have at least one digit Cause A constant beginning with "0X" or "0x" has been defined without any following digits.
320 mapinclude directive string text duplicated and ignored Cause A mapinclude directive was previously specified for this string. 321 variable sqlcode should be type short Cause The compiler requires the sqlcode variable to be declared type short. You have declared sqlcode to be a type other than type short. 322 Internal error: nested block level exceeds compiler limit; block ignored. Cause The C compiler supports a maximum of 255 block nesting levels.
21 Run-Time Messages This chapter presents the error messages that can occur during the execution of C and C++ programs. The Common Run-Time Environment (CRE) emits these messages. For more details on the error messages and the CRE, see the Common Run-Time Environment (CRE) Programmer’s Guide. Trap and Signal Messages The TNS CRE reports the messages in this subsection if a trap occurs and your program has neither disabled traps nor enabled its own trap handler.
5 Stack overflow Cause A stack overflow fault occurs if: • An attempt was made to execute a procedure or subprocedure whose local or sublocal data area extends into the upper 32K of the user data area. • There was not enough remaining virtual data space for an system procedure to execute. • The native environment exceeded the maximum stack space available. The amount of virtual data space available is G[0] through G[32767].
Cause CRE or run-time library data is invalid. Effect The CRE invokes PROCESS_STOP_, specifying the ABEND variant and the text “Corrupted environment.” Recovery In the TNS environment, the program might have written data in the upper 32K words of the user data segment. The upper 32K words are reserved for TNS CRE and run-time library data. In the native environment, the run-time environment has been corrupted. You may have written data over run-time data structures. Check the program’s logic.
Cause The CRE backup process received an operating system message that it had become the primary process but it had not yet received all of its initial checkpoint information from its predecessor primary process. Effect The CRE invokes PROCESS_STOP_, specifying the ABEND variant and the text “Premature takeover.” Recovery If the takeover occurred because of faulty program logic, correct the program’s logic.
18 Extended Stack Overflow Cause A module could not obtain sufficient extended stack space for its local data. Effect Program behavior is language and application dependent. Recovery Increase the extended stack’s size. See the language manual for the routine that caused the extended stack overflow for details on increasing the size of the extended stack. 19 Incompatible runtime libraries – Library1 vs.
Cause The CRE could not obtain the name of the program file from the operating system. Effect The CRE terminates the program. Recovery Consult your system administrator. 23 Cannot determine filename ( error ) program_name.logical_name Cause The CRE could not determine the physical file name associated with program_name.logical_name. Effect The CRE terminates the program. Recovery Correct the program_name.logical_name and rerun your program.
26 Invalid PARAM value text ( error ) PARAM name 'value' Cause A PARAM specifies a value that is not defined by the CRE. For example, the value for a DEBUG PARAM must be either ON or OFF: PARAM DEBUG [ ON ] [ OFF ] The CRE reports this error if a DEBUG PARAM has a value other than ON or OFF. error, if present, is a file-system error. Effect The CRE terminates the program. Recovery Modify the PARAM text and rerun your program. For more details on using ASSIGNs, see the TACL Reference Manual.
Effect The CRE terminates the program. Recovery Use a compiler and run-time library that are compatible. You might need to consult your system administrator. Ensure that the application is linked to the correct libraries, in the correct order, for the functions or features used.
Recovery In the TNS environment, the program might have written data in the upper 32K words of the user data segment or in the extended segment. The upper 32K words of the user data area are reserved for CRE and run-time library data. In a small-memory model, the heap is allocated in the lower 32K words of the user data segment. In a large memory model, the heap is allocated in an extended memory segment. Check the program’s logic.
Cause The request you made is not compatible with the heap that you referenced. Effect Program behavior is language and application dependent. Recovery Consult your system administrator. 37 Mark address or space corrupt Cause An address passed as a heap marker does not point to a mark. Effect Program behavior is language and application dependent. Recovery In the TNS environment, ensure that the program passed the correct address of a mark. If it did, the heap might be corrupted. Check the program’s logic.
Math Function Messages Run-time libraries report the messages in this subsection if an error is detected in a math function. 41 Range fault Cause An arithmetic overflow or underflow occurred while evaluating an arithmetic function. Effect Program behavior is language and application dependent. Recovery Modify the program to pass values to the arithmetic functions that do not cause overflow. 42 Arccos domain fault Cause The parameter passed to the arccos function was not in the range: -1.0 < parameter < 1.
Cause The parameter passed to a logarithm function was less than or equal to zero. The parameter to a logarithm function must be greater than zero. Effect Program behavior is language and application dependent. Recovery Modify the program to pass a valid value to the logarithm function. 47 Modulo function domain fault Cause The value of the second parameter to a modulo function was zero. The second parameter to a modulo function must be nonzero.
55 Missing or invalid parameter Cause A required parameter is missing or too many parameters were passed. Effect Program behavior depends on the function that was called and the language in which it is written. Recovery Correct the program to pass a valid parameter. 56 Invalid parameter value Cause The value passed as a procedure parameter was invalid. Effect Program behavior depends on the function that was called and the language in which it is written.
Effect The CRE can report this error when it closes your input file. All other instances are language and application dependent. Recovery If the error was caused by a read request from your program, correct your program. You might need to ensure that your program handles conditions that are beyond your control such as losing a path to the device. Also refer to error handling in this manual and in the language manual for the routine in your program that detected the error.
62 Invalid GUARDIAN file number Cause A value that is expected to be a Guardian file number is not the number of an open file. Effect Program behavior is language and application dependent. Recovery Consult your system administrator. 63 Undefined shared file Cause A parameter was not the number of a shared (standard) file where one was expected. Effect Program behavior is language and application dependent. Recovery Consult your system administrator.
Recovery Consult your system administrator. 67 Access mode not accepted Cause The value of the access parameter to an open operation was not valid in the context in which it was used. For example, it is invalid to open a spool file for input. Effect Program behavior is language and application dependent. Recovery Consult your system administrator. 68 Nowait value not accepted Cause The value of the no_wait parameter to an open operation was not valid in the context in which it was used.
71 Inconsistent attribute value Cause A routine requested a connection to a standard file that was already open, and the attributes of the new open request conflict with the attributes specified when the file was first opened. Effect Program behavior is language and application dependent. Recovery If your program supplied the attribute values, correct and rerun your program. Otherwise, consult your system administrator. 75 Cannot obtain buffer space Cause A routine was not able to obtain buffer space.
Effect Program behavior is language and application dependent. Recovery For more details, see the Guardian Procedure Calls Reference Manual. 79 OpenEdit failed ( error ) Cause A call to OPENEDIT_ failed. error, if present, is the error returned by OPENEDIT_. A negative number is a format error. A positive number is a file-system error number. Effect Program behavior is language and application dependent. Recovery For more details, see the Guardian Procedure Calls Reference Manual.
83 Operation incompatible with file type or status (error) Cause The program attempted an operation on a file whose type or current status is unsuitable for execution of that operation. For example, a COBOL program calls a file manipulation utility for a file that is using Fast I/O. error, if present, is as file-system error number. Effect Program behavior is language and application dependent. Recovery Change the program so that it does not attempt the operation on an unsuitable file.
Effect The run-time library terminates your program. Recovery Make sure the only defined errno in a program is the one defined in the native CRE shared run-time library. 276 Ambiguity in application of environ Cause environ is defined in the user’s object file. The native CRE reports this error if environ has been defined in the object file, and it is not the same environ defined by the native CRE shared run-time library instance data item environ. Effect The run-time library terminates your program.
22 Handling TNS Data Alignment Programs compiled with the TNS instruction set must follow the even-byte data alignment rules of TNS compilers. Certain violations of these programming rules might lead to run-time errors. This section describes these violations and explains how to avoid them and how to diagnose them at run time. On TNS systems, a word is 16 bits.
NOTE: HP recommends that the SCF MISALIGNLOG attribute be left ON (its default setting) so that any process that is subject to rounding of misaligned addresses will generate log entries, facilitating diagnosis and repair of the code. Only if the volume of misalignment events becomes burdensome should this attribute be turned OFF. The tracing facility traces exceptions that would be rounded down on a NonStop system running any release version update (RVU) earlier than G06.17.
Table 58: TNS Misalignment Handling Methods lists and describes the possible settings for TNSMISALIGN. Each setting represents a different misalignment handling method. For more details about TNSMISALIGN, see the SCF Reference Manual for the Kernel Subsystem. Table 58 TNS Misalignment Handling Methods Method Description ROUND (default)* After rounding down a misaligned address, the system proceeds to access the address, as in G06.16 and earlier RVUs.
a. b. c. 2. Dereferencing a pointer-valued field of a structure when the structure pointer is null Checking for a null pointer after some but not all pointer references, instead of before all pointer references (see Example 10).
5.
node = listhead; while (*node->kind == 4 /* used too soon */ && node != NULL) { ... node = node->next; } To this: struct listnode { int *kind; ... struct listnode *next; }; struct listnode *listhead, *node; node = listhead; while (node != NULL && *node->kind == 4) { ...
To this: lth = (name[0] << 8) | name[1]; Example 14 C/C++ Structure With Implicit Filler Bytes (Item 5) struct elem { char a; /* offset 0 */ /* implicit filler byte added before b */ short b; /* offset 2 */ char c; /* offset 4 */ /* implicit trailing filler byte added after c */ /* with filler bytes, total size is 6 bytes */ }; struct elem table[10]; /* each table element takes 6 bytes, not 4 */ Example 15 C/C++ External Structure With Misaligned Parts (Item 8) Change this: /* An interface as struct { sho
name += 2; lth -= 2; } if (lth > 0) checksum += *name << 8; 390 Handling TNS Data Alignment
23 LP64 Data Model Support for the LP64 Data Model In H06.24 and later H-series RVUs and in J06.13 and later J-series RVUs, OSS supports a new LP64 data model, along with the existing default ILP32 data model. The LP64 data model is used to create 64-bit OSS user processes. The C/C++ compiler allows the user to compile an OSS application in ILP32 as well as in LP64 mode. In the ILP32 data model, the data types: int, long, and pointers are 32-bit in size.
SYSTYPE GUARDIAN –Wlp64 does not support the following c89 options : -Wsql -Wsystype=guardian -Wversion2 –Wlp64 does not support the following c99 options : -Wsystype=guardian Pointer Modifiers The pointer modifiers specify the size of a pointer. The _ptr64 modifier is used to declare a 64-bit pointer and the _ptr32 modifier is used to declare a 32-bit pointer. These modifiers may be used in both ILP32 and LP64 modes.
Data Model Pragmas #pragma p32_shared and #pragma p64_shared These pragmas apply to class, struct, or union definitions. For C, they affect pointers declared as fields. For C++, they apply to pointers declared (implicitly or explicitly) as members, to function parameters (including the implicit “this” parameter) and to any pointers used in the member function definitions. It does not allow the components whose layout or size are not data model invariant.
Data Model Macros Table 60 lists predefined macros that are set based on the data model specified on the compiler command-line. They are used when writing source code that is intended to be compiled in both data models. Table 60 Data Model Macros Macro What it defines _ILP32 Defined automatically, when the data model specified (explicitly or implicitly) is ILP32. Its value is 1. _LP64 Defined automatically, when the data model specified is LP64. Its value is 1. New Intrinsics
Changed Features pragma shared2/shared8 When pragma shared2/shared8 is compiled with the LP64 data model, the compiler issues an error for components whose type is long or whose type is a pointer (without an explicit size modifier). These components are grandfathered for the ILP32 mode.
A HP C Implementation-Defined Behavior Implementation-Defined Behavior of Native C The ISO standard for C allows implementations to vary in specific instances. This subsection describes the implementation-defined behavior of native C. This subsection corresponds to Annex G.3 of the ISO C standard or Appendix F of the ANSI C standard. G.3.
• The C locale is used to convert multibyte characters into corresponding wide character codes. The value of the wide character is equal to the value of the first byte in the multibyte sequence (whose value is taken as an unsigned value). • A plain char has the same range of values as unsigned char. G.3.5 Integers Converting an integer to a shorter signed integer causes a representation change by discarding the high order bits.
G.3.8 Registers The register storage class specifier cannot be used with structure or array declarations. A register variable may be changed to a nonregister type or a nonregister type changed to register by the optimizer. G.3.9 Structures, Unions, Enumerations, and Bit Fields A union is considered as a block of memory the size of the union.
For the descriptions of the pragmas supported by native C, see Chapter 13: Compiler Pragmas. When the date or time of translation is not available, the definitions of the __DATE__ and __TIME__ macros are January 1, 1970 and 00:00:00, respectively. G.3.14 Library Functions OL is the null pointer constant to which the macro NULL expands.
The same file can be opened simultaneously multiple times, as long as it is not for writing. The effect of the remove() function on an open file is that it returns a nonzero value and does not remove the file. If a file with a new name already exists prior to a call to the rename() function, it returns a nonzero value without renaming the file. The output for %p conversion in the fprintf() function formats the value of a pointer to a void argument using the format specified by the x conversion code.
param_setting is the string that will be returned when getenv is called with param_name as its parameter. system() The string passed to the system() function is either a NULL string or an ASCII string that can be processed by the command processor. strerror() The format of the error message returned by the strerror() function is an ASCII string.
Table 62 errno Values and Corresponding Messages (continued) errno Messages EPIPE Broken pipe or no reader on socket EDOM Argument out of function's domain ERANGE Value out of range EDEADLK Deadlock condition ENOLCK No record locks available ENODATA No data sent or received ENOSYS Function not implemented EWOULDBLOCK Operation would block EINPROGRESS Operation now in progress EALREADY Operation already in progress ENOTSOCK Socket operation on non-socket EDESTADDRREQ Destination addr
Table 62 errno Values and Corresponding Messages (continued) errno Messages ENOTEMPTY Directory not empty EHAVEOOB Out-of-band data available EBADSYS Invalid socket call EBADFILE File type not supported EBADCF Not a C file ENOIMEM Insufficient internal memory EBADDATA Invalid data in buffer ENOREPLY No reply in buffer EPARTIAL Partial buffer received ESPIERR Interface error from SP I EVERSION Version mismatch EXDRDECODE XDR encoding error EXDRENCODE XDR decoding error G.
Multibyte Characters • The basic difficulty in an Asian environment is the huge number of ideograms that are needed for I/0, for example Chinese characters. To work within the constraints of usual computer architectures, these ideograms are encoded as sequences of bytes. The associated operating systems, application programs, and terminals understand these byte sequences as individual ideograms.
Alignment Issues Native C and C++ considers objects of integral types to exist only on word boundaries. Consequently, it is invalid to use an odd-byte address to access such an object. On TNS/R or TNS/E systems, the results of using an integer type extended pointer containing an odd-byte address are undefined. The code might continue executing or trap. Therefore, it is important for you to ensure that all extended pointers contain addresses that are even except for pointers to char.
• An internal identifier or macro name can have 63 significant characters. • An external identifier can have 31 significant initial characters. • A single translation unit can have at least 4095 external identifiers. • A block can have at least 511 identifiers declared with block scope. • A single translation unit can have at least 127 macro identifiers defined simultaneously. • A macro definition can have at least 127 parameters and a macro invocation at least 31 arguments.
and the NOWARN pragma disables the compiler from generating all or a selected set of warning messages. The compiler defaults to WARN, which enables all warning messages. G.3.2 Environment No library facilities are available to a freestanding program. In a freestanding environment, program termination is: • The program termination phase of execution begins when a program returns from the function main, calls the exit() library function, or calls the terminate_program() library function.
G.3.4 Characters There are no source and execution characters that are not explicitly specified by the ISO/ANSI C Standard. These are the escape sequence values produced for the listed sequences: Sequence Value \a 007 alert (bell) \b 008 backspace \f 012 form feed \n 010 new line \r 013 carriage return \t 009 horizontal tab \v 011 vertical tab The HP NonStop OS handles the shift states used for the encoding of multi-byte characters; therefore, it is not applicable to list them here.
Designation Size (bits) Range signed long 32 -2,147,483,648 to 2,147,483,647 unsigned long 32 0 to 4,294,967,295 The result of converting an integer to a shorter signed integer is undefined and may result in arithmetic overflow. The result of converting an unsigned integer to a signed integer of equal length is undefined and may result in arithmetic overflow. The result of bitwise operations on signed integers is the same as the result for unsigned integers, except for the right shift.
For the padding and alignment of members of structures, all fields are aligned on 16-bit boundaries, except characters that are aligned on byte boundaries. The equivalent type for a plain int bit field is: • signed int bit field • unsigned int bit field The order of allocation of bit fields within an int is high order to low order. A bit field cannot straddle a storage-unit boundary. The int integer type has been chosen to represent the values of an enumeration type. G.3.
For information on how to recognize the diagnostic that is printed by the assert() function and information on the termination behavior of the assert() function, see the assert() function in the Guardian TNS C Library Calls Reference Manual.
If a file with a new name already exists prior to a call to the rename() function, it returns a nonzero value without renaming the file. The output for %p conversion in the fprintf() function formats the value of a pointer to a void argument using the format specified by the x conversion code. The input for %p conversion in the fscanf() function matches an unsigned hexadecimal integer that uses the lowercase letters a through f to represent the digits 10 through 15.
PARAM param_name param_setting param_name is the run-time environment parameter name param_setting is the string that will be returned when getenv is called with param_name as its parameter. system() The string passed to the system() function is either a NULL string or an ASCII string that can be processed by the command processor. strerror() The format of the error message returned by the strerror() function is an ASCII string.
Table 63 errno Values and Corresponding Messages (continued) 414 errno Message ENOSPC No space left on device ESPIPE Illegal seek EROFS Read only file system EMLINK Too many links EPIPE Broken pipe or no reader on socket EDOM Argument out of function's domain ERANGE Value out of range EDEADLK Deadlock condition ENOLCK No record locks available ENODATA No data sent or received ENOSYS Function not implemented EWOULDBLOCK Operation would block EINPROGRESS Operation now in progress
Table 63 errno Values and Corresponding Messages (continued) errno Message ECONNREFUSED Connection refused EHOSTDOWN Host is down EHOSTUNREACH No route to host ENAMETOOLONG File name too long ENOTEMPTY Directory not empty EHAVEOOB Out-of-band data available EBADSYS Invalid socket call EBADFILE File type not supported EBADCF Not a C file ENOIMEM Insufficient internal memory EBADDATA Invalid data in buffer ENOREPLY No reply in buffer EPARTIAL Partial buffer received ESPIERR Interf
returns the identifier of the default character set. The Guardian Procedure Calls Reference Manual describes this system procedure in detail. The internal representation of the characters of these languages is HP internal and might not conform to any ISO standard. HP can choose to change this internal representation at any time. Multibyte Characters • The basic difficulty in an Asian environment is the huge number of ideograms that are needed for I/0, for example Chinese characters.
MB_CUR_MAX Macro • The MB_CUR_MAX macro specifies the maximum number of bytes used in representing a multibyte character in the current locale (category LC_CTYPE). The MB_CUR_MAX macro is defined in the header stdlibh as: #define MB_CUR_MAX 2 Conversion Functions • The five run-time library functions that manage multibyte characters and wide characters are: Function Description mblen() Determines the length of a multibyte character. mbtowc() Converts a multibyte character to a wide character.
B TNS C++ Implementation-Defined Behavior HP Specific Features for OSS and Guardian Environments The HP specific features discussed in this subsection are applicable to the Guardian environment on all current systems and to the OSS environment on NonStop S-series systems. Length of Identifiers Cfront generates identifiers up to a maximum of 230 characters except for global variable names which can be up to a maximum of 127 characters.
In the Guardian environment, Cprep truncates the UNIX named iostream header file from iostream.h to iostreah to comply with the Guardian file naming conventions. However, for portability, you can use iostream.h. Interfacing to the Standard C Run-Time Library To declare a standard C run-time library function, use the #include preprocessor directive to include the name of the header file that contains the function prototype for the particular function. For example: #include
To call a C++ function from another language, call the C++ function as if it were a C function but use the encoded name form. Get this encoded name form from the C source file that is created by Cfront. If you want to call a function written in another language from a C or C++ program, your program must have a C main function. You do not need to put the extern C construct around #include because the extern C construct has already been added to the header file for use by C++.
C ASCII Character Set Overview The two tables of the ASCII character set contained in this appendix use these column headings: Ord. Character’s ordinal number in the ASCII character set Octal Character’s octal representation (with left and right bytes) Hex. Character’s hexadecimal representation Dec.
Table 64 ASCII Character Set in Numeric Order (continued) Octal Ord. Left Right Hex. Dec. Char.
Table 64 ASCII Character Set in Numeric Order (continued) Octal Ord. Left Right Hex. Dec. Char.
Table 64 ASCII Character Set in Numeric Order (continued) Octal Ord. Left Right Hex. Dec. Char.
Table 64 ASCII Character Set in Numeric Order (continued) Octal Ord. Left Right Hex. Dec. Char.
Table 65 ASCII Character Set in Alphabetic Order (continued) Octal Char Meaning Ord Left Right Hex. Dec.
Table 65 ASCII Character Set in Alphabetic Order (continued) Octal Char Meaning Ord Left Right Hex. Dec.
Table 65 ASCII Character Set in Alphabetic Order (continued) Octal Char Meaning Ord Left Right Hex. Dec.
Table 65 ASCII Character Set in Alphabetic Order (continued) Octal Char Meaning Ord Left Right Hex. Dec.
D Data Type Correspondence Table 66: Integer Types, Part 1 contains the return value size generated by HP language compilers for each data type. Use this information when you need to specify values with the Accelerator ReturnValSize option. These tables are also useful if your programs use data from files created by programs in another language, or your programs pass parameters to programs written in callable languages.
Table 66 Integer Types, Part 1 (continued) TAL and pTAL 8-Bit Integer 16-Bit Integer 32-Bit Integer STRING INT INT(16) UNSIGNED(16) INT(32) 1 2 UNSIGNED(8) Return Value Size 1 (Words) 1 2 3 4 Unsigned Integer. Index Data Item is a 16-bit integer in COBOL 74 and a 32-bit integer in HP COBOL85. HP COBOL85 only. INTEGER is normally equivalent to INTEGER*2. The INTEGER*4 and INTEGER*8 compiler directives redefine INTEGER.
Table 68 Floating, Fixed, and Complex Types (continued) TAL and pTAL 32-Bit Floating 64-Bit Floating 64-Bit Fixed Point 64-Bit Complex REAL REAL(64) FIXED(s), -19 < s < 19 -- 4 4 4 REAL(32) Return Value Size (Words) 2 Table 69 Character Types Character Character String Variable-Length Character String C-series BASIC STRING STRING -- C and C++ signed char pointer to char struct { int len; char val [n] }; Alphabetic Alphabetic Numeric DISPLAY Numeric DISPLAY Alphanumeric-Edited
Table 70 Structured, Logical, Set, and File Types (continued) Byte-Addressed Structure Word-Addressed Structure Logical (true or Boolean false) Set File TAL and pTAL Byte-addressed standard STRUCT pointer Word-addressed standard STRUCT pointer -- -- -- -- Return Value Size (Words) 1 or 2, depends on 1 or 2, depends on 1 or 2, declared pointer declared pointer size depends on size compiler directive 1 1 1 1 LOGICAL is normally defined as 2 bytes.
E Features and Keywords of Version 2 Native C++ Features Supported in VERSION2 These features are accepted in the VERSION2 dialect of native C++. These features are not in the The Annotated C++ Reference Manual (Ellis and Stroustrup) but are in the X3J16/WG21 Working Paper [The relevant sections of the WP are cited inside brackets]: • The dependent statement of an if, while, do-while, or for is considered to be a scope, and the restriction on having such a dependent statement be a declaration is removed.
• mutable is accepted on nonstatic data member declarations. [7.1.1 (9) Storage class specifiers] • Namespaces are implemented, including using declarations and directives. Access declarations are broadened to match the corresponding using declarations. [7.3 Namespaces] • Explicit instantiation of templates is implemented. [14.7.2 Explicit instantiation] • The typename keyword is recognized. [7.1.5.3 Elaborated type specifiers] • explicit is accepted to declare nonconverting constructors. [7.1.
• reinterpret_cast does not allow casting a pointer to member of one class to a pointer to member of another class if the classes are unrelated. [5.2.10 Reinterpret cast] • Explicit qualification of template functions is not implemented. [14.6 Name resolution] • In a reference of the form f()->g(), with g a static member function, f() is not evaluated. This is as required by the ARM. The WP, however, requires that f() be evaluated. [9.
Example class A { virtual int foo (); // foo not defined within its class }; // A's virtual function table will be defined within the // module that contains the definition of A::foo. class B{ virtual int foo() {return 1;} }; // all of B's virtual functions are defined within // B's definition, so each module that contains B also // contains a definition for B's virtual function table.
F MIGRATION_CHECK Messages Table 73 lists the warning messages emitted by the native C++ compiler when the pragmas VERSION2 and MIGRATION_CHECK are specified in the RUN command for the compiler. Messages listed here are current at time of publication; see the appropriate VERSION2 headers online for current messages on your system. Using MIGRATION_CHECK causes the compiler to examine the source file to find instances of functions from the VERSION2 C++ library that are not supported in the VERSION3 library.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name Warnings Displayed Notes supported in version 3 library. 9. Operator& is defined as 'bitset bitset::operator&(const bitset)' in version 3 library. 10. Operator| is defined as 'bitset bitset::operator|(const bitset)' in version 3 library. 11. Operator^ is defined as 'bitset bitset::operator^(const bitset) in version 3 library.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name Warnings Displayed Notes 4. 'size_type length' is not supported in version 3. 4. In Version 3, the equivalent is size_type _Mysize. 5. 'map_pointer map' is not 5. Version 3 type and supported in version 3. variables are: Mapptr Map. 6. 'size_type map_size' is not supported in version 3. 6. size_type _Mapsize in Version 3. 7. 'void allocate_at_begin()' 7. Equivalents not defined. is not supported in version 3. 8.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name Warnings Displayed Notes 18. 'void insert_aux2 (iterator position, const T* first, const T* last)' is not supported in version 3. 18. No equivalent function defined in Version 3. 19. 'deque (const T* first, const T* last)' is not supported in version 3. 19. No equivalent constructor is defined in Version 3. 20. 'deque (const T* first, 20. No equivalent constructor const T* last, const is defined in Version 3.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name 3 4 Warnings Displayed Notes Ifstream 1. 'ifstream(int fd, char* p, int l)' is not supported in version 3.2. 'class fstreambase' is not supported in version3. 1. Equivalent class in version 3 is 'basic_ifstream' type defined to 'ifstream'.2. No equivalent constructor is Version 3. ofstream 1. 'ofstream(int fd, char* p, int l)' is not supported in version 3. 1.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. 20 Class/Member Function Name Warnings Displayed template class pointer_to_binary_function Notes No warning issued. iomanip/iomanip.h: VERSION3 header file 1 class SMANIP None. No equivalent class is defined in Version 3. 2 class SAPP 1. 'class SAPP' is not supported in Version 3. No equivalent class is defined in Version 3. 3 class IMANIP 2. 'class IMANIP' is not supported in Version 3.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name 3 class istream Warnings Displayed Notes 10. 'class istream' is defined 10. Equivalent class inside namespace std in 'basic_istream' is defined in version 3. file -istream type defined to 'istream'. 11. 'istream& 11. No equivalent function is rs_complicated(unsigned defined in version 3. char& c)' is not supported in version 3. 12. 'istream& rs_complicated(char& c)' is not supported in version 3. 12.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name 1 Struct input_iterator 1. 'struct input_iterator' is not 1. No equivalent structure is supported in version 3. defined in Version 3. 2 struct output_iterator 2. 'struct output_iterator' is not supported in version 3. 2. Equivalent structure '_Outit' is defined in xutility. 3 Struct forward_iterator 3. 'struct forwardt_iterator' is not supported in version 3. 3. No equivalent structure is defined in Version 3.
Table 73 MIGRATION_CHECK Warning Messages (continued) No.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name Warnings Displayed Notes _RW_is_integer)' is not supported in version 3. 12. 'void insert_aux (iterator 12. 'No equivalent function position, size_type n, const in Version 3. T& x)' is not supported in version 3. 13. 'void insert_aux (iterator 13. 'No equivalent function position, InputIterator first, in Version 3. InputIterator last, _RW_is_not_integer)' is not supported in version 3. 14. 'void insert_aux (iterator 14.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name Warnings Displayed Notes 26. 'size_type length' is not 26. 'No equivalent function supported in version 3. in Version 3. 2 struct list_node (inner Structure) 27. struct list_node not supported in version 3. 27. Equivalent 'struct _Node' is defined in version 3. 3 struct list_node_buffer (inner 28. struct list_node_buffer structure) not supported in version 3. 28. Equivalent 'struct _Node' is defined in Version 3.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name 5 class allocator_interface Warnings Displayed Notes 1. 'class allocator_interface' 5. Equivalent classes are is not supported in version 3 defined in Version 3. library. 2. 'allocator_type alloc_' is not supported in Version 3. 3. 'inline void allocator_interface:: construct(pointer p, const T& val)' is not supported in Version 3. 4.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name 1 class queue Warnings Displayed Notes 1. Class queue : Template Mismatch Version 2 library: template . Version 3 library: template. 2 class priority_queue 2.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name Warnings Displayed Notes None. Equivalent implementation of rwexcept is found in exception in Version 3. None. Equivalent implementation of rwnew is found in new in Version 3. rwnew: VERSION2 header file 1 class RWSTDExport bad_alloc rwstdex: VERSION2 header file 1. class RWSTDExport logic_error 2. class RWSTDExport domain_error Version 3 implements all these classes in file stdexcept. No warning messages issued.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name Warnings Displayed Notes None. Equivalent implementation of stdexcept2 is found in exception in Version 3. stdexcept2: VERSION2 header file 1 class exception stdiostream: VERSION3 header file 1 class stdiobuf 1. 'class stdiobuf' is defined Class stdiobuf extends inside namespace std in streambuf. class version 3. 'basic_filebuf' is typedefined as stdiobuf in Version 3.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name Warnings Displayed 9 class RWSTDHuge string_ref 9. 'class RWSTDHuge string_ref' is not supported in version 3. 10 class RWSTDHuge basic_string Notes 10. size_type getCapac() const' is not supported in version 3. 11. 'void clobber (size_type)' is not supported in version 3. 12. 'void cow()' is not supported in version 3. 13. 'void cow(size_type nc)' is not supported in version 3. 14.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. 5 Class/Member Function Name class strstream string_char_traits Warnings Displayed Notes 8. 'super class strstreambase' is not supported in version 3 library. 8. Not supported in Version 3. 9. 'class strstream' is defined 9. Equivalent 'class strstream' in namespace std in version is defined in strstream in 3. Version 3. 10. 'super class strstreambase' is not supported in version 3 library. 10. Not supported in Version 3.
Table 73 MIGRATION_CHECK Warning Messages (continued) No. Class/Member Function Name Warnings Displayed Notes 8. 'void insert_aux2(iterator 8. No equivalent function is position, InputIterator first, defined in Version 3. InputIterator last)' is not supported in version 3. 9. 'void insert_aux2(iterator position, const_iterator first, const_iterator last)' is not supported in version 3. 9. No equivalent function is defined in Version 3. 10. 'void destroy(iterator 10.
Table 73 MIGRATION_CHECK Warning Messages (continued) Class/Member Function Name No. Warnings Displayed Notes 5. 'unsigned int offset' is not 5. Equivalent variable not supported in Version 3. supported. 5 class const_iterator 1. 'const_iterator (unsigned 1. No equivalent constructor int* x, unsigned int y)' is not in Version 3. supported in version 3. 2. 'void bump_up ()' is not supported in version 3. 2. No equivalent function in Version 3. 1. 'void bump_down ()' is not supported in version 3. 3.
G c99 Selected Features (C99LITE) This appendix summarizes the subset of features from the 1999 update to the ISO/IEC standard for C (ISO/IEC 9899:1999, also known as c99) that are supported by the HP C compiler on systems running H06.08 and later H-series RVUs and J06.03 and later J-series RVUs.
Digraph Characters Digraph characters (two-character sequences that represent a single character) can be used to represent the characters shown in the following table: Character Equivalent Digraph [ <: ] :> { <% } %> # %: ## %:%: The digraphs enable you to enter characters that are not allowed in certain rare circumstances. [6.4.6, Punctuators] Example iarr<:10:> is equivalent to iarr[10] Comments The characters // can be used to introduce a comment.
The components of div_t, quot and rem, are initialized to 2 and -1, respectively. Previously, you would initialize the struct components as follows: typedef struct div_t { int quot; int rem; } div_t; div_t answer = {2, -1}; Nonconstant Aggregate Component Initializers The initializer expression for an automatic composite variable can contain nonconstant subexpressions. [6.7.
Example #define debug (...) fprintf (stderr, __VA_ARGS__) // The ellipsis (...
H c99 Full Support The TNS, TNS/R, and TNS/E Compilers all conform to the 1989 ANSI C Standard. The C Standard itself was updated in 1999 and is commonly referred to as “c99”. For H06.08 and later H-series RVUs and J06.03 and later J-series RVUs, the TNS/E C Compiler and TNS/E C Standard library support a selected subset of new features that were added by the 1999 standard. This subset is available when you use the C99LITE pragma and are described in “c99 Selected Features (C99LITE)” (page 457). For H06.
For more information about the c99 utility, see the c99(1) reference page either online or in the Open System Services Shell and Utilities Reference Manual.
Index Symbols #pragma p32_shared, 393 #pragma p64_shared, 393 $RECEIVE, 74 -Wcplusplus, 88 -Wnld_obey option, 253 -Wtarget=tns/r flag, 286, 299 16-bit addressable parameters, 69 16-bit data model Binder commands, 281 description of, 325 32-bit data model Binder commands, 281 data model, 103 description of, 325, 326 32-bit int, 64 64-bit data model, 392 64–bit date model supports the 64-bit OSS user processes, 391 __CPLUSPLUS feature-test macro, 162 __DATE__ predefined macro, 161 __FILE__ predefined macro, 1
B Backup process description of, 76 using DLLs, 308 using SLLs, 295 BASENAME pragma, 173 Binary operator (##), 165 Binder description of, 30 TNS c89 utility, 269 Binder region, 268 Binder:TNS/R native linkers;Processes:attributes of;Files:stripping;Data blocks;, 35 Binding C++ programs Guardian environment, 281 C++ programs OSS environment, 284 CLIB, 266 CRELIB, 266 C module, 264 examples, 271 for the CRE, 267 internationalized programs, 271 rules, 267 selecting library files, 266, 271 Bit fields manipulati
CCOMP command syntax, 305 CCPLMAIN file, 177, 307 CCPPMAIN file, 177, 294 cextdecs header, 66, 100, 124 Cfront C++ translator, 273, 276 compilation steps, 32, 282 extension, signed char, 64 RUN command, 277 char arrays;Arrays char, 387 char variables, pTAL and C mixed programming, 134 char variables, TAL and C mixed programming, 110 Characters, user-defined features, 408 CHECK pragma, 178, 274 Check-sum functions, 387 CLARGE file, 266, 281 Class libraries, TNS C++, 418 CLIB file, 266 CNONSTOP file, 266 COBO
TNS/R native C, 396 Dialect see VERSION1, VERSION2, or VERSION3 Directives, preprocessor see Preprocessor directives DLL see Dynamic-link library (DLL) DLLs linking in, 308 Dynamic binding, 266 Dynamic-link library (DLL) example, 298, 310 Export attribute, 51 SHARED, 237 E Eclipse see NSDEE EDIT files description of, 73, 279 functions, 78 eld utility description of, 41 Example, 310 Guidelines, 177 Linking a module, 307 overview, 41 using with FLOATTYPE attribute, 302 ELD(arg) pragma, 182 ELF (Executable an
Function, prototypes, 123, 268 Functions check-sum, 387 extensible, 147, 196 hashing, 387 parameter messages, 372, 374 resident, 196 variable, 147, 196 G Generating TNS/R code on TNS/E system TNS/E native C and C++, 299 TNS/R narive C and C++, 286 getenv() function, native C, 400 getenv() function, TNS C, 412 Global data sharing C data with pTAL modules using BLOCK declarations, 132 sharing C data with TAL modules using BLOCK declarations, 109 sharing C data with TAL modules using pointers, 108, 131 sharin
Intermediate files, 279 Internationalized programs, 271 Interoperability Guardian and OSS, 47, 420 specific functions, 77 Interoperability:TNS/E native C;, 40 Interoperability:TNS/R native C++;, 34 ISO/ANSI C standard description of, 47 TNS C, 30 TNS/E C, 39 TNS/R C, 32 ISO/IEC 9899 1999 supported features, 457 K Kernighan & Ritchie (K&R) C, 210 Keywords extensions, 49 TNS/R C++, 436 KR pragma, 210 L Language attributes, 196 C++, 33, 39 extensions, 49 preprocessor, 269 Large-memory model Attributes of, 70
TAL and C guidelines, 103 types, 323, 325 Messages CRE service, 364 function parameter, 372, 374, 375 heap management, 370 input/output (I/O), 375 math function, 373, 374 MIGRATION_CHECK, 438 trap, 363 MIGRATION_CHECK pragma, 438 MISALIGNLOG attribute (SCF) attributes of, 384 misalignment tracing facility and, 383 Misdeclared external functions, 386 Mixed-language programming considerations, 56 for TNS, 97 for TNS/R and TNS/E, 122 TAL and C guidelines, 101, 125 TNS C++, 419 Model-dependent library files, 26
Passing pointers to constants, 144 PC cross compiler;Native compilers C/C++ PC cross compiler, 316 pe_heap_max value, 200 Physical file types, 73 PIC (Position-Independent Code) Call shared, 177 Example, 298, 310 for ld or eld linker, 170 for TNS/E native, 167 Non shared, 222 shared, 237 with libraries, 295, 308 Platform, 261 Pointer modifiers, 59 Pointers implicit casts, 61 null, 385 pTAL and C guidelines, 136 TAL and C guidelines, 112 uninitialized, 385 unions of, 386 user-defined features native C, 397 u
S Samll-memory model, 39 Sample C++ program, 279 SAVEABEND pragma, 235 SCF user interface misalignment handling and, 384 misalignment tracing facility and, 383 SEARCH pragma, 236, 276 Search subvolumes, 244 SEC, 309, 310 SECTION pragma, 237, 274 SEGMENT_ALLOCATE_ procedure, 117 SEGMENT_DEALLOCATE_ procedure, 117 SEGMENT_USE_ procedure, 117 SHARED pragma, 237 Shared run-time libraries See SRLs, 266 Sharing data C data with pTAL modules using pointers, 131 C data with TAL modules using BLOCK declarations, 109
T TACL macro, for compilation, 273 TAL calling C, 103, 127 Guardian procedure, 66 TAL and C guidelines arrays , 110, 134 arrays of structures , 111 bit-field manipulation , 113 C calling TAL , 104, 127 C enumeration variables, 113, 137 data sharing , 106 data types , 102, 126 Guardian procedure, 67 identifiers , 101 indirection , 109 memory usage , 103 multidimensional arrays , 111, 135 passing C routines to TAL, 116, 138 passing TAL routines to C, 115, 138 pointers , 112, 136 procedures cannot call directl
PC Tools, 318 SAVEABEND, 236 SYMBOLS, 250 Visual Inspect utility, 210 Volatile object accessing TNS C, 410 accessing TNS/R native C, 398 volatile type qualifier, 55 TNS C++, 418 W WARN pragma, 258, 274 Warning messages compiler, 329 run-time, 363 Wide characters, TNS C, 403, 415 Wide data model, 325 Wide data model;32-bit data model Type int, 64 WIDE pragma, 103, 258, 274 Working Paper X3J16/WG21, 434, 435 Writing portable programs, 45 X XMEM pragma, 259 XPG4 specification, 45, 152 XVAR pragma, 260 Z ZCP
