HP C/C++ Programmer’s Guide for NonStop Systems Abstract This guide describes HP extensions to the C and C++ languages for HP NonStop™ systems. The guide describes how to write C and C++ programs that run on an HP NonStop system in either the Guardian environment or the Open System Services (OSS) environment.
Document History Part Number Product Version Published 429301-003 NA December 2003 429301-004 NA May 2004 429301-006 NA December 2004 429301-008 H01 July 2005
HP C/C++ Programmer’s Guide for NonStop Systems Glossary Index Examples What’s New in This Guide xix Guide Information xix New and Changed Information About This Guide xxiii Audience xxiii Documentation Set Organization Related Manuals xxvi Guide Organization xxvii Notation Conventions xxxi Figures xix xxv 1.
1. Introduction to HP C and C++ for NonStop Systems (continued) Contents 1.
2. C and C++ Extensions (continued) Contents 2. C and C++ Extensions (continued) Operators (continued) _optional() 2-19 Data Types 2-20 decimal 2-21 long long 2-21 unsigned long long 2-21 signed char 2-21 Size of Type int 2-21 3.
Contents 5. Using the Standard C++ Library (continued) 5. Using the Standard C++ Library (continued) Contents of the Standard C++ Library 5-4 VERSION3 5-4 VERSION2 5-5 VERSION1 5-5 Installation Notes for VERSION3 5-6 Using Header Files With VERSION3 5-7 Installation Notes for VERSION2 5-7 Examples of VERSION2 Headers 5-8 VERSION2 Standard C++ Library Example Files 5-9 Compiling and Linking in the OSS Environment 5-12 Pragmas for the Standard C++ Library 5-12 Using the Neutral C++ Dialect 5-13 6.
. Mixed-Language Programming for TNS Programs (continued) Contents 7. Mixed-Language Programming for TNS Programs (continued) Interfacing to TAL (continued) TAL Procedures That You Cannot Directly Call Sharing Data 7-13 Variables and Parameters 7-17 Extended Data Segments 7-27 Interfacing to TNS COBOL 7-30 7-12 8.
9. System-Level Programming (continued) Contents 9. System-Level Programming (continued) Writing Variable and Extensible Functions 9-4 Declaring Variable Functions 9-5 Declaring Extensible Functions 9-5 Checking for Actual Parameters With _arg_present() 9-5 Omitting Parameters 9-6 Converting Variable Functions to Extensible Functions 9-6 10. Converting C-Series TNS Programs to Use the Current TNS Compiler 11. Migrating Programs to TNS/R or TNS/E Native Mode 12.
13. Compiler Pragmas (continued) Contents 13.
13. Compiler Pragmas (continued) Contents 13.
13. Compiler Pragmas (continued) Contents 13. Compiler Pragmas (continued) VERSION3 13-108 WARN 13-110 WIDE 13-112 XMEM 13-113 XVAR 13-114 14.
Contents 16. Compiling and Linking TNS/R Native C and C++ Programs 16. Compiling and Linking TNS/R Native C and C++ Programs Selecting a Development Platform 16-2 Specifying Header Files 16-3 Compiling and Linking Floating-Point Programs 16-4 Using Compiler Pragmas IEEE_Float and Tandem_Float 16-5 Using Link Options to Specify Floating-Point Format 16-5 Working in the Guardian Environment 16-9 Compiling a Module 16-9 Linking a Module 16-12 17.
18. Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC (continued) Contents 18. Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC (continued) PC Tools 18-8 HP Extensions for Codewright (TEC) Visual Inspect 18-9 ar Tool (File Archive) 18-9 18-8 19.
22. Run-Time Messages (continued) Contents 22. Run-Time Messages (continued) Function Parameter Messages 22-15 Input/Output Messages 22-16 Environment Messages 22-23 23. Handling TNS Data Alignment Misalignment Tracing Facility 23-2 Misalignment Handling 23-3 C/C++ Misalignment Examples 23-4 A. HP C Implementation-Defined Behavior Implementation-Defined Behavior of Native C A-2 G.3.1 Translation A-2 G.3.2 Environment A-2 G.3.3 Identifiers A-2 G.3.4 Characters A-2 G.3.5 Integers A-3 G.3.
A. HP C Implementation-Defined Behavior (continued) Contents A. HP C Implementation-Defined Behavior (continued) Implementation-Defined Behavior of TNS C (continued) G.3.10 Qualifiers A-19 G.3.11 Declarators A-20 G.3.12 Statements A-20 G.3.13 Preprocessing Directives A-20 G.3.14 Library Functions A-21 G.4 Locale Behavior A-26 G.5 Common Extensions A-26 B.
E. Features and Keywords of Version 2 Native C++ Contents E. Features and Keywords of Version 2 Native C++ Features Supported in VERSION2 E-1 Features Not Supported in VERSION2 E-4 Keywords Added for the D45 Product Release Defining Virtual Function Tables E-5 E-5 F. MIGRATION_CHECK Messages Code Examples F-26 Glossary Index Examples Example 3-1. Example 3-2. Example 7-1. Example 7-2. Example 7-3. Example 7-4. Example 8-1. Example 8-2. Example 8-3. Example 23-1. Example 23-2. Example 23-3.
Tables (continued) Contents Tables (continued) Table iv. Table 2-1. Table 2-2. Table 2-3. Table 2-4. Table 2-5. Table 4-1. Table 4-2. Table 4-3. Table 4-4. Table 5-1. Table 5-2. Table 5-3. Table 5-4. Table 6-1. Table 6-2. Table 6-3. Table 7-1. Table 7-2. Table 8-1. Table 9-1. Table 12-1. Table 12-2. Table 12-3. Table 13-1. Table 13-2. Table 13-3. Table 13-4. Table 14-1. Table 14-2. Table 14-3. Table 14-4. Table 14-5. Table 14-6.
Tables (continued) Contents Tables (continued) Table 15-1. Table 15-2. Table 15-3. Table 16-1. Table 16-2. Table 16-3. Table 16-4. Table 16-5. Table 16-6. Table 17-1. Table 17-2. Table 17-3. Table 17-4. Table 17-5. Table 17-6. Table 19-1. Table 19-2. Table 19-3. Table 19-4. Table 19-5. Table 21-1. Table 23-1. Table A-1. Table A-2. Table A-3. Table C-1. Table C-2. Table D-1. Table D-2. Table D-3. Table D-4. Table D-5. Table D-6. Table D-7. Table F-1.
Tables (continued) Contents HP C/C++ Programmer’s Guide for NonStop Systems—429301-008 xvii
Tables (continued) Contents HP C/C++ Programmer’s Guide for NonStop Systems—429301-008 xviii
What’s New in This Guide Guide Information HP C/C++ Programmer’s Guide for NonStop Systems Abstract This guide describes HP extensions to the C and C++ languages for HP NonStop™ systems. The guide describes how to write C and C++ programs that run on an HP NonStop system in either the Guardian environment or the Open System Services (OSS) environment.
New and Changed Information What’s New in This Guide • • • • ld nld noft NS/R pTAL Continue to use the Enterprise Toolkit or G-series servers for your G-series development tasks. The following changes are included in this edition: Section Change Throughout the manual Changed the use of Guardian to refer only to the Guardian environment (when compared to the OSS environment) or to Guardian system procedures, not to the NonStop system.
New and Changed Information What’s New in This Guide Section Change (continued) Section 5, Using the Standard C++ Library Indicated that Version 1 of the library is not supported on TNS/E servers. Customers must migrate applications that use VERSION1 to either VERSION2 or VERSION3 or use the CPPNEUTRAL dialect. Added new tables listing installation details for VERSION2 and VERSION3 on H-series systems.
New and Changed Information What’s New in This Guide Section Change (continued) Section 15, Compiling, Binding, and Accelerating TNS C++ Programs Added OCA as the accelerator for TNS programs to be run on a TNS/E platform. Mentioned Binder changes that allow Binder to work with a TNS-accelerated file containing TNS/E code. Section 16, Compiling and Linking TNS/R Native C and C++ Programs Clarified SRL and DLL information and updated manual titles in cross-references.
About This Guide This guide describes the implementation of the C and C++ programming languages for HP NonStop systems.
Audience About This Guide When you do mixed language programming, remember the following: • There are three HP compilers for the COBOL language, invoked by six separate commands.
Documentation Set Organization About This Guide describe HP extensions and enhancements to the standards, in addition to implementation-defined behavior. 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 i, Organization of HP C and C++ Documentation Set, on page -xxvi. • At the D30.
Related Manuals About This Guide Figure i. Organization of HP C and C++ Documentation Set D20 product release D30 product release C++ User's Guide C++ User's Guide D40 through G06.23 RVUs G06.24 and subsequent G06 RVUs, H06.
Related Manuals About This Guide Table i. Program Development Manuals and Online Help (page 1 of 2) 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.
Related Manuals About This Guide Table i. Program Development Manuals and Online Help (page 2 of 2) Manual Title Description noft Manual Describes how to use the TNS/R native object file tool noft. Object Code Accelerator (OCA) Manual Describes how to use the Object Code Accelerator to optimize TNS object code for the TNS/E execution environment. rld Manual Describes how to use the native PIC loader rld.
Guide Organization About This Guide Table iii. Open System Services (OSS) Environment Manuals Manual Title Descriptions Open System Services Library Calls Reference Manual Describes the syntax and semantics of the native C runtime library in the OSS environment. Open System Services Programmer’s Guide Describes how to use the OSS application programming interface to the operating system.
Guide Organization About This Guide Table iv. Summary of Contents (page 2 of 3) Section Title This section . . . 8 Mixed-Language Programming for TNS/R and TNS/E Native Programs Describes the Common Run-Time Environment (CRE) and the interface declarations that are necessary to interface from native C or C++ to pTAL or native COBOL. 9 System-Level Programming Describes how to write C code that resides in system code, system library, and user library.
Notation Conventions About This Guide Table iv. Summary of Contents (page 3 of 3) Section Title This section . . . 21 Native C and C++ Compiler Messages Lists the messages from the native C and C++ compilers. 22 Run-Time Messages Describes the C run-time library messages. 23 Handling TNS Data Alignment Describes the even-byte data alignment rules used by TNS compilers, and how to avoid violating the rules, and how to diagnose violations at run time.
General Syntax Notation About This Guide UPPERCASE LETTERS. Uppercase letters indicate keywords and reserved words; enter these items exactly as shown. Items not enclosed in brackets are required. For example: MAXATTACH lowercase italic letters. Lowercase italic letters indicate variable items that you supply. Items not enclosed in brackets are required. For example: file-name [ ] Brackets. Brackets enclose optional syntax items. For example: TERM [\system-name.
Notation for Messages About This Guide Punctuation. Parentheses, commas, semicolons, and other symbols not previously described must be entered as shown. For example: error := NEXTFILENAME ( file-name ) ; LISTOPENS SU $process-name.#su-name Quotation marks around a symbol such as a bracket or brace indicate the symbol is a required character that you must enter as shown. For example: "[" repetition-constant-list "]" Item Spacing.
Notation for Messages About This Guide lowercase italic letters. Lowercase italic letters indicate variable items whose values are displayed or returned. For example: p-register process-name computer type. Computer type letters within text indicate C and Open System Services (OSS) keywords and reserved words. Type these items exactly as shown. Items not enclosed in brackets are required. For example: myfile.c italic computer type.
Change Bar Notation About This Guide % Percent Sign. A percent sign precedes a number that is not in decimal notation. The % notation precedes an octal number. The %B notation precedes a binary number. The %H notation precedes a hexadecimal number. For example: %005400 %B101111 %H2F P=%p-register E=%e-register Change Bar Notation A change bar (as shown to the right of this paragraph) indicates a difference between this edition of this guide and the preceding edition.
Change Bar Notation About This Guide HP C/C++ Programmer’s Guide for NonStop Systems —429301-008 xxxvi
1 Introduction to HP C and C++ for NonStop Systems • • • • • • • • • • TNS C Language System on page 1-1 TNS C++ Language System on page 1-3 TNS/R Native C and C++ Language System on page 1-4 Features of TNS/R Native C and C++ on page 1-10 TNS/E Native C and C++ Language System on page 1-12 Features of TNS/E Native C and C++ on page 1-17 Writing Portable Programs on page 1-19 Porting Programs to HP C and C++ for NonStop Systems on page 1-21 Porting Without Data Alignment Problems on page 1-22 Guardian and
Introduction to HP C and C++ for NonStop Systems C Run-Time Library C Run-Time Library The C run-time library contains the functions defined in the ISO/ANSI C standard as well as several functions that are extensions to the standard. Macros that are not in the library are expanded during the preprocessing phase of the compiler. The Guardian C run-time library and the OSS C run-time library share the same set of header files.
Introduction to HP C and C++ for NonStop Systems Visual Inspect Symbolic Debugger Visual Inspect Symbolic Debugger Visual Inspect is an optional PC-based (GUI) symbolic debugger designed to work in complex distributed environments.
Introduction to HP C and C++ for NonStop Systems • • Exception Handling Is Not Supported 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 the following steps: 1.
Introduction to HP C and C++ for NonStop Systems TNS/R Native C Compiler TNS/R Native C Compiler The TNS/R native C compiler accepts C language source files that comply with either 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). The native C compiler also accepts HP NonStop extensions that support the native architecture.
Introduction to HP C and C++ for NonStop Systems • TNS/R Native C Run-Time Library On a PC running the Windows operating system, use the Enterprise Toolkit (ETK) or the Tandem Development Suite (TDS) to compile C++ code. You can also use the command-line cross compiler (named c89) outside the ETK or TDS. (The TDS does not support VERSION3.) For more information, see the online help in the ETK or TDS, or the file “Using the Command-Line Cross Compilers” installed with the ETK compiler package.
Introduction to HP C and C++ for NonStop Systems • TNS/R Native Linkers (nld and ld Utilities) Tools.h++ version 6.1 (Guardian version in file ZTLHGSRL; OSS version in file ZTLHOSRL) VERSION2 Standard C++ Library For C++ VERSION2, the following libraries are available: • • • • The HP NonStop C run-time library (file ZCRTLSRL) The HP NonStop C++ run-time library (product T0179, file ZCPLSRL) The draft Standard C++ Library from Rogue Wave (product T5895, file ZRWSLSRL) Tools.h++ version 7.
Introduction to HP C and C++ for NonStop Systems Inspect Symbolic Debugger Unlike Binder, nld and ld cannot replace individual procedures and data blocks in an object file or build an object file from individual procedures and data blocks. nld and ld operate on procedures and data blocks, but only in terms of an entire object file. nld and ld run in the Guardian and OSS environments as well as the HP Enterprise Toolkit (ETK) on the PC; only nld is available with the Tandem Development Suite (TDS).
Introduction to HP C and C++ for NonStop Systems • TNS/R Native Object File Tool (noft Utility) Is available also as a stand-alone product For more information about enabling and using Visual Inspect, see the Visual Inspect online help. See also the descriptions of pragmas INSPECT on page 13-52 and SYMBOLS on page 13-100. TNS/R Native Object File Tool (noft Utility) The native object file tool (the noft utility) reads and displays information about TNS/R native object files.
Introduction to HP C and C++ for NonStop Systems TNS/R Native C and C++ Migration Tool TNS/R 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++.
Introduction to HP C and C++ for NonStop Systems • • Features of TNS/R Native C and C++ 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). International Standard ISO/IEC 14882:2003(E) Programming Languages -- C++ (a newer standard) HP includes several extensions to ISO/ANSI standard C that make C an effective language for writing applications that execute under the HP NonStop operating system.
Introduction to HP C and C++ for NonStop Systems • TNS/E Native C and C++ Language System Fault-tolerant programs You can write fault-tolerant process pairs using the active backup programming model. TNS/E Native C and C++ Language System The TNS/E native C and C++ language system generates native C and C++ programs for the Guardian and OSS environments.
Introduction to HP C and C++ for NonStop Systems TNS/E Native C++ Compiler online help, or the file “Using the Command-Line Cross Compilers on Windows” installed with the ETK compiler package. The TNS/E native C compiler supports programs that define the size of pointers and type int as 32 bits (programs compiled with the pragma WIDE). Existing TNS C language programs that define pointers or type int as 16 bits must be changed.
Introduction to HP C and C++ for NonStop Systems C++ Run-Time Library and Standard C++ Library increases the interoperability between environments. For details on interoperability, refer to the Open System Services Programmer’s Guide. The native C run-time library provides locale-sensitive functions and algorithmic codeset converters for use in internationalized OSS applications. For details, refer to the Software Internationalization Guide.
Introduction to HP C and C++ for NonStop Systems TNS/E Native Linker (eld Utility) TNS/E Native Linker (eld Utility) The eld native linker links one or more TNS/E native object files (files generated by the native compilers or eld) to produce either an executable (a loadfile) or relinkable native object file (linkfile). eld can also modify process attributes, such as HIGHPIN, of executable native object files and remove nonessential information from native object files.
Introduction to HP C and C++ for NonStop Systems • • • TNS/E Native Object File Tool (enoft Utility) Provides source-level debugging for servers executing in either the Guardian or OSS environment; provides additional application navigation features that allow a higher level of abstraction Supports both CISC and native machine architectures and compilers (that is, C, C++, COBOL, TAL, EpTAL, pTAL, D-series Pascal, and FORTRAN), Guardian and OSS executing environments Is available also as a stand-alone pro
Introduction to HP C and C++ for NonStop Systems TNS/E Native C and C++ Migration Tool correct NonStop SQL/MX database calls. See the SQL/MX Programming Manual for C and COBOL. 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++.
Introduction to HP C and C++ for NonStop Systems • Features of TNS/E Native C and C++ International Standard ISO/IEC 14882:2003(E) Programming Languages -- C++ (a newer standard). HP includes several extensions to ISO/ANSI standard C that make C an effective language for writing applications that execute under the HP NonStop operating system.
Introduction to HP C and C++ for NonStop Systems • Writing Portable Programs Fault-tolerant programs You can write fault-tolerant process pairs using the active backup programming model. 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.
Introduction to HP C and C++ for NonStop Systems Following Good Programming Practices The five feature-test macros that apply to standards compliance are: _POSIX_C_SOURCE=1 Makes visible identifiers required or permitted by the POSIX.1 standard. _POSIX_C_SOURCE=2 Makes visible identifiers required or permitted by the POSIX.1 and POSIX.2 standards. _XOPEN_SOURCE Makes visible identifiers required or permitted by the XPG4 specification. Represents the OSS compile default.
Introduction to HP C and C++ for NonStop Systems • • • ° ° ° ° ° ° ° ° ° ° Porting Programs to HP C and C++ for NonStop Systems System headers Local headers Macros File scope variables External variables External functions Structures and unions Signal-catching functions Functions main function Do not write code that relies on processor architecture.
Introduction to HP C and C++ for NonStop Systems • Porting Without Data Alignment Problems Redesign the code to use functions and features of ISO/ANSI C. Many UNIX compilers now comply with the ISO/ANSI C standard. Unlike the HP C compilers, most of these compilers do not strictly enforce the standard by default. These compilers allow features that do not comply with the standard but that the compilers can still process correctly. Thus, many programs that you thought to be compliant are not.
Introduction to HP C and C++ for NonStop Systems Guardian and OSS Environment Interoperability 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.
Introduction to HP C and C++ for NonStop Systems Guardian and OSS Environment Interoperability HP C/C++ Programmer’s Guide for NonStop Systems —429301-008 1- 24
2 • • • • • C and C++ Extensions Keywords on page 2-1 Declarations on page 2-2, including the following: ° Storage Class Specifier on page 2-2 ° Type Specifier on page 2-7 ° Type Qualifier on page 2-9 ° Attribute Specifier on page 2-10 Pointer Modifiers on page 2-15 Operators on page 2-18 Data Types on page 2-20 This section 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.
Declarations C and C++ Extensions identifier. Enforcing standards conformance is the default setting. To disable it, specify the EXTENSIONS pragma. TNS C and C++ always treat these HP extensions as reserved keywords. There is no way to disable this behavior. This feature might cause some strictly conforming program to fail to compile. Declarations This subsection lists all of the extensions HP has made to the declarationspecifier syntax defined in the ISO/ANSI C standard.
C and C++ Extensions Declarations _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++). Consequently, _lowmem is useful only when compiling for the large-memory model or the wide-data model. Note that you can use _lowmem alone, or you can specify it after the auto, extern, or static storage-class specifiers. The _lowmem storage class specifier is applicable only in the TNS environment.
C and C++ Extensions Declarations 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. export-attribute: export$ indicates that a specification is a definition and its associated members will be exported.
Declarations C and C++ Extensions Examples for Native C/C++ For a complete programming example using export$ and import$ and producing a DLL, see Examples on page 16-17.
Declarations C and C++ Extensions • • Only members that are introduced by the class are exported or imported; methods inherited by the class are not exported or imported. Do not export a class definition in more than one compilation unit or load unit, and do not mix explicit export$/import$ usage with default class definitions.
Declarations C and C++ Extensions }; // Error to selectively export/import members of an exported/imported class class export$ C4 { public : int I; import$ int foo (void) {return I;} // Error export$ static int J; // Error }; int C4::J = 1; //Definition for exported static data member.
Declarations C and C++ Extensions struct-or-union-specifier, enum-specifier, and typedef-name are described in the ISO/ANSI C standard. Usage Guidelines • • If _cc_status is used as the return type for a function declaration, the language specifier, if used, must be one of _c, _tal, or _unspecified. The tal.h header contains three macros that interrogate the results of a function declared with the _cc_status type specifier.
Declarations C and C++ Extensions /* 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.
C and C++ Extensions Declarations Attribute Specifier The attribute specifier is an HP extension. It is used for writing system-level C and C++ functions and for declaring external routines written in other languages. Note. The attribute specifier is an outdated syntax for mixed-language programming and is maintained only for compatibility. To declare external routines written in another language, you should use the FUNCTION pragma syntax as described in FUNCTION on page 13-36.
C and C++ Extensions Declarations Considerations for Both Native and TNS Compilers • • • • • Only one language specifier can be specified for a function. The language specifier is allowed only in function declarations, function definitions, and function pointer declarations. However, _cobol, _fortran, _pascal, _tal, and _unspecified are not allowed in function definitions. _c is allowed in a function definition only if the language being compiled is C.
Declarations C and C++ Extensions Table 2-2, Effects of Function Attributes, shows the effect of function attributes for each language. “Valid” indicates that the compiler accepts the attribute. “Ignore” indicates that the compiler accepts but ignores the attribute. “Error” indicates that the compiler issues an error. Table 2-2.
Declarations C and C++ Extensions Considerations for only the native compilers: • • 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 only the TNS compilers: • A function with no prototype declaration or definition under pragma OLDCALLS cannot be _extensible.
Declarations C and C++ Extensions Considerations for both the native and TNS compilers: • • The _resident attribute is effective only for function definitions. It is ignored if it is given for a function declaration and its corresponding function definition is not in the same compilation unit. For C++, if you define a local class within a _resident function, then all member functions of this local class are implicitly declared to be _resident.
Pointer Modifiers C and C++ Extensions Usage Guidelines for Attribute-Specifier Syntax • • The FUNCTION pragma is the preferred method for declaring external routines. For details, see pragma FUNCTION on page 13-36 and Writing Interface Declarations on page 7-3. Programs that use this attribute-specifier syntax can be made portable by using macro definitions in which the attribute-specifier keywords are replaced by nothing.
C and C++ Extensions Pointer Modifiers Ptr-operator for C++ Programming Language ptr-operator: [ modifier-list ] * [ cv-qualifier-seq ] [ modifier-list ] & [ cv-qualifier-seq ] [ :: ] nested-name-specifier [ modifier-list ] * [ cv-qualifier-seq ] modifier-list: modifier [ modifier-list ] modifier: _far | _near | _baddr | _waddr | _procaddr cv-qualifier-seq and nested-name-specifier are described in the draft ANSI C++ standard. _far denotes a 32-bit extended byte address.
Pointer Modifiers C and C++ Extensions • If _near is used to modify a pointer and neither _waddr or _baddr is specified, then the pointer can contain either a byte address or a TNS word address, as follows: If Type Pointed To Is Then Pointer Contains 8-bit scalar * byte address 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. * Arithmetic types and pointer types are called scalar types.
C and C++ Extensions • Operators For TNS only, _procaddr can be applied only to void *. A pointer declared with the _procaddr type qualifier cannot be fused to call a function. The value must be assigned to a typed function pointer and called through that pointer. Operators An expression comprises a sequence of operators and operands. An operator specifies an operation that results in a value. The items on which the operator acts are called operands.
C and C++ Extensions Operators type-name is the name of a type. unary-expression is a unary expression. Usage Guideline The _bitlength() operator cannot be applied to an operand of function type or of incomplete type. If this application is attempted, the result is an unsigned constant whose type is size_t. _optional() The _optional() operator is similar to the pTAL $OPTIONAL standard function. It allows you to dynamically pass and omit actual parameters to extensible and variable functions.
Data Types C and C++ Extensions This example shows a function that passes along one of its optional parameters only if an actual parameter is supplied. _extensible foo (int, int, int); _extensible void bar ( int i, int j) { /* Pass a third argument of j to foo only if j is present. */ foo (10, 20, _optional (_arg_present (j), j )); } This example shows an incorrect usage of the _optional operator.
Data Types C and C++ Extensions Table 2-4. Predefined Data Types (page 2 of 2) Long forms Abbreviated forms double double long double long double * 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.
Data Types C and C++ Extensions data model, use the WIDE pragma. The WIDE pragma compiles only under the largememory model. For TNS C, a C program runs under the large-memory model unless you have specified the NOXMEM pragma. For TNS C++, a C++ program always runs under the large-memory model. In addition, the 32-bit (wide) data model is the default specification. If you want the size of the data type int to be 16 bits, specify the NOWIDE pragma.
3 Interfacing to Guardian Procedures and OSS Functions • • • Declaring Guardian Procedures on page 3-1 Calling Guardian Procedures on page 3-3 ° Procedures That Return a Return Value on page 3-3 ° Procedures That Return a Condition Code on page 3-4 ° Procedures With 16-Bit Addressable Parameters on page 3-6 ° Procedures That You Cannot Call on page 3-6 Declaring OSS Functions on page 3-6 This section describes how to declare and call Guardian procedures and OSS functions in C and C++ programs.
Interfacing to Guardian Procedures and OSS Functions Declaring Guardian Procedures reference page includes its C declaration syntax; however, do not use this syntax to declare Guardian procedures. Include the appropriate header file instead. The header files specify the C names for the Guardian procedures in uppercase characters and provide a section for each procedure using the SECTION pragma.
Interfacing to Guardian Procedures and OSS Functions Calling Guardian Procedures Calling Guardian Procedures The syntax of a Guardian procedure call determines whether a parameter is required or is optional. To call procedures with optional parameters, you can omit the parameter, but you must include the comma that would follow it. For example: err = FILENAME_SCAN_ (string,length,count,,,options); A call to a Guardian procedure usually returns either a return value or a condition code.
Interfacing to Guardian Procedures and OSS Functions Procedures That Return a Condition Code Example 3-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.
Interfacing to Guardian Procedures and OSS Functions Procedures That Return a Condition Code Example 3-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.
Interfacing to Guardian Procedures and OSS Functions Procedures With 16-Bit Addressable Parameters Procedures With 16-Bit Addressable Parameters Native C and C++ programs do not support 16-bit addressable parameters. All Guardian procedures called from native programs use 32-bit addressable parameters. This subsection applies only to TNS C and C++ programs. Some Guardian procedures require 16-bit addressable parameters.
4 • • • • • • • • • Using the C Run-Time Library Versions of the C Run-Time Library on page 4-1 Input/Output Models on page 4-2, including ANSI model and alternate model I/O Mathematical Functions on page 4-6 ° IEEE Floating-Point Arithmetic on page 4-7 ° Differences Between Tandem and IEEE Floating-Point Formats on page 4-7 Active Backup Programming Functions on page 4-8 Environment-Specific Functions on page 4-10 ° Changes Required to Interoperable Compilation Modules at D44 on page 4-10 EDIT File Functi
Input/Output Models Using the C Run-Time Library Complete semantics and syntax of functions and macros in each version of the C runtime library are documented in the following manuals: Version Manual Guardian TNS C run-time library Guardian TNS C Library Calls Reference Manual OSS TNS C G-series run-time library D30 edition of the Open System Services Library Calls Reference Manual Guardian native C run-time libraries Guardian Native C Library Calls Reference Manual OSS native C run-time libraries
Using the C Run-Time Library Logical File Types Logical File Types Regardless of the file-reference model you use, you specify the logical file type of a physical file when you open the physical file. When selecting which logical type to use, you must consider two factors: 1. Which of the logical types best matches the way you want to interpret the data in the physical file 2.
Physical File Types Using the C Run-Time Library Table 4-1.
Using the C Run-Time Library ANSI-Model I/O When you characterize a process as a binary file, each I/O request is an interprocess message. Consequently, when you perform binary interprocess communication, you should use the direct I/O functions that transfer blocks of data, not single characters. When you characterize a process as a text file, each line is an interprocess message.
Using the C Run-Time Library Alternate-Model I/O Alternate-Model I/O As mentioned earlier, the alternate-model I/O functions use file descriptors to identify files. The alternate-model I/O functions are not available in standard ISO/ANSI C. In the Guardian TNS environment, alternate-model I/O functions are defined by HP. In all other environments, alternate-model I/O functions are defined by the XPG4 specification.
Using the C Run-Time Library IEEE Floating-Point Arithmetic might be set to [EDOM]. Because the Tandem floating-point format does not support NaN, the cos() function does not return NaN or optionally set errno to [EDOM]. Note that if you specify IEEE floating-point format, NaN is supported. The standards specify the action that must or might occur for a given condition. If the condition cannot occur in a given implementation, the action is not required.
Active Backup Programming Functions Using the C Run-Time Library • IEEE floating-point format is available only on NonStop servers with the underlying hardware capacity, running a G07 or later version of the HP NonStop operating system. For more general information about IEEE floating-point format, see Compiling and Linking Floating-Point Programs on page 16-4, and see the Guardian Programmer’s Guide.
Active Backup Programming Functions Using the C Run-Time Library critical data serves two purposes: to provide sufficient information to enable the backup process to resume application processing (file state and application state information), and to indicate to the backup process where it should logically resume application processing (control state information). The backup process receives messages from two sources.
Using the C Run-Time Library Environment-Specific Functions Environment-Specific Functions There are several file-system functions that allow you to operate on a file in the opposite environment without writing and compiling a separate module for that environment. These functions are fopen(), freopen(), remove(), rename(), tmpfile(), and tmpnam(). Each of these functions has environment-specific variants with suffixes to indicate which type of file you want to operate on.
EDIT File Functions Using the C Run-Time Library The TNS/R native C modules that must be recompiled and the source code changes you need to make are summarized in the following table: Type of Compilation Unit Type of Runnable Unit Change Required SYSTYPE GUARDIAN OSS process Use _guardian variant of the function in compilation unit. SYSTYPE OSS Guardian process Use _oss variant of the function in compilation unit.
Miscellaneous HP Extension Functions Using the C Run-Time Library Table 4-4. C Functions That Retrieve Process Startup Information (page 2 of 2) Function Action get_param_by_name() Retrieves the value of the parameter that corresponds to the parameter name requested. get_param_msg() Retrieves the PARAM message. get_startup_msg() Retrieves the process startup message.
5 • • • • • • • • Using the Standard C++ Library User Documentation on page 5-3 Features of the Standard C++ Library (VERSION3) on page 5-3 Contents of the Standard C++ Library on page 5-4 ° ° ° VERSION3 on page 5-4 VERSION2 on page 5-5 VERSION1 on page 5-5 Installation Notes for VERSION3 on page 5-6 ° Using Header Files With VERSION3 on page 5-7 Installation Notes for VERSION2 on page 5-7 ° ° Examples of VERSION2 Headers on page 5-8 VERSION2 Standard C++ Library Example Files on page 5-9 Compili
Using the Standard C++ Library Table 5-1. Versions of the Standard C++ and C++ Run-Time Libraries Version Product Number Description T9227 C++ run-time library TNS/R programs VERSION1 G-series systems only VERSION2 VERSION3 Separate libraries for Guardian and OSS: ZCPLGSRL and ZCPLOSRL, respectively T2824 Common header files for all C++ versions T5895 Standard C++ library, Rogue Wave Software version 1.31, file ZRWSLSRL T0179 C++ run-time library, file ZCPLSRL T8473 Tools.
User Documentation Using the Standard C++ Library User Documentation Available using the HP NonStop Technical Library (NTL) software: • 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 Using the Standard C++ Library VERSION3 Feature Advantages (continued) Migration tool To help customers move from C++ VERSION2 to C++ VERSION3, the migration tool generates warnings in the listing file where potential problems are found. The MIGRATION_CHECK pragma is described in MIGRATION_CHECK on page 13-63, and its output is described in Appendix F, MIGRATION_CHECK Messages.
VERSION2 Using the Standard C++ Library Using VERSION3 on Guardian, you should use the full name of the standard headers, without truncating the name or using a .h file extension. The NonStop system automatically performs truncation as necessary. HP recommends that you also use the CPATHEQ pragma to specify the SLMAP file as described in Pragmas for the Standard C++ Library on page 5-12. SLMAP contains specific truncation rules for the header names that do not fit the standard.
Installation Notes for VERSION3 Using the Standard C++ Library VERSION1 is not supported on H-series systems. To run a C++ program on an H-series system when it is based on VERSION1 of the C++ Library, you must migrate it to VERSION3, VERSION2, or CPPNEUTRAL before recompiling it. Migration from VERSION1 to VERSION2 also requires migrating from use of Tools.h++ 6.1 to use of Tools.h++ 7. Migration from VERSION1 to VERSION3 requires migrating from use of either version of Tools.h++. See Using Tools.
Using the Standard C++ Library Using Header Files With VERSION3 Using Header Files With VERSION3 Specify the names of the VERSION3 Standard C++ Library header files as defined in the standard. On NonStop systems, header files have been renamed in some cases to implement the three versions of the library, but in all cases you need only to specify the standard names. To use a VERSION3 header file, do not include .h (even if the standard name contains .h).
Examples of VERSION2 Headers Using the Standard C++ Library Table 5-3. Installation Details for Rogue Wave Standard C++ Library (VERSION2) Environment Location of Headers Location of Libraries Guardian $SYSTEM.SYSTEM TNS/R code: $SYSTEM.SYSnn.ZRWSLSRL TNS/E code: $SYSTEM.ZDLLnnn.ZRWSLDLL OSS /usr/include The Guardian namespace: TNS/R code: $SYSTEM.SYSnn.ZRWSLSRL TNS/E code: $SYSTEM.ZDLLnnn.
Using the Standard C++ Library • VERSION2 Standard C++ Library Example Files Specifying the header-file name rwnew includes both new.h and the header file rwnew from the Standard C++ Library (as renamed for the HP implementation). #include //includes standard header "new.
Using the Standard C++ Library VERSION2 Standard C++ Library Example Files Table 5-4.
Using the Standard C++ Library VERSION2 Standard C++ Library Example Files Table 5-4.
Compiling and Linking in the OSS Environment Using the Standard C++ Library Table 5-4.
Using the Neutral C++ Dialect Using the Standard C++ Library #pragma mapinclude file #pragma mapinclude file #pragma mapinclude file #pragma mapinclude file #pragma mapinclude file #pragma mapinclude file #endif /* __SLMAP */ "tree.cc" "vector.cc" "sys/types.h" "sys/stat.h" "hash_map" "hash_set" = = = = = = "treecc" "vectorcc" "systypeh" "sysstath" "hashmap" "hashset" Note that this SLMAP file can be used with both VERSION2 and VERSION3.
Using the Standard C++ Library Using the Neutral C++ Dialect The BUILD_NEUTRAL_LIBRARY pragma can also be specified as a flag on the c89 command line as -Wbuild_neutral_library.
6 Accessing Middleware Using HP C and C++ for NonStop Systems • • Using Tools.h++ ° ° ° ° ° ° ° ° User Documentation on page 6-2 Contents of the Tools.h++ Class Library (Version 7) on page 6-2 Migration Considerations for Version 7 on page 6-2 Installation Notes on page 6-3 Including Header Files for Tools.h++ on page 6-4 XDR Streams on page 6-4 Tools.h++ Example Files for Versions 6.1 and 7 on page 6-4 Pragmas for Tools.
Accessing Middleware Using HP C and C++ for NonStop Systems User Documentation User Documentation • • Version 6.1: Tools.h++ Manual Version 7: Tools.h++ User’s Guide and Tools.h++ Class Reference These manuals are available on the HP NonStop user documentation disc using the HP NonStop Technical Library (NTL) software. Contents of the Tools.h++ Class Library (Version 7) Tools.
Accessing Middleware Using HP C and C++ for NonStop Systems Installation Notes To migrate existing code from version 6.1 to version 7, the following code adjustments are required for specific classes: • • • • Extra template arguments are required for hashed and sorted collections. Use the predefined macro RWDefHArgs or RWDefCArgs to provide the additional template arguments. Different constructor arguments are required for hashed collections.
Accessing Middleware Using HP C and C++ for NonStop Systems Including Header Files for Tools.h++ Table 6-1. Installation Details for G06.20 Tools.h++ (page 2 of 2) Environment Location of Header Files Location of SRLs or DLLS OSS Version 6.1: /usr/rogue6.1/rw In the Guardian namespace: Version 7: /usr/rogue/rw G-series Version 7: $SYSTEM.SYSnn.ZTLHSRL Version 6.1: $SYSTEM.SYSnn.ZTLHGSRL, $SYSTEM.SYSnn.ZTLHOSRL H-series Version 7: $SYSTEM.ZDLLnnn.ZTLH7DLL PC running Windows (ETK) Version 6.
Accessing Middleware Using HP C and C++ for NonStop Systems Tools.h++ Example Files for Versions 6.1 and 7 Table 6-2. Tools.h++ Example Files for Version 6.1 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 6-3 lists the example files that are provided with Version 7. Table 6-3. Tools.
Accessing Middleware Using HP C and C++ for NonStop Systems Pragmas for Tools.h++ Pragmas for Tools.h++ You need to use the MAPINCLUDE and CPATHEQ pragmas to map UNIX or OSS pathnames to Guardian file names. The following examples illustrate the use of these pragmas: 1. The pragma: pragma MAPINCLUDE "from"="to" 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. • The following example treats #include "sys/types.
Accessing Middleware Using HP C and C++ for NonStop Systems Pragmas for Tools.h++ For example, to get version 7 of the Tools.h++ library, a user might specify: #pragma MAPINCLUDE PATH "rw/"= "$system.zincrw70." To get version 6.1 of the Tools.h++ library, a user might specify: #pragma MAPINCLUDE PATH "rw/"="$system.zrw." 3. The pragma: pragma MAPINCLUDE FILE "from"="to" tells C or C++ to modify any #include name ending with the "from" string. It replaces the "from" string with the "to" string.
Accessing Middleware Using HP C and C++ for NonStop Systems • • • • Pragmas for Tools.h++ Only one MAPINCLUDE pragma without the PATH or FILE modifier is performed on each #INCLUDE directive. MAPINCLUDE FILE and PATH pragmas can be specified more than once. Each one must have a unique "from" string, or a diagnostic message is issued. Subvolume searching by the SSV pragma does not change. That is, if an #include (after substitution) includes a volume or subvolume, it is not overridden by an SSV.
7 Mixed-Language Programming for TNS Programs • • • • • Introducing the CRE on page 7-1 Using Standard Files in Mixed-Language Programs on page 7-3 Writing Interface Declarations on page 7-3 Interfacing to TAL on page 7-7 ° Using Identifiers on page 7-7 ° Matching Data Types on page 7-8 ° Memory Models on page 7-9 ° Data Model on page 7-9 ° Calling TNS C Routines From TAL Modules on page 7-10 ° Calling TAL Routines From TNS C Modules on page 7-11 ° Sharing Data on page 7-13 ° Variables and Parameters on p
Introducing the CRE Mixed-Language Programming for TNS Programs log. The language-specific run-time libraries access all other files by calling Guardian system procedures directly, whether or not a program uses the CRE. C-series programs run in a language-specific run-time environment. D-series C and Pascal programs run only in the CRE. D-series COBOL, FORTRAN, and TAL programs can run in either their language-specific run-time environments or the CRE.
Mixed-Language Programming for TNS Programs Using Standard Files in Mixed-Language Programs routines in a program to run in the CRE. In contrast, TAL routines must call CRE library routines directly. For information on writing programs that use the services provided by the CRE, see the Common Run-Time Environment (CRE) Programmer’s Guide. For details on specifying a run-time environment, see the description of pragma ENV on page 13-19.
Mixed-Language Programming for TNS Programs • • Usage Guidelines 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 on page 2-10. You should use the FUNCTION pragma to declare external routines.
Examples Mixed-Language Programming for TNS Programs contains three macros to interrogate the results of the procedure declared with the _cc_status type specifier: #define _status_lt(x) ((x) #define _status_eg(x) ((x) #define _status_gt(x) ((x) == 2) == 1) == 0) Before you can use these macros, you must include the tal.h header file. Note that you should avoid designing TAL procedures that return a condition code, because that is an outdated programming practice.
Mixed-Language Programming for TNS Programs Examples The example is equivalent to the following older-style interface declaration: _extensible _tal _alias (“CRE_ASSIGN_MAXORDINAL_”) \ get_max_assign_msg_ordinal (void); 2. This example, taken from the cextdecs header file, shows the interface declaration for the CHANGELIST system procedure.
Mixed-Language Programming for TNS Programs Interfacing to TAL 6.
Matching Data Types Mixed-Language Programming for TNS Programs Matching Data Types Use data types that are compatible between languages for: • • • Shared global variables Formal or actual parameters Function return values Table 7-2 lists compatible TAL and C data types for each TAL addressing mode. Table 7-2.
Memory Models Mixed-Language Programming for TNS Programs 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.
Calling TNS C Routines From TAL Modules Mixed-Language Programming for TNS Programs Calling TNS C Routines From TAL Modules A TAL module must include an EXTERNAL procedure declaration for each TNS C routine to be called. The following TAL code shows the EXTERNAL procedure declaration for C_FUNC and a routine that calls C_FUNC. ARRAY is declared with .EXT, because C_FUNC uses the large-memory model: TAL Code C Code INT status := 0; STRING .EXT array[0:4]; INT PROC c_func (a) LANGUAGE C; STRING .
Mixed-Language Programming for TNS Programs Calling TAL Routines From TNS C Modules Calling TAL Routines From TNS C Modules A TNS C module has full access to the TNS C run-time library even if the C module does not contain the main() routine. When you code TNS C modules that call TAL routines: • • • Include an interface declaration for each TAL routine to be called, or a function prototype and a FUNCTION pragma, as described in Using a Function Prototype and a FUNCTION Pragma on page 8-3.
Mixed-Language Programming for TNS Programs TAL Procedures That You Cannot Directly Call _tal _variable _cc_status READ (short, short *, short, short *, long); _tal _extensible _cc_status READX (short, char _far *, short, short *, long); _tal _alias ("tal^name") void c_name (short *); After specifying an interface declaration, use the normal C routine call to access the TAL routine.
Mixed-Language Programming for TNS Programs Sharing Data To illustrate this technique, the following example defines a jacket procedure for the GETPOOL system procedure. First, here is the TAL source module that defines the jacket routine: ?SOURCE EXTDECS(GETPOOL); PROC C^GETPOOL(pool^head, block^size, block^addr); INT .EXT pool^head; ! Address of pool head INT(32) block^size; ! Block size INT(32) .
Sharing Data Mixed-Language Programming for TNS Programs You can share global data in the automatic extended data segment between the following kinds of TAL and C modules: • • TAL modules that declare global variables having extended indirection (.
Sharing Data Mixed-Language Programming for TNS Programs return 1; } /* Access the TAL arrays by using the pointers */ TAL Code STRUCT rec (*); BEGIN INT x; STRING tal_str_array[0:9]; END; INT .EXT tal_int_array[0:4]; STRUCT .EXT tal_struct (rec); !TAL data to share with C !TAL 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.
Sharing Data Mixed-Language Programming for TNS Programs This example shows how to share C data with a TAL module. The TNS C module passes the addresses of two C arrays to a TAL routine. The TAL routine assigns the array addresses to TAL pointers.
Variables and Parameters Mixed-Language Programming for TNS Programs In the following example, a TAL module declares a variable within a BLOCK declaration, and the TNS C module declares the equivalent variable: TAL Code C Code NAME TAL_module; BLOCK fred; INT .EXT fred; END BLOCK; int FRED; /*all uppercase*/ Because this method requires that the layout of the corresponding TAL and C declarations match, it is recommended that you share data by using pointers where possible.
Variables and Parameters Mixed-Language Programming for TNS Programs • Declare TAL STRING and C char formal parameters as reference parameters to avoid the following 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. ° When you pass a char parameter to a TAL routine, the actual byte value occupies the right byte of the word allocated for the TAL STRING formal parameter.
Variables and Parameters Mixed-Language Programming for TNS Programs Structures All TAL and C structures begin on a word boundary. Following 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.
Variables and Parameters Mixed-Language Programming for TNS Programs Multidimensional Arrays In C, you can declare multidimensional arrays. In TAL, you can emulate multidimensional arrays by declaring structures that contain arrays. Here is an example of multidimensional arrays in TAL and TNS C (large-memory model): TAL Code C Code STRUCT rec1 (*); BEGIN INT y[0:4]; END; short cma[10][5]; STRUCT .EXT tma(rec1)[0:9]; !Sample access! tma[8].
Variables and Parameters Mixed-Language Programming for TNS Programs Pointers Pointers contain memory addresses of data. You must store an address into a pointer before you use it. In TAL and C pointer declarations, you specify the data type of the data to which the pointer points. You must use pointers when sharing global variables. You can pass pointer contents by value between TAL and C routines.
Variables and Parameters Mixed-Language Programming for TNS Programs 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 rec { short x; struct rec *p; }; STRUCT .EXT joe (rec); PROC callme (param1); INT .
Variables and Parameters Mixed-Language Programming for TNS Programs Bit-Field Manipulation You can manipulate bit fields in both TAL and C. In TAL, you can use either: • • Built-in bit-extraction and bit-deposit operations Bit-wise operators LAND and LOR In C, you can use either: • • Bit-wise operators & (and) and | (or) Defines The following TAL bit-deposit operation and C bit-wise operation are equivalent: TAL Code C Code INT x := -1; INT y := 0; PROC example; BEGIN y.<0:2> := x.
Variables and Parameters Mixed-Language Programming for TNS Programs If the WIDE pragma is not specified, the TNS C compiler normally packs adjacent bit fields in a 16-bit word. If the WIDE pragma is specified, the TNS C compiler normally packs adjacent bit fields in a 32-bit word. TAL UNSIGNED(1–16) and C bit fields of like size are compatible. TAL UNSIGNED(17–31) and C bit fields of like size are compatible.
Variables and Parameters Mixed-Language Programming for TNS Programs In the following example, a large-memory-model TNS C module contains C_FUNC, which expects a TAL procedure as a parameter.
Variables and Parameters Mixed-Language Programming for TNS Programs 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.
Extended Data Segments Mixed-Language Programming for TNS Programs /* a parameter to TAL_PROC */ } When you pass a large-memory-model TNS C routine as a parameter, the compiler passes a 32-bit address that contains PEP and map information in the high-order word and a zero in the low-order word. When you pass a small-memory-model TNS C routine as a parameter, the compiler passes a 16-bit address that contains PEP and map information.
Mixed-Language Programming for TNS Programs Extended Data Segments Here are guidelines for using explicit extended data segments: 1. Declare an extended pointer for the base address of the explicit extended segment. 2. To allocate an explicit extended data segment and obtain the segment base address, call SEGMENT_ALLOCATE_. 3. To make the explicit extended segment the current segment, call SEGMENT_USE_. 4.
Extended Data Segments Mixed-Language Programming for TNS Programs In the following example, a large-memory-model TNS C routine calls a TAL routine that manipulates data in an explicit extended data segment and then restores the automatic extended data segment. When control returns to the TNS C routine, it manipulates data in the restored automatic extended data segment: TAL Code INT .EXT array[0:10]; !Allocated in the automatic ! extended data segment ID 1024D INT .
Mixed-Language Programming for TNS Programs main () { s = &sarr[0]; *s = 'A'; arr[0] = 10; MIGHT_LOSE_SEG (); Interfacing to TNS COBOL /* Call TAL routine, which uses the*/ /* explicit extended data segment */ /* 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.
Mixed-Language Programming for TNS Programs Interfacing to TNS COBOL For examples showing TNS/R native C calling a COBOL function in the Guardian and OSS environments, see Interfacing to Native COBOL on page 8-26. Example 7-2. 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.
Mixed-Language Programming for TNS Programs Interfacing to TNS COBOL Example 7-3. Include File (Prototype Function) /* COBINCLH */ /* Following is the new way to declare extern COBOL calls */ void XCOBFUNC (char *, short *, long *); #pragma FUNCTION XCOBFUNC (cobol) Example 7-4. Binder File select check parameter strong add * from testco add * from testcobo select search $system.system.cwide set heap 64 build testexe To compile the programs in the Guardian environment: 1.
8 Mixed-Language Programming for TNS/R and TNS/E Native Programs • • • • Introducing the CRE on page 8-2 Using Standard Files in Mixed-language Programs on page 8-2 Declaring External Routines on page 8-2 Considerations When Interfacing to pTAL on page 8-6 ° Using Identifiers on page 8-7 ° Matching Data Types on page 8-7 ° Calling C Routines From pTAL Modules on page 8-8 ° C Routines That You Cannot Call Directly on page 8-9 ° Calling pTAL Routines From C Modules on page 8-9 ° pTAL Procedures That You Cann
Mixed-Language Programming for TNS/R and TNS/E Native Programs Introducing the CRE native COBOL. The main() function in a native mixed-language program can be written in native C or C++, native COBOL, but not pTAL. Introducing the CRE The Common Run-Time Environment (CRE) is a set of services that support mixedlanguage programs. The CRE library is a collection of routines that implement the CRE. The CRE library enables the language-specific run-time libraries to coexist peacefully with each other.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Declaring External Routines Writing Interface Declarations The interface declaration is an HP extension of the function declaration as defined by ISO/ANSI C. The interface declaration indicates the correct language or indicates unspecified if the language is unknown. If no language attribute specifier is provided, then the external procedure is assumed to be written in the same language as the compilation.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Declaring External Routines Usage Guidelines • Procedure names When you specify the C name of a non-C procedure, you should use the non-C name of the procedure if it is a valid C identifier. If the name is not a valid C identifier because it includes circumflexes (^) or hyphens (-), you must use the _alias attribute in the interface declaration.
Mixed-Language Programming for TNS/R and TNS/E Native Programs • • Declaring External Routines If the pTAL definition specifies the EXTENSIBLE attribute, the interface declaration must specify _extensible. If the pTAL definition specifies the VARIABLE attribute, the interface declaration must specify _variable. Examples 1. This example, taken from the stdlib.h header file, shows the preferred style for declaring an external routine (in this case, for the CRE_ASSIGN_MAXORDINAL_ procedure).
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL else return( NULL ); } 4. The following function prototype and FUNCTION pragma: void segment_allocate (short, long, short *, short); ... #pragma function segment_allocate (tal, alias (“SEGMENT_ALLOCATE_”), variable) is equivalent to the following interface declaration: _tal _variable short SEGMENT_ALLOCATE_ (short, long, short *, short); 5.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL Using Identifiers pTAL and C identifiers differ as follows: • • • pTAL and C have independent sets of reserved keywords. pTAL identifiers can include circumflexes (^); C identifiers cannot. The C language is case-sensitive; the pTAL language is not case-sensitive. To declare variable identifiers that satisfy both compilers: • • • • Avoid using reserved keywords in either language as identifiers.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL Table 8-1. Compatible pTAL and C Data Types (page 2 of 2) pTAL Declaration pTAL Data Type C Data Type INT .i; INT short * INT (32) .j; INT(32) int * FIXED .f; FIXED(0) long long * REAL .r; REAL float * REAL(64) .s; REAL(64) double * Indirect using 32-bit pointers STRING .EXT s; STRING char INT .EXT i; INT short INT (32) .EXT j; INT(32) int FIXED .
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL C Routines That You Cannot Call Directly pTAL procedures cannot call a C routine that: • • • Passes a struct or union parameter by value Returns a struct or union parameter by value Uses C-style variable argument list (...
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL Return Type Value Meaning void The pTAL routine does not return a value. fundamental-type The pTAL routine returns a value. Specify one of, or a pointer to one of, the character, integer, or floating-point types. _cc_status The pTAL routine does not return a value but does set a condition code. The tal.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL code, you must write a “jacket” procedure in pTAL that is directly callable by your C program.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL return( NULL ); } Techniques other than this cannot be used on H-series systems. See Appendix D of the pTAL Reference Manual for more information. 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.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL SHARED2 alignment rules that are the AUTO rules for TNS platforms, and directs the native C and C++ compilers to lay out components using the AUTO alignment rules for their respective TNS/R and TNS/E platforms. Sharing pTAL Data With C Using Pointers To share pTAL global data with C modules, follow these steps: 1.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL STRING .EXT tal_strptr; EXTERNAL; PROC tal_main MAIN; BEGIN status := init_c_ptrs (tal_int_array, tal_struct.tal_str_array); !Do lots of work END; Sharing C Data With pTAL Using Pointers To share C global data with pTAL modules, follow these steps: 1. In the C module, declare the data using pTAL-compatible identifiers, data types, and alignments.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL charr[2] = 'B'; } pTAL Code INT .EXT tal_int_ptr; STRING .EXT tal_char_ptr; !Pointer to C data !Pointer to C data PROC init_tal_ptrs (c_addr1, c_addr2); !Called from C INT .EXT c_addr1; STRING .
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL name x; int i; int j; int k [0:2] = 'P' := [0, 1, 2]; extern short i; extern short j; extern const short k [3] := {0, 1, 2}; block b; int .ext p; int .
Mixed-Language Programming for TNS/R and TNS/E Native Programs int o = 'P' := [1, 2, 3]; int p; end block; Considerations When Interfacing to pTAL /* is more than one data declaring item */ /* in the block. */ extern short o [3] := {1, 2, 3}; extern short p; block b4; int q = 'P' := [1, 2, 3]; int .r [0:9]; end block; /* Names are not changed because there */ /* is more than one data declaring item */ /* in the block.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL Characteristic pTAL Array C Array Lower bound Any integer Always zero Dimensions One dimension * One or more dimensions Direct or indirect Direct or indirect Indirect only Byte or word addressing STRING arrays and extended indirect arrays are byte addressed; all other arrays are word addressed Native C and C++ only have byte addressing * pTAL structures can emulate multidimensional C array
Mixed-Language Programming for TNS/R and TNS/E Native Programs • Considerations When Interfacing to pTAL In pTAL, a routine cannot return a structure as a return value or pass a struct or union by value. The following pTAL and C structures have compatible layouts: pTAL Code STRUCT rec (*); BEGIN INT x; STRING y[0:2]; END; C Code struct birdname { short x; char y[3]; } robin[10]; STRUCT .
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL Arrays of Structures If you specify bounds when you declare a pTAL structure, you create an array of structures. The following pTAL and C arrays of structures are equivalent. Each declaration contains an array of ten structure occurrences: pTAL Code C Code STRUCT cell (*); BEGIN INT x; STRING y; END; struct cell { short x; char y; }; STRUCT .
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL Differences between pTAL and C pointers include the following: • • • pTAL structure pointers can point to a byte or word address. C structure pointers always point to a byte address. pTAL pointers are dereferenced implicitly. Here are examples of pTAL and native C pointers: pTAL Code C Code STRUCT rec (*); BEGIN INT d; INT .p (rec); END; struct rec { short d; struct rec *p; }; BLOCK joe; INT .
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL A C routine can share an enumeration variable with pTAL routines. A pTAL routine cannot access the enumeration variables, but it can declare LITERALs for readability.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL C Module /* C function that accepts pTAL routine as parameter */ void C_FUNC (short (*F) (short n)) { short j; j = (*F)(2); /* lots of code */ } pTAL Module PROC c_func (x) LANGUAGE C; INT PROC x; EXTERNAL; !EXTERNAL procedure declaration ! for C routine to be called !Parameter declaration INT PROC tal_param_proc (f); !Procedure to be passed as a INT f; ! parameter to C_FUNC BEGIN RETURN f; END; PROC t
Mixed-Language Programming for TNS/R and TNS/E Native Programs Differences Between Native and TNS MixedLanguage Programs pTAL Module INT i; STRING .EXT s[0:9]; PROC c_param_func (i, s) LANGUAGE C; INT i; STRING .
Mixed-Language Programming for TNS/R and TNS/E Native Programs Differences Between Native and TNS MixedLanguage Programs Data Models The native C and C++ compilers support only one data model: the 32-bit or wide data model. The size of int is always 32 bits. If you are writing C or C++ programs that you want to run as both native and TNS processes, you must write code that expects the size of type int to be 32 bits.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Interfacing to Native COBOL For more information on using extended data segments, refer to the “Managing Memory” section in the Guardian Programmer’s Guide. Interfacing to Native COBOL Your native C/C++ programs can call functions written in native COBOL. The general procedure consists of the following steps: Use a native COBOL compiler to compile the COBOL function. Use a native C/C++ compiler to compile the C/C++ program.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Interfacing to Native COBOL Example 8-1. C Program That Calls a COBOL Function /* testc.c */ /* #pragma inspect, symbols */ /* #pragma search largec */ #include #include "cobincl.h" short main (void) { short ds; long dl; char *tx = "Displayed in COBOL"; ds = 100; dl = 40000; XCOBFUNC(tx, &ds, &dl); printf("I am back in C now and program is ending.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Interfacing to Native COBOL Example 8-2. COBOL Function Called by a C Program ================================================================ The COBOL program for OSS. testcob.cob ================================================================ ?env common;innerlist ?SYMBOLS IDENTIFICATION DIVISION. PROGRAM-ID. XCOBFUNC. AUTHOR. MOLLY. DATE-WRITTEN. 7/25/00. ENVIRONMENT DIVISION. CONFIGURATION SECTION. SOURCE-COMPUTER. TANDEM-K2006.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Interfacing to Native COBOL Compiling and Linking the COBOL and C Programs To compile the programs in the OSS environment: 1. Compile the COBOL function named testcob.cob using the TNS/R native COBOL compiler: nmcobol -c testcob.cob or compile the function using the TNS/E native COBOL compiler: ecobol -c testcob.cob 2. Compile the C program named testc.c using c89: c89 -c testc.c The resulting object file is named testc.o. 3.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Interfacing to Native COBOL or eld $system.system.ccplmain testco testcobo -o testexe -l zcobdll 4.
9 • • • System-Level Programming Specifying a Code Space on page 9-1 Passing Pointers to Constants Between Code Spaces on page 9-2 Writing Variable and Extensible Functions on page 9-4 ° Declaring Variable Functions on page 9-5 ° Declaring Extensible Functions on page 9-5 ° Checking for Actual Parameters With _arg_present() on page 9-5 ° Omitting Parameters on page 9-6 ° Converting Variable Functions to Extensible Functions on page 9-6 System-level programming refers to the ability to write TNS C and C++
Passing Pointers to Constants Between Code Spaces System-Level Programming Table 9-1. Code Spaces and the Availability of Run-Time Library and Language Features (page 2 of 2) Feature System Code User Library System Library CRE library functions No Yes No Constants allocated in code space No ** Yes Yes Constants allocated in data space Yes No No * TNS C and C++ programs can use functions in a user library if direct access to relocatable data blocks is not needed for the operations.
Passing Pointers to Constants Between Code Spaces System-Level Programming Example The following example shows valid uses of the CSADDR pragma to pass pointers to constants between code spaces: #pragma env library #pragma csaddr #pragma xmem void foo( const void * ); main() { const struct S { int i,j,k; } s = { 10, 20, 30 }; const struct S *sp; foo( "This is a test" ); /* 15 bytes copied and passed */ foo( &s ); /* 6 bytes copied and passed */ sp = &s; A pointer variable to the code space cannot be init
System-Level Programming Writing Variable and Extensible Functions 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.
System-Level Programming Writing Variable and Extensible Functions instead of variable in native C programs. The following discussion about variable and extensible functions applies only to TNS C and C++, not to native mode. Declaring Variable Functions The variable attribute directs the compiler to treat all parameters of a function as though they are optional, even if some are required by your code.
Writing Variable and Extensible Functions System-Level Programming In the following example of a variable function, a default value is assigned if the first argument is absent. It operates on the second argument if it is present.
System-Level Programming Writing Variable and Extensible Functions extensible function is unnecessary, because native C and C++ treat functions declared variable or extensible as extensible functions. Note. To convert a variable function into an extensible function, you must use the deprecated syntax for writing function declarations. This syntax uses the _variable and _extensible attributes described in Attribute Specifier on page 2-10. You cannot use the FUNCTION pragma in this case.
System-Level Programming Writing Variable and Extensible Functions HP C/C++ Programmer’s Guide for NonStop Systems —429301-008 9 -8
10 Converting C-Series TNS Programs to Use the Current TNS Compiler This section 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, refer to the Guardian Application Conversion Guide. Note. Do not convert a C-series TNS C program to a current native C program directly.
Converting C-Series TNS Programs to Use the Current TNS Compiler Change code that uses the result of the sizeof operator for constant operands under the 32-bit or wide data model (pragma WIDE): • • ° For C-series compilers, the sizeof operator returns 2 or 4 for constant operands. ° For the current compilers, the sizeof operator returns 4 for all constant operands. Change the use of type long as a bitfield type under the 32-bit or wide data model to type int.
Converting C-Series TNS Programs to Use the Current TNS Compiler For the current compilers, the compiler treats a literal string as a preprocessor token of the substitution list. The literal string is not scanned.
Converting C-Series TNS Programs to Use the Current TNS Compiler ISO/ANSI C standard does not specify GMT. However, virtually all software vendors use GMT, therefore, the HP implementation has changed. Greenwich Mean Time is also called Coordinated Universal Time (UTC).
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.
Migrating Programs to TNS/R or TNS/E Native Mode For detailed information on: • • Running the migration tool and on migrating TNS programs to TNS/R native mode, see the TNS/R Native Application Migration Guide. Migrating TNS/R programs to TNS/E native mode, see the H-Series Application Migration Guide.
12 Preprocessor Directives and Macros • • • • • • • • • • • • Directive #define on page 12-2 Directive #error on page 12-3 Directives #if, #elif, #ifdef, #ifndef, #else, and #endif on page 12-4 Directive #include on page 12-7 Directive #line on page 12-10 Directive #pragma on page 12-10 Directive #undef on page 12-10 Predefined Macros on page 12-11 Predefined Symbols on page 12-12 Variadic Macros on page 12-12 Feature-Test Macros on page 12-13 Preprocessor Operators on page 12-16 The preprocessor is a mac
Preprocessor Directives and Macros #define #define The #define directive defines a macro, providing it with a name (an identifier) and the replacement list that the name represents. The macro can be either object-like or function-like, depending on how you define it.
Preprocessor Directives and Macros • • #error Unless you delete a macro definition, it remains in effect for the remainder of the translation unit. Avoid invoking macros with arguments that cause side effects. When the macro evaluates an argument more than once, it also produces the side effect more than once, sometimes with unexpected results.
Preprocessor Directives and Macros #if, #elif, #ifdef, #ifndef, #else, and #endif 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.
Preprocessor Directives and Macros { { { { #if int-constant-expression #elif int-constant-expression #ifdef identifier #ifndef identifier #if, #elif, #ifdef, #ifndef, #else, and #endif } newline [ source-text ] } } } #else-group: #else newline [ source-text ] #if int-constant-expression newline [ source-text ] introduces an if section that conditionally includes source text based on the value of a constant expression.
Preprocessor Directives and Macros #if, #elif, #ifdef, #ifndef, #else, and #endif #endif newline terminates the if section. The new line following the #endif directive terminates the directive line. Usage Guidelines • • • When using the if directives, remember to distinguish between macro definitions and function definitions; the #ifdef and #ifndef directives test only macro definitions.
Preprocessor Directives and Macros #include The compiler ignores the source text following the #ifdef TNS directive because TNS is undefined: #define PC 1 #ifdef TNS /* HP Tandem dependent code. */ printf("This program executes on the server.\n"); #endif #ifdef PC /* pc dependent code. */ printf("This program executes on the pc.\n"); #endif 4. This example shows how the #ifndef directive works.
#include Preprocessor Directives and Macros In the OSS environment, the compiler searches for source_file using operands specified in the c89 utility -I flag. library_header_file is the name of the library header file you want to include. The compiler assumes that library header files reside in the same volume and subvolume (in the Guardian environment) or directory (in the OSS environment) as the compiler.
#include Preprocessor Directives and Macros In RVUs preceding D30.00, if the #include specification was of the form #include "subvolume.file", the Guardian compiler checked for the subvolume in the current volume by default. Beginning with D30.00, you must specify the default volume using an SSV pragma. • If you need more than one physical line to complete the section list, place a backslash (\) at the end of all but the last line of the list.
Preprocessor Directives and Macros #line #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, then 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.
Preprocessor Directives and Macros Predefined Macros Example To delete the macro definition with identifier red and print “Red is undefined.”: #define red 1 /* ... */ #undef red #ifdef red printf("Red is defined.\n"); #else printf("Red is undefined.\n"); #endif Predefined Macros The compiler provides six predefined object-like macros. These macros expand to various statistics regarding compilation, as shown in Table 12-2, Predefined Macros.
Preprocessor Directives and Macros Predefined Symbols void foo (void) { printf ("Entering function %s\n", __FUNCTION__); printf ("ch[] was in function \"%s\"\n", ch); }; int main (void) { foo (); } The output from the preceding code is: Entering function foo ch[] was in function "" Predefined Symbols The compiler provides three predefined preprocessor symbols: __TANDEM, __INT32, and __XMEM. You can use the __TANDEM symbol to increase the portability of your programs.
Feature-Test Macros Preprocessor Directives and Macros D("EDG\n"); /* Expands to "printf("EDG\n", );" -- note the extra comma*/ • The other variant of variadic macro is the GNU form, provided by the GNU C compiler. This variant adds to the C9X form the ability to name the variadic parameter and a special meaning to the token pasting operator ("##").
Feature-Test Macros Preprocessor Directives and Macros Table 12-3. Predefined Feature-Test Macros (page 2 of 2) Macro What It Defines _IGNORE_LOCALE Identifiers that do not support internationalization and support the C/POSIX locale only _OSS_HOST Identifiers used by the C compiler running in the OSS environment _OSS_TARGET Identifiers required for executing in the OSS environment _POSIX_C_SOURCE=1 Identifiers required or permitted by the POSIX.
Preprocessor Directives and Macros Feature-Test Macros The _TANDEM_SOURCE macro makes supplementary functions defined by HP for NonStop systems. If a module compiled for the OSS environment uses functions defined by HP, you must specify the _TANDEM_SOURCE macro. The _XOPEN_SOURCE macro makes visible functions defined by either the XPG4 or XPG4 Version 2 specifications.
Preprocessor Directives and Macros Preprocessor Operators The ENV pragma setting determines which of these native mode feature-test macros is defined: _COMMON Identifies code that runs with pragma ENV COMMON set. Pragma ENV COMMON is the default setting. Such code runs in the user code space and requires the Common Run-Time Environment (CRE). _EMBEDDED Identifies code that runs with pragma ENV EMBEDDED set. Such code runs in the system code space and cannot use the Common RunTime Environment (CRE).
Preprocessor Directives and Macros Preprocessor Operators to be expanded into: "testing" Operator ## The binary operator ## is used in both object-like and function-like macros. It allows you to concatenate two tokens, and therefore it cannot occur at the beginning or at the end of the macro definition. If a formal parameter in a macro definition is preceded or followed by the ## operator, the formal parameter is immediately replaced by the unexpanded actual argument.
Preprocessor Directives and Macros Preprocessor Operators HP C/C++ Programmer’s Guide for NonStop Servers— 429301-002 12 -18
13 Compiler Pragmas Compiler pragmas enable you to control various elements of compiler listings, code generation, and building of the object file.
Compiler Pragmas Table 13-1. Compiler Pragma Descriptions (page 2 of 7) Pragma Purpose CALL_SHARED Directs the native compilers to generate PIC (PositionIndependent 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. COLUMNS Specifies the maximum logical line length of the source file. CPATHEQ Specifies a file to be included before the compiler begins compiling the source file.
Compiler Pragmas Table 13-1. Compiler Pragma Descriptions (page 3 of 7) 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.
Compiler Pragmas Table 13-1. Compiler Pragma Descriptions (page 4 of 7) Pragma Purpose LINES Specifies the maximum number of output lines per page for the compiler listing file. LINKFILE Invokes the appropriate linker and specifies a command file to be passed. LIST Controls the generation of compiler-listing text. LMAP Controls the generation and presentation of load-map information in the compiler listing. MAP Controls the generation of identifier maps in the compiler listing.
Compiler Pragmas Table 13-1. Compiler Pragma Descriptions (page 5 of 7) Pragma Purpose OPTIMIZE Controls the level to which the compiler optimizes the object code. OVERFLOW_TRAPS Determines whether the native C and C++ compilers generate code with arithmetic overflow traps. PAGE Causes a page eject in the compiler listing and prints a page heading. POOL_STRING_LITERALS Specifies that within a compilation unit multiple occurrences of the same string literal are to occupy the same storage space.
Compiler Pragmas Table 13-1. Compiler Pragma Descriptions (page 6 of 7) Pragma Purpose SRLExportClassMembers Controls which members of a class are exported from an SRL or user library (a private shared run-time library). This pragma is valid only for TNS/R compilers. SRLExports Specifies that a definition of an external function or external variable is exported from an SRL or user library (a private shared run-time library). This pragma is valid only for TNS/R compilers.
ALLOW_CPLUSPLUS_COMMENTS Compiler Pragmas Table 13-1. Compiler Pragma Descriptions (page 7 of 7) Pragma Purpose VERSION2 Directs the native C++ compiler to compile using the dialect or features available beginning with the D45 version of the HP C++ language. VERSION3 Directs the native C++ compiler to compile according to the G06.20 version or dialect of C++. Enables all new features added at the G06.20 RVU and enforces the ISO/IEC IS 14882-1998 standard.
ALLOW_EXTERN_EXPLICIT_INSTANTIATION Compiler Pragmas • When you use the ALLOW_CPLUSPLUS_COMMENTS directive, your native mode C program can include the comment delimiter that is standard in C++, namely, the double slash (//). 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.
ANSICOMPLY Compiler Pragmas ANSICOMPLY The ANSICOMPLY pragma directs the TNS C compiler to perform strict syntax checking for compliance to the ISO/ANSI C standard. ANSICOMPLY 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 N.A. N.A. Native c89 utility N.A. N.A. TNS/E native C and C++ compilers N.A. N.A.
ANSISTREAMS Compiler Pragmas ANSISTREAMS The ANSISTREAMS pragma specifies that Guardian files created by the program, including the standard files (standard input, standard output, and standard error), are odd-unstructured disk files with a file code of 180. The maximum length of a line for type 180 files is the maximum size of a file. If this pragma is not asserted, files are EDIT files with a file code of 101.
BUILD_NEUTRAL_LIBRARY Compiler Pragmas BUILD_NEUTRAL_LIBRARY The BUILD_NEUTRAL_LIBRARY pragma directs the native compilers to create a C++ library using only those components common to the VERSION2 and VERSION3 standard libraries and to set the CPPNEUTRAL flag in the linkfile. This pragma allows you to create a dynamic-link library that does not have a dependency on a specific version of the C++ libraries.
CALL_SHARED Compiler Pragmas 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.
CALL_SHARED Compiler Pragmas • • • • ° If you specify -Wcall_shared, the compilation results in a PIC executable object file (a PIC loadfile). ° If you specify the -c option with -Wcall_shared, the linker is not called, and the result is a PIC linkable object file (a PIC linkfile). If you specify the CALL_SHARED pragma, the compiler driver passes the following to the eld or ld linker: ° For a TNS/R program, CCPPMAIN (on Guardian) or ccppmain.
CHECK Compiler Pragmas CHECK The CHECK pragma controls the inclusion of run-time error-checking code in the object file. The CHECK pragma directs the TNS C compiler to include these run-time checks, and NOCHECK directs it to omit them. [NO]CHECK The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler CHECK NOCHECK G-series TNS c89 utility CHECK NOCHECK TNS/R native C and C++ compilers N.A. N.A. Native c89 utility N.A. N.A. TNS/E native C and C++ compilers N.A. N.A.
COLUMNS Compiler Pragmas COLUMNS The COLUMNS pragma specifies the maximum logical line length of the source file. COLUMNS last-column last-column specifies the last column in a source line to process. The compiler ignores any text in the line beyond this column. last-column must be in the range 20–32767.
CPATHEQ Compiler Pragmas ° In all other cases, the last-column value is set by the most recently processed COLUMNS pragma. CPATHEQ The CPATHEQ pragma specifies a file to be included before the compiler begins compiling the source file. The CPATHEQ file is an EDIT file that typically contains MAPINCLUDE pragmas to submit to the C or C++ compiler.
CPPONLY Compiler Pragmas CPPONLY The CPPONLY pragma causes only the C macro preprocessor to be run. CPPONLY [ (option [, option] ) ] option: { [no]comments | [no]lines | file "file-name" } [no]comments specifies whether comments are preserved in the preprocessed file. [no]lines specifies whether #line directives are generated in the preprocessed file. file "file-name" specifies a Guardian type-180 file to receive the preprocessed output. Quotation marks are required delimiters around the file name.
CSADDR Compiler Pragmas 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. The CSADDR pragma is intended for functions compiled under the ENV LIBRARY or ENV LIBSPACE pragma.
ELD(arg) Compiler Pragmas ELD(arg) The ELD pragma specifies arguments to be passed to the eld utility, the TNS/E linker for PIC (Position-Independent Code). ELD(arg) arg is any argument accepted by the eld utility. For details on valid syntax and semantics, see the eld Manual. 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 N.A. N.A.
ENV Compiler Pragmas COMMON specifies that the module requires the Common Run-Time Environment (CRE). The module can be called by routines written in any language that runs in the CRE. Use this option for user code functions that run in the CRE. For the native C and C++ compilers, this option sets the _COMMON feature-test macro. EMBEDDED specifies that the module does not require resources provided by the CRE and that it meets the requirements to run in the system code space.
ENV Compiler Pragmas The module can be called from routines written in any language, regardless of whether the routines run in the CRE. It is intended for system-level programming. For additional considerations, see Section 9, System-Level Programming. For the native C and C++ compilers, this option sets the _LIBSPACE feature-test macro.
ERRORFILE Compiler Pragmas • • • • • • For TNS C and C++, pragmas ENV LIBRARY and ENV LIBSPACE restrict relocatable data blocks. Without relocatable data blocks, static data is not allowed. Thus, 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.
ERRORFILE Compiler Pragmas SYSTYPE GUARDIAN SYSTYPE OSS TNS/R native C and C++ compilers Not set Not set Native c89 utility Not applicable Not applicable TNS/E native C and C++ compilers Not set Not set Usage Guidelines • • • • • The ERRORFILE pragma can appear only on the RUN command line (not in the source file) for NMC or NMCPLUS (G-series Guardian) or for CCOMP or CPPCOMP (H-series Guardian). The effect of the ERRORFILE pragma can be achieved with the 2> operand of the c89 utility.
ERRORS Compiler Pragmas ERRORS The ERRORS pragma directs the compiler to terminate compilation if it detects more than a specified number of errors. ERRORS max-errors max-errors specifies the maximum number of errors that the compiler is to generate before terminating the compilation. The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler Not set for C N.A. for C++ Not set for C N.A. for C++ G-series TNS c89 utility Not set for C N.A. for C++ Not set for C N.A.
EXTENSIONS Compiler Pragmas EXTENSIONS The EXTENSIONS pragma allows source code to use syntax extensions and standard library extensions defined by HP. [NO]EXTENSIONS 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.
EXTENSIONS Compiler Pragmas • • The native mode C++ compiler expects ANSI-compliant code unless you include the EXTENSIONS pragma. To avoid warnings or errors on features that are not strictly ANSI-compliant, you must use the EXTENSIONS pragma on the command line.
EXTENSIONS Compiler Pragmas ° 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. Such names are in a namespace distinct from all other names, including macro names.
EXTERN_DATA Compiler Pragmas EXTERN_DATA The EXTERN_DATA pragma specifies whether external data references (object declared extern) can use GP-relative addressing. EXTERN_DATA value [variable-name [,variable-name]] value: { GP_OK | NO_GP } GP_OK means that GP-relative addressing is allowed. This value is not valid for the TNS/E compilers. NO_GP means that GP-relative addressing must not be used. This is the value that typically indicates that the data is exported by an SRL.
FIELDALIGN Compiler Pragmas pragma is combined with the SHARED pragma or CALL_SHARED, and ignores the GP_OK directive. The TNS/E compiler ignores this directive. • Specifying EXTERN_DATA GP_OK as the global default might prevent some ISO/ANSI C Standard conforming programs from linking successfully. This might occur if the user program uses SRL data but does not use the correct header file to declare the SRL data.
FIELDALIGN Compiler Pragmas align-attribute specifies the alignment rules for the compiler to follow. Valid values are: AUTO directs the compiler to choose the layout scheme. The compiler might add implicit (anonymous) fillers to ensure that components are properly aligned. This is the default alignment. The TNS C compiler and the native C and C++ compilers have different AUTO alignment rules.
FIELDALIGN Compiler Pragmas SYSTYPE GUARDIAN SYSTYPE OSS TNS/R native C and C++ compilers FIELDALIGN AUTO FIELDALIGN AUTO Native c89 utility 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.
FIELDALIGN Compiler Pragmas • • • • SHARED8 requires that you explicitly declare any filler needed to properly align fields. The compiler issues a warning for improperly aligned fields in a SHARED8 structure. For more details on structure alignment, refer the pTAL Conversion Guide and pTAL Reference Manual.
FIELDALIGN Compiler Pragmas 3. In this example, pragma FIELDALIGN SHARED2 causes all structures in the compilation unit to be the same as TAL’s definition structures, except for any structure with the tag CTAG, whose members always are 16-bit word-aligned. #pragma fieldalign shared2 #pragma fieldalign auto CTAG ... struct CTAG { ... } cstruct; ... 4.
FORCE_VTBL Compiler Pragmas FORCE_VTBL The FORCE_VTBL command-line option forces definition of virtual function tables in cases where the heuristic used by the compiler to decide on definition of virtual function tables provides no guidance. The default behavior is to make the definition a local static entity. This option is valid only for native C++. FORCE_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.
FORCE_STATIC_VTBL Compiler Pragmas SYSTYPE GUARDIAN SYSTYPE OSS TNS/R native C and C++ compilers Not set Not set Native c89 utility Not set Not set TNS/E native C and C++ compilers N.A. N.A. Usage Guidelines • • FORCE_STATIC_TYPEINFO can be entered on the compiler RUN command line (NMCPLUS) or be specified with the -Wforce_static_typeinfo flag of the c89 utility. This pragma is only valid for TNS/R-target compilations.
FUNCTION Compiler Pragmas FUNCTION The FUNCTION pragma declares attributes of external routines. The FUNCTION pragma is used at function declaration, not at function definition.
FUNCTION Compiler Pragmas Use alias to describe the name of a function written in COBOL, FORTRAN, D-series Pascal, or TAL that does not have a valid C name. resident causes the function code to remain in main memory for the duration of program execution. The operating system does not swap pages of this code. Binder or a linker allocate storage for resident functions as the first functions in the code space.
FUNCTION Compiler Pragmas 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 utility Not set Not set TNS/E native C and C++ compilers Not set Not set Usage Guidelines • • • • • • • • • • • • • • The FUNCTION pragma can be entered on the compiler RUN command line or in the source text.
HEADERS Compiler Pragmas ° ° ° 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.
HEAP Compiler Pragmas • If both pragmas CPPONLY and HEADERS are specified, CPPONLY takes precedence. HEAP The HEAP pragma specifies the maximum heap size of a program compiled with the RUNNABLE pragma. HEAP count [ { BYTES | PAGES | WORDS } ] count [ { BYTES | PAGES | WORDS } ] specifies the maximum size of the heap in terms of a number of units of a given size. count specifies the number of units, and the keyword following count specifies the size of each unit.
HEAP Compiler Pragmas • For native C and C++ programs, you should not specify the HEAP pragma unless there is an unusual reason to limit the heap size to less than the capacity of the program address space. The HEAP pragma specifies an upper bound on heap size by setting the heap_max attribute in a new loadfile; for example, specifying HEAP n BYTES is equivalent to specifying -set heap_max n to the eld linker for the loadfile. You do not need to recompile to change the setting.
HIGHPIN Compiler Pragmas 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)..
HIGHREQUESTERS Compiler Pragmas If these four conditions are met, the operating system assigns a high PIN, if available. If no high PINs are available, the operating system assigns a low PIN.
ICODE Compiler Pragmas The HIGHREQUESTERS attribute is set for native C and C++ programs only if an executable object file is the output of the compilation. (Process attributes cannot be set for native relinkable object files.) • • You can set the HIGHREQUESTERS object-file attribute either during compilation using the HIGHREQUESTERS pragma or after compilation using the Binder SET command (for TNS programs) or the eld, ld, or nld utility (for native programs).
IEEE_FLOAT Compiler Pragmas IEEE_FLOAT The IEEE_FLOAT directive specifies that the native C and C++ compilers use the IEEE floating-point format for performing floating-point operations. Compare to pragma TANDEM_FLOAT on page 13-102. IEEE_FLOAT 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.
IEEE_FLOAT Compiler Pragmas • ° IEEE floating-point default handling of overflow, underflow, divide-by-zero, and invalid operation is better than the Tandem floating-point handling. ° ° IEEE floating-point default rounding mode gives more accurate results. ° IEEE floating-point denormalized numbers avoid computational problems that arise from very small numbers as intermediate results in computations.
IEEE_FLOAT Compiler Pragmas • • In addition to the differences shown in Table 13-4, note the following: ° 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. ° For the double type in IEEE floating-point format, the smallest positive nonzero number is approximately 4.9406564584124654E-324. This is a denormalized number.
INLINE Compiler Pragmas INLINE For TNS C programs, the INLINE pragma controls whether the compiler generates inline code for certain standard library functions instead of generating a function call. INLINE directs the compiler to generate inline code. NOINLINE directs the compiler to revert to the library function call. For native C++ programs, the INLINE pragma controls whether functions declared inline are actually generated inline. NOINLINE suppresses inline generation of all functions.
INLINE_COMPILER_GENERATED_FUNCTIONS Compiler Pragmas standard ANSI code. It is necessary to revert to non-inline mode in order to execute the locally defined function. • The following example, which applies only to TNS C and C++, shows how to mix the inlined standard definition of strlen and a local version of strlen.
INLINE_LIMIT Compiler Pragmas INLINE_LIMIT The INLINE_LIMIT command-line option specifies the maximum number of lines that the compiler can inline. INLINE_LIMIT n n denotes the number of lines as an integer. If n is 0, there is no limit on the number of lines that the compiler can inline. n should be in the range 0 through 2147483647. 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.
INNERLIST Compiler Pragmas Usage Guidelines • • • INLINE_STRING_LITERALS can be entered on the compiler RUN command line (NMCPLUS) or be specified with the -Winline_string_literals flag of the c89 utility. If a function is inlined by this specification, its program will not conform to section 7.1.2 of the 1998 ISO C++ standard. This pragma is only valid for TNS/R-target compilations.
INSPECT Compiler Pragmas 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 Compiler Pragmas • The debugging utility selected by INSPECT and NOINSPECT varies by system, environment, and available subsystem, as follows: ° For a TNS process: • • NOINSPECT selects, in order of precedence: G-series H-series DEBUG Inspect Native Inspect INSPECT selects, in order of precedence: G-series H-series Visual Inspect Inspect Visual Inspect Inspect Native Inspect DEBUG ° For a native process: • • NOINSPECT selects, in order of precedence: G-series H-series DEBUG Na
KR Compiler Pragmas KR The KR pragma specifies to the native C compiler that Kernighan & Ritchie or common-usage C is being compiled instead of ISO/ANSI Standard C. KR 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.
LARGESYM Compiler Pragmas LARGESYM The LARGESYM pragma directs the TNS C compiler and Cfront to generate all the symbols for a given compilation to a single symbols data block containing information used by the Inspect debugger to display information about a variable or to display its contents. You must also specify the SYMBOLS pragma when you specify LARGESYM.
LD(arg) Compiler Pragmas the declarations for the structure worddef. When you try to display a variable of type worddef in the Inspect debugger, the debugger might display the wrong information. LD(arg) The LD pragma specifies arguments to be passed to the ld utility, the TNS/R linker for PIC (Position-Independent Code). LD(arg) arg is any argument accepted by the ld utility. For details on valid syntax and semantics, see the ld Manual.
LINES Compiler Pragmas 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.
LIST Compiler Pragmas 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 applicable Not applicable TNS/E native C and C++ compilers Not set Not set Usage Guidelines • On Guardian, the LINKFILE pragma must be entered on the compiler RUN command line for native C and C++.
LMAP Compiler Pragmas Usage Guideline The LIST and NOLIST pragmas can be entered on the compiler RUN command line or in the source text. LMAP The LMAP pragma controls the generation and presentation of load-map information in the compiler listing. The LMAP pragma enables load-map generation and specifies how to present the load maps. NOLMAP disables generation of load maps or disables one form of load-map presentation.
MAP Compiler Pragmas Usage Guidelines • For the TNS C compiler, the LMAP pragma can be entered on the compiler RUN command line or in the source text. For OSS, the LMAP pragma must be entered in the source file. • The native C and C++ compilers do not support this pragma. Native compilers do not generate load map information. MAP The MAP pragma controls the generation of identifier maps in the compiler listing. The MAP pragma enables generation of identifier maps, and NOMAP disables it.
MAPINCLUDE Compiler Pragmas MAPINCLUDE The MAPINCLUDE pragma specifies how to transform file names within #include directives. MAPINCLUDE [ FILE | PATH ] "from" = "to" The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS 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 utility N.A. N.A.
MAXALIGN Compiler Pragmas ° The following MAPINCLUDE pragma changes only the exact file name n.h and does not affect the file name machin.h: mapinclude "n.h" = "e95nh" ° The following MAPINCLUDE pragma with the FILE option changes the file name machin.h to machie9h after file-name compression. This is because the original file name ends in n.h: MAPINCLUDE FILE n.h = e95nh However, the file name n.h is not affected by this MAPINCLUDE because it does not end with the from string. In fact, the name n.
MIGRATION_CHECK Compiler Pragmas }; // Aligned at 16 bytes, with size 16 bytes and // 8 bytes of padding at the end MIGRATION_CHECK The MIGRATION_CHECK pragma directs the TNS/R native C++ compiler to perform a migration check, to aid in migrating from VERSION2 of the Standard C++ Library to VERSION3.
NEST Compiler Pragmas • MIGRATION_CHECK must be used with the VERSION2 command-line directive. If it is used with VERSION1 or VERSION3 (or if no version is specified), the following error is output to the home terminal and to the compilation listing if it is enabled: ***Error: MIGRATION_CHECK option only allowed with version2. • • • The source code to be analyzed must be error-free, valid VERSION2 C++ source. No migration check is available for migrating from VERSION1 to VERSION3.
NEUTRAL Compiler Pragmas Usage Guidelines • • For the TNS C compiler, the NEST pragma can be entered on the compiler RUN command line or in the source text. For OSS, the pragma can be entered only in the source file. The native C and C++ compilers do not support the NEST pragma. The ISO/ANSI C Standard does not support nested comments.
NLD(arg) Compiler Pragmas class bad_exception() class bad_typeid() • Storage allocation and exception handling are common ( except for the classes defined in the stdexcept header ). Example See Using the Neutral C++ Dialect on page 5-13. NLD(arg) The NLD command-line directive specifies arguments to be passed to the nld utility, the linker for TNS/R native code that is not PIC (Position-Independent Code). NLD(arg) arg is any argument accepted by the nld utility.
NOEXCEPTIONS Compiler Pragmas ° ° CALL_SHARED SHARED Example The following command invokes the TNS/R native mode C compiler and uses the NLD directive to pass options to the nld utility: nmc /in prog1/ prog1o;nld(-set highpin off -set highrequester off),runnable NOEXCEPTIONS The NOEXCEPTIONS compiler directive directs the native C++ compiler to disable support for exceptions and exception handling. NOEXCEPTIONS The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A.
NON_SHARED Compiler Pragmas NON_SHARED The NON_SHARED pragma directs the native C and C++ compilers to generate nonshared 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.
OLDCALLS Compiler Pragmas OLDCALLS The OLDCALLS pragma controls how the TNS C compiler generates code for function calls. [NO]OLDCALLS 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.
OLIMIT Compiler Pragmas OLIMIT The OLIMIT directive specifies the maximum decimal number of basic blocks of a routine that the global optimizer is to optimize. When a routine has more basic blocks than this number, the routine is not optimized and a warning is printed. OLIMIT value value is the number of basic blocks of a routine that are to be optimized. Specify a value between 0 and 32767. The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler N.A. N.A.
ONCE Compiler Pragmas ONCE The ONCE pragma specifies that the file containing this pragma will be compiled only once during the compilation, even if it is included multiple times. ONCE There is no default setting for this pragma. Usage Guidelines • • • This pragma applies to native commpilations only. The ONCE pragma can be specified only in the source code. Use the ONCE pragma only in header files. Note. Do not use the #pragma ONCE in a header file that contains the #pragma SECTION.
OPTIMIZE Compiler Pragmas • • • 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. The optimizer file can raise or lower the optimize level for the given functions; the other functions in the module are compiled at the optimization level specified in the RUN command line, if any is specified, or at the default level if no level is specified.
OVERFLOW_TRAPS Compiler Pragmas Because it does not affect statement 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.
OVERFLOW_TRAPS Compiler Pragmas 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 NOOVERFLOW_TRAPS NOOVERFLOW_TRAPS Native c89 utility NOOVERFLOW_TRAPS NOOVERFLOW_TRAPS TNS/E native C and C++ compilers NOOVERFLOW_TRAPS NOOVERFLOW_TRAPS Usage Guidelines • • • • The OVERFLOW_TRAPS pragma can be entered on the compiler RUN command line or in the source text.
PAGE Compiler Pragmas 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. The title string can contain up to 61 characters. There is no default setting for this pragma.
POP Compiler Pragmas 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.
REFALIGNED Compiler Pragmas REFALIGNED The REFALIGNED pragma specifies the default reference alignment for pointers in native C and C++ programs. REFALIGNED value [ pointer-name-list ] value: { 2 | 8 } pointer-name-list: pointer-name [ pointer-name-list ] pointer-name: { type-name | variable-name } 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.
REMARKS Compiler Pragmas • • • • Pragma REFALIGNED without a pointer-name-list specifies the default alignment for the entire compilation and can be used in the command line or in the source text. A global REFALIGNED pragma affects only pointers that do not point to classes, structs, or unions. If you declare a TYPEDEF and it is of a type that has been given an explicit reference alignment, then that REFALIGNED value is propagated to the new TYPEDEF.
RUNNABLE Compiler Pragmas RUNNABLE The RUNNABLE pragma directs the compiler to generate an executable object file instead of a linkable object file for a single-module program. RUNNABLE The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS 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 utility N.A. N.A.
RUNNAMED Compiler Pragmas RUNNAMED The RUNNAMED pragma specifies that the object file runs as a named process, even if you do not specify the NAME option in the RUN command.
SAVEABEND Compiler Pragmas • • 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. A named process running at a high PIN can be opened with the Guardian OPEN system procedure by an unconverted process running at a low PIN. For example, a named server process can be opened by an unconverted requester process.
SAVEABEND Compiler Pragmas Usage Guidelines • • • • • • • The SAVEABEND pragma can appear only on the compiler RUN command line for native C and C++. On TNS, the pragma can only be specified with the c89 -W[no]saveabend flag. The SAVEABEND attribute is set for native C and C++ programs only if an executable object file is the output of the compilation. (Process attributes cannot be set for native relinkable object files.
SEARCH Compiler Pragmas SEARCH For TNS programs, the SEARCH pragma directs the Binder to search a given object file when attempting to resolve external references in a program compiled with the RUNNABLE pragma. For native programs compiled with the RUNNABLE pragma, the SEARCH pragma directs the nld utility (for conventional code) or the eld or ld utility (for PIC code) to link in the entire given object file (not just the procedure that contains the external reference).
SECTION Compiler Pragmas SECTION The SECTION pragma gives a name to a section of a source file for use in an #include directive. Sections enable you to include only a portion of a file. SECTION sec-name sec-name is a valid C identifier to associate with all source text that follows the SECTION pragma until another SECTION pragma or the end of the source file. There is no default setting for this pragma. Usage Guidelines • • The SECTION pragma can appear only in the source text.
SHARED Compiler Pragmas SHARED The SHARED pragma directs the native C and C++ compilers to generate shared code, which is PIC (Position-Independent Code) and to invoke the ld or eld linker to create a PIC library file, or a dynamic-link library (DLL). Compare the action of SHARED with that of the two related pragmas: • • CALL_SHARED directs the compiler to generate PIC. NON_SHARED directs the compiler to generate a non-PIC loadfile that cannot be shared and cannot access PIC files.
SQL Compiler Pragmas ° ° ° • eld Manual ld Manual rld Manual The SHARED pragma cannot be used with the CALL_SHARED, 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 compiler issues a warning if this pragma is combined with the SHARED pragma or CALL_SHARED, and ignores the gp_ok directive. SQL The SQL pragma enables the compiler to process subsequent SQL statements.
SQL Compiler Pragmas RELEASE1 | RELEASE2 specifies the earliest release of NonStop SQL/MP that supports the features used in the embedded SQL statements. If you do not specify either RELEASE1 or RELEASE2, the C compiler uses the version of SQL that is installed on the compilation system. The latest current version of SQL is 345. RELEASE1 specifies that the embedded SQL statements require features first available in NonStop SQL Release 1.
SQL Compiler Pragmas SYSTYPE GUARDIAN SYSTYPE OSS 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++ TNS/E native C and C++ compilers Not set for C, N.A. for C++ Not set for C, N.A.
SQLMEM Compiler Pragmas SQLMEM The SQLMEM pragma provides the ability to alter the placement of SQL data structures from extended memory to the user data segment. The default setting is SQLMEM EXT. 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.
SRL Compiler Pragmas SRL The SRL pragma specifies that a module is being compiled to link into a TNS/R native user library. (A TNS/R native user library is a private shared run-time library (SRL). SRL 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 TNS/E native C and C++ compilers N.A. N.A.
SRLExportClassMembers Compiler Pragmas item_list: item | item_list , item item: is a member of the class. This pragma has no default settings. Usage Guidelines • The SRLExportClassMembers pragma is used to specify which members of a class are exported from an SRL. Exporting a member function from an SRL means that the member function definition is provided by the SRL. The SRL's clients should never have a copy (inlined or non-inlined) of the function definition within the client's code.
SRLExports Compiler Pragmas SRLExports The SRLExports pragma specifies that a definition of an external function or external variable is exported from an SRL or a user library (a private shared run-time library). This pragma sets the srl_export bit for the definition in the object file. When this object file is linked, nld automatically adds any items which have this bit set to the export list of the SRL. The SRLExports pragma is supported for TNS/R native C and C++ only.
SRLName Compiler Pragmas SRLName The SRLName pragma is used to "name" an SRL or a user library (a private shared run-time library). This pragma is supported for TNS/R native C++ only. SRLName srl_id srl_id: is the name of the SRL. There is no default setting for this pragma. Usage Guidelines • • • This pragma is valid only for TNS/R-targetted compilations. The SRLName pragma is used to determine whether a SRLExportClassMembers pragma provides a definition or a declaration for its exported functions.
SSV Compiler Pragmas To compile: c89 -Wsrl -c SRL_1.C // client.C #include "inc.h" // Member functions exported by s are // only declared - no definition is provided. To compile: c89 client.C SRL_1.o SSV The SSV pragma specifies a list of search subvolumes (SSVs) to be searched for files specified in #include directives. SSV pragmas on the command line take precedence over SSV pragmas in source files; that is, those in source files are appended to those from the command line.
SSV Compiler Pragmas The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler Current subvolume and then compiler subvolume Current subvolume and then compiler subvolume G-series TNS c89 utility Not applicable Not applicable TNS/R native C and C++ compilers Current subvolume and then compiler subvolume Current subvolume and then compiler subvolume Native c89 utility Not applicable Not applicable TNS/E native C and C++ compilers Current subvolume and then compiler subvolu
SSV Compiler Pragmas On the other hand, if you enter the preceding SSV pragma list on the command line, only the first SSV is set; the others are ignored because of the numerical gap. • • The native compilers also support the setting of SSVs using ASSIGN statements. If you use both ASSIGNs and command-line SSV pragmas, the two sets are unioned together. If the two sets have any duplicate SSV numbers, the SSV specified in the command line is used.
STDFILES Compiler Pragmas STDFILES The STDFILES pragma controls the automatic opening of the three standard files: stdin, stdout, and stderr. The STDFILES pragma allows the C library to automatically open the three standard files. The NOSTDFILES pragma suppresses the automatic opening of these files. [NO]STDFILES 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.
STRICT Compiler Pragmas STRICT The STRICT pragma directs the TNS C compiler or Cfront to generate a warning if it encounters one of a number of valid, but questionable, syntactic or semantic constructs. STRICT 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 N.A. N.A. Native c89 utility N.A. N.A. TNS/E native C and C++ compilers N.A. N.A.
SUPPRESS Compiler Pragmas • The native C and C++ compilers do not support this pragma. Native compilers perform strict syntactic and semantic checking by default. SUPPRESS The SUPPRESS pragma controls the generation of compiler-listing text, regardless of the status of the LIST pragma.
SYMBOLS Compiler Pragmas SYSTYPE GUARDIAN SYSTYPE OSS TNS/R native C and C++ compilers Not set Not set Native c89 utility Not set Not set TNS/E native C and C++ compilers Not set Not set Usage Guidelines • • SUPPRESS_VTBL can either be entered on the compiler RUN command line (CPPCOMP or NMCPLUS) or be specified with the -Wsuppress_vtbl option of c89. See also the description of the FORCE_VTBL command-line option.
SYNTAX Compiler Pragmas • • 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. SYNTAX The SYNTAX pragma directs the compiler to not generate an object file but merely to check the source text for syntactic and semantic errors.
TANDEM_FLOAT Compiler Pragmas Guardian Environment OSS Environment TNS/R native C and C++ compilers GUARDIAN N.A. Native c89 utility N.A. OSS TNS/E native C and C++ compilers GUARDIAN N.A. Usage Guidelines • • • • • The SYSTYPE pragma can be entered on the compiler RUN command line or be specified with the -Wsystype flag of the c89 utility. A SYSTYPE pragma in the source text does not change the target environment; it is only an affirmation of the target environment.
TRIGRAPH Compiler Pragmas SYSTYPE GUARDIAN SYSTYPE OSS TNS/R native C and C++ compilers TANDEM_FLOAT TANDEM_FLOAT Native c89 utility For TNS/R code: TANDEM_FLOAT For TNS/R code: TANDEM_FLOAT For TNS/E code: IEEE_FLOAT For TNS/E code: IEEE_FLOAT IEEE_FLOAT IEEE_FLOAT TNS/E native C and C++ compilers Usage Guidelines • • • • The TANDEM_FLOAT directive can be entered on the compiler RUN command line or with the -W Tandem_float flag of the c89 program. In RVUs preceding the G06.
VERSION1 Compiler Pragmas Usage Guidelines • • The TRIGRAPH pragma can be entered on the compiler RUN command line or in the source text. The native C and C++ compilers do not support this pragma. Native compilers always translate trigraphs. VERSION1 The VERSION1 pragma is a command-line directive for TNS/R native mode C++ that instructs the C++ compiler to compile using the D40 version or dialect of C++, rather than a more recent version. This pragma is not accepted by the TNS or TNS/E compilers.
VERSION1 Compiler Pragmas warning (for load files) from the linker, and a run-time error at load time from the NonStop operating system. • Using the VERSION1 directive with the D45 (or later) native C++ compiler produces an object file that is compatible with an object file produced by the D40 native C++ compiler but not compatible with an object file produced by the D45 (or later) native C++ compiler using the VERSION2 or VERSION3 directives.
VERSION2 Compiler Pragmas 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.
VERSION2 Compiler Pragmas These language features are part of the proposed C++ standard introduced by the Working Paper for Draft Proposed International Standard for Information Systems – Programming Language C++, 2 December 1996, X3J6/96-0225 WG21/N1043. If you want to use any of these VERSION2 features in an application originally compiled with any pre-D45 RVU of the TNS/R native C++ compiler, you must recompile and relink all modules of the program using the VERSION2 directive.
VERSION3 Compiler Pragmas • ZCPPCDLL and ZCPP2DLL (common C++ run-time library and VERSION2-specific C++ standard library) must be linked in by the user. For more information about the TNS/R SRLs, see Shared Run-Time Libraries (SRLs) on page 16-13. For more information about the TNS/E DLLs, see DynamicLink Libraries (DLLs) on page 17-13. VERSION3 The VERSION3 pragma is a command-line directive for native mode C++ that instructs the compiler to use the features of the G06.
VERSION3 Compiler Pragmas separated into three component libraries (ZCPPCDLL, ZCPP2DLL, and ZCPP3DLL) on H-series systems to implement the BUILD_NEUTRAL_LIBRARY pragma. For more information about the VERSION3 Standard C++ Library, see the Standard C++ Library Reference ISO/IEC (VERSION3) on the product documentation CD, the HP NonStop Technical Library (NTL). • • • • VERSION3 supports IEEE floating-point format. VERSION3 supports DLLs (Dynamic-Link Libraries) and Position-Independent Code (PIC).
WARN Compiler Pragmas or instead of: #include (Guardian) For VERSION3 you can use the standard header names without truncation as long as you also use the CPATHEQ file named SLMAP as described in Pragmas for the Standard C++ Library on page 5-12. • • The T2824 C++ headers include a few that end with .h (such as fstream.h and iomanip.h) for compatibility with previous C++ versions. If you include one of these .
WARN Compiler Pragmas warning-list is a parenthesized, comma-separated list of warning-message numbers. This list represents the warning messages whose generation the compiler is to enable or disable. If you omit warning-list, the WARN or NOWARN pragma affects all warning messages.
WIDE Compiler Pragmas WIDE The WIDE pragma specifies the data model, which defines the size of the data type int. The WIDE pragma specifies the 32-bit data model. NOWIDE specifies the 16-bit data model. (The 32-bit data model is also referred to as the wide-data model.) [NO]WIDE The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler Not set WIDE G-series TNS c89 utility WIDE WIDE TNS/R native C and C++ compilers N.A N.A. Native c89 utility N.A N.
XMEM Compiler Pragmas XMEM The XMEM pragma controls which memory model, large or small, the object file uses. The XMEM pragma specifies the large-memory model. NOXMEM specifies the smallmemory model. [NO]XMEM The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler XMEM XMEM TNS c89 utility XMEM XMEM G-series TNS c89 utility N.A N.A TNS/R native C and C++ compilers N.A N.A Native c89 utility N.A. N.A.
XVAR Compiler Pragmas XVAR The XVAR pragma controls whether the TNS C compiler places subsequent global or static aggregates in extended memory or in the user data segment. The XVAR pragma causes the TNS C compiler to allocate space in extended memory for any global or static aggregates that follow the pragma. NOXVAR causes the compiler to allocate space in the user data segment for any subsequent global or static aggregates.
14 Compiling, Binding, and Accelerating TNS C Programs • • • • Selecting a Development Platform on page 14-2 Specifying Header Files on page 14-3 Working in the Guardian Environment on page 14-4 ° Compiling a C Module on page 14-4 ° Binding a C Module on page 14-6 ° Specifying Library Files on page 14-8 ° Changes in Binding CLIB on page 14-9 ° Restrictions on Binding Caused by the ENV Pragma on page 14-10 ° Accelerating C Programs on page 14-11 Working in the OSS Environment on page 14-12 ° Versions of th
Compiling, Binding, and Accelerating TNS C Programs Selecting a Development Platform and OSS programs and produces identical code. However, each compiler has different default pragma settings. Selecting a Development Platform A development platform consists of the hardware system and software environment available to compile, bind, accelerate, and run a program. HP NonStop TNS systems support only the Guardian environment.
Compiling, Binding, and Accelerating TNS C Programs • Specifying Header Files You cannot use the SSV pragma. To specify search directories, use the TNS c89 -I flag. Specifying Header Files The macros and functions in the C run-time library are declared in header files. Each header file contains declarations for a related set of library functions and macros, as well as variables and types that complete that set.
Compiling, Binding, and Accelerating TNS C Programs Working in the Guardian Environment 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.
Compiling, Binding, and Accelerating TNS C Programs Compiling a C Module OUT listing specifies the file to which the C compiler writes the compiler listing. When specified, listing is usually a spooler location. If you omit the OUT option, the compiler writes the listing to your current default output file. run-options is a comma-separated list of additional options for the RUN command. These options are described in the TACL Reference Manual.
Compiling, Binding, and Accelerating TNS C Programs Binding a C Module Usage Guidelines • • • The C compiler accesses source files as text-type logical files. Consequently, the source files you specify in a module must represent physical file types that the compiler can access as text-type logical files. The C compiler accepts logical source lines of up to 509 characters. The C compiler returns one of these completion codes: 0 The compilation completed successfully.
Compiling, Binding, and Accelerating TNS C Programs Binding a C Module After starting Binder, you enter Binder commands to combine your object files and C run-time library object files to produce a program file.
Compiling, Binding, and Accelerating TNS C Programs Binding a C Module SELECT SEARCH model-dependent-library-file directs Binder to search the specified model-dependent library file when resolving external references. You choose the model-dependent library file depending on the execution environment, the data model, and the memory model of your program. For details on selecting the correct model-dependent library file, see Specifying Library Files on page 14-8.
Compiling, Binding, and Accelerating TNS C Programs Binding a C Module The COSS and CWIDE library files support the 32-bit data model. Bind OSS modules with COSS and bind Guardian modules with CWIDE. If you compile all modules in a program using the header files supplied by HP, you can bind using either COSS or CWIDE. If you do not use header files, you must bind using the library file that supports the module’s environment. You can only use static binding for Guardian programs.
Compiling, Binding, and Accelerating TNS C Programs Restrictions on Binding Caused by the ENV Pragma your BIND scripts to ensure that you do not bind in CLIB or CRELIB. Look for statements such as: 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.
Compiling, Binding, and Accelerating TNS C Programs Accelerating C Programs Table 14-4. Run-Time Environment Resulting From Binding Modules Binder Group Binder Group OLD COMMON NEUTRAL OLD language-specific Not allowed language-specific COMMON Not allowed CRE CRE NEUTRAL language-specific CRE language-specific or CRE Use the Binder INFO command with the DETAIL clause to show the ENV attribute of a particular data or code block. For more information, refer to the Binder Manual.
Compiling, Binding, and Accelerating TNS C Programs • Working in the OSS Environment Generate and retain the Binder and Inspect symbols regions for your programs. After accelerating a program, you can strip the symbols region from it without affecting performance. For a complete description of accelerating programs for TNS/R systems, refer to the Accelerator Manual. For a complete description of accelerating programs for TNS/E systems, refer to the Object Code Accelerator (OCA) Manual.
Compiling, Binding, and Accelerating TNS C Programs • Using the TNS c89 Utility C compiler The compiler translates the source text into object code. • Binder The Binder resolves external references to library routines and performs fixups to the object file. • Accelerator The Accelerator generates RISC instructions from the TNS object file. • SQL/MP compiler This compiler generates the appropriate code for embedded SQL/MP statements.
Compiling, Binding, and Accelerating TNS C Programs Using the TNS c89 Utility Table 14-6.
Compiling, Binding, and Accelerating TNS C Programs Binding an OSS TNS Module Table 14-6.
Compiling, Binding, and Accelerating TNS C Programs • • Examples of Working in the OSS Environment You cannot use an SRL for Guardian programs. Only OSS programs can use an SRL. You must bind internationalized programs using an SRL that supports internationalization. For details on binding internationalized programs, refer to the Software Internationalization Manual.
Compiling, Binding, and Accelerating TNS C Programs Examples of Working in the OSS Environment files in directory /usr/myself/header first, then it looks in /usr/friend, and finally it looks in /usr/include. Static binding has been specified, so the Binder tries to resolve references 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.
Compiling, Binding, and Accelerating TNS C Programs Examples of Working in the OSS Environment HP C/C++ Programmer’s Guide for NonStop Systems —429301-008 14 -18
15 Compiling, Binding, and Accelerating TNS C++ Programs • • Working in the Guardian Environment on page 15-1 ° C Preprocessor Cprep on page 15-3 ° C++ Translator Cfront on page 15-6 ° TNS C Compiler Run Command Syntax on page 15-8 ° File Formats on page 15-9 ° Compiling a Sample C++ Program on page 15-10 ° Error Messages in the Guardian Environment on page 15-11 ° Binding C++ Programs on page 15-12 Working in the G-Series OSS Environment on page 15-15 ° TNS c89 Flags on page 15-16 ° TNS c89 Operands on p
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment After compiling your C++ program, you run the Binder to create an executable C++ object file. This section describes a sample set of Binder commands that you can use to bind your C++ programs. You can use the Accelerator or OCA to make programs more efficient on native systems. The same rules that apply to accelerating C programs apply to accelerating C++ programs.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment C Preprocessor Cprep Cprep is a general-purpose C preprocessor.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment Generation of #line Directives Cprep generates #line directives indicating the original C++ source file, edit line number, and timestamp. These #line directives appear in the output from Cprep and are also propagated through to the output of Cfront. These #line directives are generated to support source-level debugging and to support generation of error messages from Cfront.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment define __cplusplus specifies to Cprep that it is processing a C++ program. compile-option modifies compiler operation by specifying a compiler pragma or defining a preprocessor symbol. SSV-pragma is a C compiler pragma that specifies a subvolume in which a header file is located. For details, see SSV on page 13-94. pragma is a C compiler pragma.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment To send error and warning messages to a file, assign stderr to the desired file name prior to invoking Cprep. You assign stderr to a file name as follows: ASSIGN STDERR, file-name To return to the default location, enter: CLEAR ASSIGN STDERR Example: In this example, the C++ source file progcp is input to Cprep. An intermediate file, intfile1, is created by Cprep for later use by Cfront.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment Pragma Use (continued) 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.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment To send error and warning messages to a file, assign stderr to the desired file name prior to invoking Cprep. You assign stderr to a file name as follows: ASSIGN STDERR, file-name To return to the default location, enter: CLEAR ASSIGN STDERR Example: • In this example, the intermediate file intfile1, which was previously created by Cprep, is now input to Cfront.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment Object specifies the file to which the TNS C compiler writes the TNS object code. If you do not specify an object file, the TNS C compiler writes the TNS object code to the file OBJECT in your current default volume and subvolume. If OBJECT cannot be created, the compiler writes the object code to the file ZZBInnnn (where nnnn is a unique four-digit number) in your current default volume and subvolume.
Compiling, Binding, and Accelerating TNS C++ Programs • Working in the Guardian Environment Terminals The input to Cprep is usually an EDIT file. The output of Cprep is a C++ source file, which is referred to in this section as an intermediate file. This intermediate C++ source file is by default a type 101 file and is used as the input to Cfront. The output of Cfront is a C source file, which is also referred to in this section as an intermediate file.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment cfront/in intfile1, out intfile2/ c/in intfile2, out $s.#hold/progo To run this program, enter: run progo The program will respond with the following: 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.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment Once Cfront recognizes errors, it stops emitting source code, and after a maximum of 13 errors, it stops compiling. When Cfront stops compiling, it terminates with the message Process terminated with fatal errors or diagnostics. Cfront's error and warning messages that appear in stderr are self-explanatory. Run-Time Error Messages C++ uses the TNS C run-time library.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment Binder Commands After starting Binder, you enter Binder commands to combine your compiled modules with the TNS C++ run-time library object files and with the TNS C run-time library object files to produce an executable C++ TNS object file. The Binder commands you can use are shown in the following diagram.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment Specify LIBLA if your program uses the 16-bit data model. For the 16-bit data model, the size of the type int is 16 bits. SELECT SEARCH data-model-file directs Binder to search the specified data-model file when resolving external references. Use CWIDE for the data-model-file to specify the 32-bit data model. Use CLARGE for the data-model-file to specify the 16-bit data model.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the G-Series OSS Environment Working in the G-Series OSS Environment The TNS c89 utility enables you to compile TNS C++ programs in the Open System Services (OSS) environment. The c89 utility is XPG4 compliant. This section gives an overview of the standard file operands and flags, lists the HP extensions that are applicable to TNS C++, and gives some examples.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the G-Series OSS Environment TNS c89 Flags You can invoke Cfront through the TNS c89 utility with the -Wcfront flag using the following 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 15-2 lists other commonly used TNS c89 flags. Table 15-2.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the G-Series OSS Environment TNS c89 Operands An operand is in the form of either a pathname or -l library. Note also that TNS c89 recognizes the operands in Table 15-3. Table 15-3.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the G-Series OSS Environment 1. This example preprocesses hello.C with Cprep, translates it with Cfront, compiles it with TNS C, and then binds it with the Binder to create an executable file named a.out. c89 hello.C 2. This example causes the same compilation steps to occur as in the previous example except that the resulting executable file is named hello. c89 -o hello hello.C 3. This example preprocesses hello.
16 Compiling and Linking TNS/R Native C and C++ Programs • • • • Selecting a Development Platform on page 16-2 Specifying Header Files on page 16-3 Compiling and Linking Floating-Point Programs on page 16-4 ° Using Compiler Pragmas IEEE_Float and Tandem_Float on page 16-5 ° Using Link Options to Specify Floating-Point Format on page 16-5 ° Link-Time Consistency Checking on page 16-6 ° Run-Time Consistency Checking on page 16-7 ° Linking Mixed-Language Programs on page 16-8 Working in the Guardian Environm
Compiling and Linking TNS/R Native C and C++ Programs Selecting a Development Platform For information about compiling and binding native C++ programs using the Windows PC environment, see the online help for the Enterprise Tool Kit. In this manual, the Enterprise Tool Kit is introduced in Section 18, Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC.
Compiling and Linking TNS/R Native C and C++ Programs • Specifying Header Files You cannot use the SSV pragma. However, you can specify search directories using the c89 -I flag. Specifying Header Files The macros and functions in the C run-time library are declared in header files. Each header file contains declarations for a related set of library functions and macros, as well as variables and types that complete that set.
Compiling and Linking TNS/R Native C and C++ Programs Compiling and Linking Floating-Point Programs and Section 6, Accessing Middleware Using HP C and C++ for NonStop Systems. For information about including SRLs at link time, see Determining Which SRLs Are Required on page 16-14. You can specify locations to search for header files as follows: • • • • In the Guardian environment, use the SSV pragma to specify a search list of subvolumes for files specified in #include directives.
Compiling and Linking TNS/R Native C and C++ Programs Using Compiler Pragmas IEEE_Float and Tandem_Float Tandem Floating-Point Format IEEE Floating-Point Format (continued) Remains the default format on HP NonStop systems, and is available for TNS C and C++, FORTRAN, TAL, pTAL, Pascal, COBOL, and native C and C++ programs Is available only for TNS/R native C and C++ programs and only by specifying IEEE floating-point using the IEEE_FLOAT command-line directive Requires conversion routines for data int
Compiling and Linking TNS/R Native C and C++ Programs Using Link Options to Specify Floating-Point Format When modifying an existing object file, nld or ld sets the state as specified by the change floattype flag. Link-Time Consistency Checking The nld or ld utility checks the consistency of floating-point type combinations when linking object files. The checking differs according to whether the -set flag is specified.
Compiling and Linking TNS/R Native C and C++ Programs Using Link Options to Specify Floating-Point Format Table 16-4. Floating-Point State as Determined by nld or ld floattype Attribute Tandem IEEE Neutral -set Tandem -set IEEE -set Neutral 1 or more 0 0 or more No message is generated and the output object file is TANDEM_ FLOAT. Warning message is generated and the output object file is IEEE_FLOAT. Warning message is generated and the output object file is NEUTRAL_ FLOAT.
Compiling and Linking TNS/R Native C and C++ Programs Using Link Options to Specify Floating-Point Format at process creation to ensure that the user library (if there is one) is marked with a floattype consistent with the program file.
Compiling and Linking TNS/R Native C and C++ Programs Working in the Guardian Environment In this example, the native C object file named COBJ uses IEEE floating-point format, and the pTAL object file uses Tandem floating-point format. (Note that pTAL supports only Tandem floating-point format.) To link these modules, you must specify the -set floattype IEEE_FLOAT flag. If this flag is not specified, ld generates error messages because of the mismatch between Tandem and IEEE floating-point formats.
Compiling and Linking TNS/R Native C and C++ Programs Compiling a Module If your program comprises a single module, you can use the RUNNABLE pragma to direct the compiler to produce a program file instead of a nonexecutable object file. If your program comprises more than one module, you can use the RUNNABLE and LINKFILE pragmas to direct the compiler to produce a linked program file instead of a nonexecutable object file. For details, see pragma LINKFILE on page 13-57.
Compiling and Linking TNS/R Native C and C++ Programs Compiling a Module OUT listing specifies the file to which the TNS/R native C compiler writes the compiler listing. When specified, listing is usually a spooler location. If you omit the OUT option, the compiler writes the listing to your current default output file. If the file already exists, the compiler attempts to delete the file and then continue. run-options is a comma-separated list of additional options for the RUN command.
Compiling and Linking TNS/R Native C and C++ Programs • Linking a Module The compiler returns one of the following completion codes: 0 The compilation completed successfully. 1 The compilation completed with warnings (but no errors). 2 The compilation completed with errors. 3 The compiler terminated abnormally as the result of an internal error. Examples 1.
Compiling and Linking TNS/R Native C and C++ Programs Linking a Module The ld utility is the linker for PIC (Position-Independent Code). For more information about PIC and sharing code, see: • • • • Pragma CALL_SHARED on page 13-12 Pragma NON_SHARED on page 13-68 Pragma SHARED on page 13-85 Example of compiling and linking PIC using ld in Examples on page 16-17 For more information about ld, see the ld Manual. CRTLMAIN File The CRTLMAIN file, located in $SYSTEM.
Compiling and Linking TNS/R Native C and C++ Programs Linking a Module system image for a particular node. A node can have more than one SYSnn subvolume, but only one active (running) SYSnn subvolume. When you use nld to build an executable program, nld fixes up references to the SRLs that you have specified. You can also use nld to repeat the fix-up process on an existing program to use a new version of an SRL or let the operating system update the references when you execute the program.
Compiling and Linking TNS/R Native C and C++ Programs Linking a Module Table 16-5 on page 16-15 is a conceptual stack of the SRLs that make up the context of VERSION1, VERSION2, and VERSION3. In the table, CRTL represents the SRL named ZCRTLSRL (the C run-time library). RWSLSRL is given as RWSL (the VERSION2 Standard C++ Library, which is a port of the Rogue Wave standard library). For a given version, you can link only to the SRLs listed in the column or stack for that version in Table 16-5.
Compiling and Linking TNS/R Native C and C++ Programs Linking a Module Additional SRLs might be required for other run-time libraries and services.
Compiling and Linking TNS/R Native C and C++ Programs Linking a Module Table 16-6. Using the Guardian nld and ld Utilities to Link SRLs (page 2 of 2) If your program uses: You should specify these nld/ld utility flags: VERSION2 Standard C++ Library, Tools.h++ (version 7) and runs in the OSS environment -l ZTLHSRL -l ZRWSLSRL -l ZCPLSRL -OBEY $SYSTEM.SYSTEM.
Compiling and Linking TNS/R Native C and C++ Programs Linking a Module 5. Compiling PIC (Position-Independent Code) using the default native C++ dialect (VERSION3 ). The example program (MEXE) uses a DLL (named NDLL) compiled from a library file named NC, which contains the getnum() function. MEXE imports getnum() and prints the result (31).
17 Compiling and Linking TNS/E Native C and C++ Programs • • • • Selecting a Development Platform on page 17-2 Specifying Header Files on page 17-3 Compiling and Linking Floating-Point Programs on page 17-4 ° Using Compiler Pragmas IEEE_Float and Tandem_Float on page 17-5 ° Using Link Options to Specify Floating-Point Format on page 17-6 ° Link-Time Consistency Checking on page 17-6 ° Run-Time Consistency Checking on page 17-7 ° Linking Mixed-Language Programs on page 17-8 Working in the Guardian Environm
Compiling and Linking TNS/E Native C and C++ Programs Selecting a Development Platform (ETK). In this guide, the Enterprise Tool Kit is introduced in Section 18, Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC. The Guardian CPPINIT* and OSS or PC cppinit* files used to create, replace, or delete C++ operators for TNS/R programs are not needed for TNS/E programs. The Guardian LIBCOBEY and OSS libc.obey files are not used for TNS/E program linking during compilation.
Compiling and Linking TNS/E Native C and C++ Programs Specifying Header Files The following 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. You cannot use the SSV pragma. However, you can specify search directories using the c89 -I flag.
Compiling and Linking TNS/E Native C and C++ Programs Compiling and Linking Floating-Point Programs You might also need to specify header files for the TNS/E native Standard C++ Library and Tools.h++ library in order to use functions contained in those libraries. For examples of #include directives for these libraries, see Section 5, Using the Standard C++ Library and Section 6, Accessing Middleware Using HP C and C++ for NonStop Systems.
Compiling and Linking TNS/E Native C and C++ Programs Using Compiler Pragmas IEEE_Float and Tandem_Float Tandem Floating-Point Format IEEE Floating-Point Format (continued) Available for TNS C and C++, FORTRAN, TAL, pTAL, D-series Pascal, COBOL, and native C and C++ programs Available only for native C and C++ programs.
Compiling and Linking TNS/E Native C and C++ Programs Using Link Options to Specify Floating-Point Format Using Link Options to Specify Floating-Point Format When linking object files using the eld utility, you can specify the floating-point state of the output object file using the -set floattype flag.
Compiling and Linking TNS/E Native C and C++ Programs Using Link Options to Specify Floating-Point Format Any floating type combination is allowed if the user explicitly overrides the default with the set floattype flag. Table 17-4 shows the results of each floating-point state when the floattype attribute is explicitly specified. Table 17-4.
Compiling and Linking TNS/E Native C and C++ Programs Using Link Options to Specify Floating-Point Format The following combinations are considered to be conflicting and are not allowed to begin to run: floattype in program file floattype in user library file IEEE Tandem Tandem IEEE Neutral IEEE The case in which the floattype attribute of the program file is IEEE and the user library file is Neutral is not considered a conflict.
Compiling and Linking TNS/E Native C and C++ Programs Working in the Guardian Environment modules, you must specify the -set floattype IEEE_FLOAT flag. If this flag is not specified, eld generates error messages because of the mismatch between Tandem and IEEE floating-point formats. When this flag is specified, eld generates a warning message about the mismatch and builds the executable file MYEXEC. CCPLMAIN (an object file) is a standard item, required when linking C programs.
Compiling and Linking TNS/E Native C and C++ Programs Compiling a Module To use the RUNNABLE pragma, one of the modules must contain the main function of the program. The CCOMP command invokes the TNS/E native C compiler. The CPPCOMP command invokes the TNS/E native C++ compiler. The syntax for these commands is shown in the following diagram. [ RUN ] { CCOMP | CPPCOMP } / IN source [ , OUT listing ] [ , run-options ] / [ object ] [ ; compile-option [ , compile-option ]...
Compiling and Linking TNS/E Native C and C++ Programs Compiling a Module OBJECT cannot be created, the compiler writes the object code to the file ZZLDFnnn (where nnn is a unique three-digit number) in your current default volume and subvolume. 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.
Compiling and Linking TNS/E Native C and C++ Programs Linking a Module 3. Generating an object file for the OSS environment: > CCOMP /IN filec / fileo; SYSTYPE OSS 4. Generating an executable program from a single module: > CCOMP /IN filec / fileo; RUNNABLE 5.
Compiling and Linking TNS/E Native C and C++ Programs Linking a Module Dynamic-Link Libraries (DLLs) A DLL contains code present in virtual memory at run time, to be shared by other processes, rather than code that is linked into object files. A DLL can also contain global data, and each process using the DLL automatically gets its own run-time copy of the data, called instance data. A process can use several DLLs. HP supplies public DLLs; you can create your own public DLLs.
Compiling and Linking TNS/E Native C and C++ Programs Linking a Module Determining Which DLLs Are Required The DLLs that are required by a program depend on whether the program: • • • • • • Runs in the Guardian or OSS environment Uses the C run-time library Uses the C++ run-time library Uses the Tools.h++ library (and whether Version 6.
Compiling and Linking TNS/E Native C and C++ Programs Linking a Module For more information see: • Section 5, Using the Standard C++ Library • Pragmas VERSION2 on page 13-106 and VERSION3 on page 13-108 • C++ Run-Time Library and Standard C++ Library on page 1-6 Additional DLLs might be required for other run-time libraries and services.
Compiling and Linking TNS/E Native C and C++ Programs Linking a Module Table 17-6. Using the Guardian eld Utility to Link DLLs (page 2 of 2) If your program uses: You should specify these eld utility flags: TCP/IP socket library -l ZINETDLL and other DLLs required by the program environment For more information about the linker, see the following manuals: • • eld Manual rld Manual Examples 1. The specified eld flags link a VERSION2 Guardian C++ program that uses the Tools.
Compiling and Linking TNS/E Native C and C++ Programs Linking a Module return 0; } Library for DLL (file name NC): export$ int getnum() { 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.
Compiling and Linking TNS/E Native C and C++ Programs HP C/C++ Programmer’s Guide for NonStop Systems —429301-008 17 -18 Linking a Module
18 Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC • • • • HP Enterprise Toolkit (ETK) on page 18-1 ° Hardware and Software Requirements on page 18-2 ° Online Help on page 18-3 ° Usage Guidelines on page 18-3 Tandem Development Suite (TDS) on page 18-4 ° Hardware and Software Requirements on page 18-4 ° Online Help on page 18-4 ° Usage Guidelines on page 18-5 Cross Compilers on page 18-6 ° Native C/C++ PC Cross Compiler on page 18-6 ° pTAL Cross Compiler on page 18-6 ° COBOL
Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC Hardware and Software Requirements Using the ETK, you can: • • • • • • • • • • • • • • • • • • Build native mode C/C++, COBOL, and pTAL applications targeted at NonStop systems Complete development functions more quickly by using a familiar user interface Create projects using wizards, including projects that contain embedded NonStop SQL/MP or NonStop SQL/MX source code Build Guardian and OSS executables (either PIC or G-ser
Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC Online Help Online Help Online help is the only user documentation for the Enterprise Toolkit.
Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC • • • Tandem Development Suite (TDS) The PC cross compiler interprets the slash character (\) in #include path names as a backslash (\). Therefore, OSS source files with directory names can map automatically to the PC namespace. The PC cross compiler handles source-file name suffixes in the same manner as c89. Source-file names must be identified with the .suffix format just as are OSS file names.
Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC Usage Guidelines Usage Guidelines The TDS version of the TNS/R native C/C++ cross compiler produces object code that runs only on G-series systems in either the Guardian or the OSS environment.
Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC Cross Compilers Cross Compilers Several cross compilers work with the ETK or the TDS: • • • • Native C/C++ PC Cross Compiler pTAL Cross Compiler EpTAL Cross Compiler on page 18-7 COBOL85 Cross Compilers on page 18-7 The ETK cross compiler package is installed with an HTML help file (“Using the Command-Line Cross Compilers on Windows”).
Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC • • • EpTAL Cross Compiler Accepts compiler and linker options that you select through the Project command on the Options menu Does not support embedded SQL statements Can produce dynamic-link libraries (DLLs), static libraries, or user libraries For more information about pTAL, see the pTAL Programmer’s Guide. EpTAL Cross Compiler The optional EpTAL cross compiler compiles EpTAL code that will run on TNS/E NonStop servers.
Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC • • PC Tools On the ETK and TDS platforms, enter ADD, MODIFY, SET, and DELETE statements into a TACL DEFINE file On the ETK and command-line platforms, compile SQL/MP or SQL/MX statements embedded in native COBOL source code Your PC must be connected to the NonStop host for certain SQL compile-time operations and for running your applications.
Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC • • Visual Inspect Allows you to select from several ways to view or collapse source files: by function, by paragraph, by pragma, or by normal view. Is available also as a stand-alone product. Visual Inspect Visual Inspect is an optional PC-based (GUI) symbolic debugger designed to work in complex distributed environments.
Using the HP Enterprise Toolkit (ETK) and Native C/C++ Cross Compiler on the PC HP C/C++ Programmer’s Guide for NonStop Systems —429301-008 18 -10 ar Tool (File Archive)
19 Running and Debugging C and C++ Programs • • • • • • • • • Running Programs in the Guardian Environment on page 19-1 Running Programs in the OSS Environment on page 19-2 Program Initialization on page 19-2 Program Termination on page 19-6 Two Memory Models: Large and Small on page 19-7 Two Data Models: 16-Bit and 32-Bit on page 19-9 Selecting Memory and Data Models on page 19-9 Converting Programs to the 32-Bit Data Model on page 19-10 Debugging C and C++ Programs on page 19-11 Running Programs in the
Running and Debugging C and C++ Programs Running Programs in the OSS Environment OUT file-name specifies the standard output file (stdout) for the new process. If you do not include the OUT option, the new process uses the command interpreter’s default output file, which is usually your home terminal. args-list is a space-separated list of additional arguments to the C or C++ program you are running. Note that you separate these arguments with spaces, not commas.
Running and Debugging C and C++ Programs The Standard Input, Output, and Error Files CRE has established its environment and set up shared facilities, it calls a languagespecific initialization function for each language that is represented by a routine in your program, except TAL and pTAL. Each language-specific initialization function sets up its data structures and file I/O model for the language that it supports. When the CRE completes initialization, it returns control to the C run-time library.
Running and Debugging C and C++ Programs • Invocation of Constructors for Global and Static Variables stderr denotes the physical file specified in an ASSIGN STDERR command. If you do not use the ASSIGN command, stderr denotes the command interpreter’s default output file, which is usually your home terminal. The IN and OUT options of the RUN command were described in Running Programs in the Guardian Environment on page 19-1.
Running and Debugging C and C++ Programs Parameters to the Function main argv is the argument array. Each element (except for the last) points to a null-terminated string. argv[0] points to the fully qualified name of the executing program. Each of the elements argv[1] through argv[argc-1] points to one command-line argument; argv[argc] has the pointer value NULL. env is the environment array.
Retrieving Startup Information Running and Debugging C and C++ Programs Retrieving Startup Information The Guardian C run-time library includes six functions that allow the retrieval of the process startup message, the PARAM message, and the ASSIGN messages. You can call these functions only from Guardian processes. These functions are listed in Table 19-1.
Two Memory Models: Large and Small Running and Debugging C and C++ Programs Two Memory Models: Large and Small HP TNS C has two memory models: the large-memory model and the small-memory model. HP TNS C++, native C, and native C++ has only the large-memory model. Both models support large amounts of code, but the large-memory model also supports large amounts of data.
Large-Memory Model Running and Debugging C and C++ Programs Figure 19-1. Memory Models Extended Segment Heap Global and Static Aggregates 64 KB User Data Segment Stack Stack Global and Static Aggregates with NOXVAR pragma and lowmem Aggregates Heap Global and Static Scalars Global and Static Aggregates 256 words Global and Static Scalars and Pointers to Global Aggregates 0 KB Large Model Small Model VST002.
Running and Debugging C and C++ Programs Two Data Models: 16-Bit and 32-Bit The stack, global, and static aggregates that have been specified with the NOXVAR pragma and global and static scalars are stored in the user data segment. The user data segment is limited to a total of 64 KB. Buffers that are used in certain Guardian system procedure calls must be stored in the user data segment so that they will be 16-bit addressable.
Converting Programs to the 32-Bit Data Model Running and Debugging C and C++ Programs Table 19-4.
Running and Debugging C and C++ Programs • Debugging C and C++ Programs Ensure that the type of a function call argument matches the defined type of its associated parameter. The compiler issues the following warning message for argument-parameter mismatches: Warning 86: argument "name" conflicts with formal definition • Write function prototypes for all user-written functions that don’t have prototypes.
Running and Debugging C and C++ Programs • • Debug Native Inspect on H-series systems The Visual Inspect debugger The following 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 machinelevel quantities.
Running and Debugging C and C++ Programs Visual Inspect Symbolic Debugger commands to access registers, code and data segments, stack, and other machinelevel entities. If you compile your program using the SAVEABEND pragma, the system automatically creates a save file, or snapshot, of your running program if it terminates abnormally. You can then use Native Inspect to examine the save file and diagnose the cause of the abnormal termination.
Running and Debugging C and C++ Programs Visual Inspect Symbolic Debugger HP C/C++ Programmer’s Guide for NonStop Systems —429301-008 19 -14
20 TNS C Compiler Messages This section 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.
TNS C Compiler Messages Types of Compiler Messages 4 invalid lexical token The compiler encountered an unrecognized element that was not a valid lexical construct (such as an identifier or one of the valid expression operators). This error can occur if the compiler detected control characters or other illegal characters in the source file. This error can also occur if you specified a preprocessor directive with the number sign not in the first position of an input line.
TNS C Compiler Messages Types of Compiler Messages 10 invalid subscript expression The compiler detected an error in the expression—presumably a subscript expression—following the left bracket character. This error can occur if the expression in brackets is null (not present). 11 string too large or not terminated The length of a string constant exceeded the maximum allowed by the compiler (256 bytes). This error occurs if you omit the closing double quote when specifying the string.
TNS C Compiler Messages Types of Compiler Messages 16 invalid function argument You specified an invalid function argument expression following the (function call operator. This error can occur if you omit an argument expression. 17 too many operands During expression evaluation, the compiler encountered the end of an expression, but more than one operand was still awaiting evaluation. This error can occur if you omit an expression.
TNS C Compiler Messages Types of Compiler Messages 22 structure used as function argument An identifier declared as a structure or union appeared as a function argument without the preceding address-of operator. Although you can pass a structure by value, this warning reminds you that it is inefficient to do so. 23 invalid use of conditional operator You used the conditional operator erroneously. This error can occur if the question mark was present but the colon was not found when expected.
TNS C Compiler Messages Types of Compiler Messages 28 missing operand 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. 29 invalid pointer operation You specified an operation—such as an arithmetic operation other than addition or subtraction—that was invalid for pointer operands.
TNS C Compiler Messages Types of Compiler Messages 33 cannot initialize auto aggregate You attempted to attach an initializer expression to a structure, union, or array that was declared auto. These initializations are not allowed by the language. 34 invalid initializer expression The expression used to initialize an object was invalid.
TNS C Compiler Messages Types of Compiler Messages 38 unbalanced braces In a body of compound statements, the number of opening left braces and closing right braces was not equal. This error can occur if the compiler got “out of phase” due to a previous error. 39 invalid use of keyword One of the C language reserved words appeared in an invalid context (for example, as an object name).
TNS C Compiler Messages Types of Compiler Messages 44 continue not inside loop 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. 45 default not inside switch The compiler encountered a default statement outside the scope of a switch statement. This error can occur due to an error in a preceding statement.
TNS C Compiler Messages Types of Compiler Messages 50 label missing from goto The compiler did not find a statement label following the goto keyword. 51 label name conflict identifier 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 The expression following the if keyword was null (not present).
TNS C Compiler Messages Types of Compiler Messages 56 colon expected The compiler did not find an expected colon. This error can occur if you improperly specified a case statement, or if you omitted the colon following a label or prefix to a statement. 57 semicolon expected The compiler did not find an expected semicolon. This error generally means that the compiler completed the processing of an expression but did not find the statement terminator.
TNS C Compiler Messages Types of Compiler Messages 61 undefined structure tag tag-name You did not previously define the indicated structure or union tag; that is, the members of the aggregate were unknown. 62 structure/union type mismatch The compiler detected a structure or union tag in the opposite usage from which it was originally declared; that is, a tag originally applied to a structure has appeared on an aggregate with the union specifier.
TNS C Compiler Messages Types of Compiler Messages 67 illegal object A declaration specified an illegal object, which can include functions that return aggregates (arrays, structures, or unions) and arrays of functions. 68 illegal object for structure A structure or union declaration included an object declared as a function. (An aggregate, however, can contain a pointer to a function.
TNS C Compiler Messages Types of Compiler Messages 73 declaration expected While processing object declarations, the compiler did not find another line of declarations that it expected. This error can occur if a preceding error caused the compiler to “get out of phase” with respect to declarations. 74 initializer data truncated More initializer data was provided than could be used for the declared size of the array. 75 invalid sizeof expression You supplied an invalid operand in a sizeof expression.
TNS C Compiler Messages Types of Compiler Messages 79 duplicate enumeration value You have attempted to give the same integer value to two identifiers that denote enumeration constants within the same enumeration type. 80 invalid bit field 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.
TNS C Compiler Messages Types of Compiler Messages 86 argument name conflicts with formal definition The type of the specified argument conflicts with the defined type of its associated parameter. 87 argument count incorrect The number of arguments in the function call disagrees with the number of arguments in the function prototype. 88 argument type incorrect The type of an argument in the function call disagrees with the type specified in the function prototype.
TNS C Compiler Messages Types of Compiler Messages 92 statement has no effect The statement does nothing. In the following common instance, the statement f; is meant to be a call to f, a function without parameters. Programmers accustomed to TAL often omit the parentheses from such a function call. 93 no reference to identifier name The identifier was not referenced at any point while it was in scope.
TNS C Compiler Messages Types of Compiler Messages This warning occurs only when you have specified the STRICT pragma. 98 no type was specified for object-name The compiler encountered an object declaration that did not specify the object’s type. Consequently, the object defaults to type int. This warning occurs only when you have specified the STRICT pragma.
TNS C Compiler Messages Types of Compiler Messages 103 no room for automatic data: object-name A function definition declared more than 32 KB of automatic data. 104 constant converted to smaller type and significance lost A constant was converted to a type that could not represent the value of the constant. 105 function declaration not in scope: func-name The compiler encountered a reference to a function that does not have a function declaration in scope.
TNS C Compiler Messages Types of Compiler Messages 110 number is not a legal warning number You specified an invalid warning number in the WARN pragma. 111 pragma directive has appeared too late in the compilation You used one of the pragmas that must occur at the start of the translation unit somewhere later in the translation unit.
TNS C Compiler Messages Types of Compiler Messages 117 C compiler is out of heap space This error occurs only with an extremely large C compilation unit. Break the large unit into two or more smaller units, and then use Binder to link them after compilation. 118 illegal function definition The parameter identifiers are missing from a function definition.
TNS C Compiler Messages Types of Compiler Messages 124 directive is valid only on the command line: pragma You used one of the pragmas that must occur on the command line in the translation unit. 125 directive is valid only as a pragma in the program: pragma You used one of the pragmas that must occur in the translation unit on the command line.
TNS C Compiler Messages Types of Compiler Messages 130 name is not a SQL variable The C object you used in an embedded SQL string was not declared within an SQL Declare Section. 131 variable missing from SQL statement The compiler encountered a colon (:) in an embedded SQL string, but the colon was not followed by a valid C identifier. 132 name is not of a supported variable type in SQL statements The object you specified as a variable in an embedded SQL string is not of a supported type.
TNS C Compiler Messages Types of Compiler Messages 136 library function name has been redefined The compiler encountered a redefinition of the specified library routine. This error usually indicates that one of your functions has a name conflict with a library routine. 137 name is an obsolete feature The specified feature is obsolete in this release of the C compiler.
TNS C Compiler Messages Types of Compiler Messages 146 missing comma between directives The compiler encountered a #pragma directive that specifies multiple pragmas, but the pragmas are not separated by commas. 147 non-standard use of cast operator in integral constant expression In an integral constant expression, the compiler encountered a cast operator that converts a pointer value to an arithmetic type. The C compiler does not support this nonstandard use of the cast operator.
TNS C Compiler Messages Types of Compiler Messages 151 macro-name has been replaced once, no further replacement During the macro expansion phase, if macro-name is encountered and if macroname is the same as that of the expanding macro, macro-name is not expanded, to avoid infinite looping of a recursive call. This message is a warning message. 152 missing ending quote The C compiler encountered a string literal that does not have an ending quotation mark (").
TNS C Compiler Messages Types of Compiler Messages for SEARCH use SEA and for SECTION 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 The C compiler encountered an interface declaration for a TAL procedure that uses the keyword tal. Replace the keyword tal with the keyword _tal.
TNS C Compiler Messages Types of Compiler Messages 161 too many commas The C compiler encountered extra commas in a list of section names. When including several section names from a file, use only the minimal number of commas necessary to separate the section names. For example, the following #include directive causes this error message. #include "$system.system.
TNS C Compiler Messages Types of Compiler Messages 165 constant for pointer function argument may only be 0 (null pointer) In the absence of function prototypes, the C compiler issues this error if a pointer to a const-qualified variable is passed as an actual parameter. This error message is issued to prevent the value of a const-qualified variable from being changed.
TNS C Compiler Messages Types of Compiler Messages 170 character format in SQL directive was set twice; default is used 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. The C compiler encountered two SQL pragmas with the char_as_array option specified.
Types of Compiler Messages TNS C Compiler Messages 175 two storage class specifiers exist in the same declaration Only one storage class specifier is allowed in each of the following: 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.
TNS C Compiler Messages Types of Compiler Messages 180 keywords 'typedef' '_pascal' _fortran' '_cobol' '_tal' or '_unspecified' should be the first token of a declaration statement or prototype declaration The compiler encountered a typedef declaration or an interface declaration for a Pascal, FORTRAN, COBOL, TAL, or an unspecified language type, in which typedef, _pascal, _fortran, _cobol, _tal, or unspecified is not the first keyword in the declaration, respectively.
Types of Compiler Messages TNS C Compiler Messages 186 second argument of offsetof is not a member of the structure The second parameter of the offsetof function must be a member of the structure that is the first parameter. 187 second argument of offsetof must not be a bit field member of the structure The second parameter of the offsetof function cannot be a bit field member of the structure that is the first parameter of the offseof function.
TNS C Compiler Messages Types of Compiler Messages 191 illegal pointer conversion between const and non-const attribute The C compiler encountered an illegal pointer. Check to see if the program illegally passes a const * formal parameter to a reference parameter without the const attribute.
TNS C Compiler Messages Types of Compiler Messages 198 illegal number of parameters count/size 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. 199 can be used in _extensible or _variable function only The _arg_present() operator can be used with extensible functions only. 201 invalid structure alignment An unknown FIELDALIGN pragma type name has been specified.
TNS C Compiler Messages Types of Compiler Messages 206 align type of tag name already set You can only specify one FIELDALIGN setting for a tag. 207 address pointing at code space is taken 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.
TNS C Compiler Messages Types of Compiler Messages 212 initialization of pointer to code space not allowed use explicit assignment or convert to array instead A pointer cannot be initialized with an address that represents a location in the code space. You must assign the address at run time. To avoid this restriction, convert an array of string constants to a two-dimensional array of characters.
TNS C Compiler Messages Types of Compiler Messages 222 structure cannot contain members in code and data space at the same time All the members of a structure have to reside in the data space or the code space; mixing is not possible. 224 number of bytes passed relies on previous declaration only The declarations for a pointer modified with the _cspace attribute are different.
TNS C Compiler Messages Types of Compiler Messages 228 fatal error, compiler terminates The compiler issues this message if physical limitations prevent further compilation. The surrounding error messages give more details as to the cause of the failure. 229 language specified for non-routine identifier, pragma function is ignored The identifier used in the pragma FUNCTION is not a known function. Ensure that the identifier has been declared.
TNS C Compiler Messages Types of Compiler Messages 236 Unable to read source text The compiler cannot read the source text. 249 INTERNAL COMPILER ERROR The compiler has detected an internal inconsistency. Contact your HP representative. 250 BINSERV or SYMSERV stopped 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.
TNS C Compiler Messages Types of Compiler Messages 282 Routine exceeds code size limit The routine being compiled is too large to fit in the 32K words of code space. Break the routine into more than one routine. 289 Parameter limit for extensible procedure is number words The extensible procedure has exceeded the upper bound of the number of words that can be passed to it. 294 Tag name is defined in fieldalign pragma but not used The compiler requires that a tag specified in a FIELDALIGN pragma exist.
TNS C Compiler Messages Types of Compiler Messages 303 Truncation of pointer size performed The TNS C compiler has converted a 32-bit pointer to a 16-bit pointer, resulting in the loss of the segment portion of the address and leaving only the offset portion. This can occur in two instances: • • When the address of a location in extended memory is cast to a _near pointer. When a non-C routine expecting a _near (16-bit) pointer argument is passed a 32-bit pointer.
TNS C Compiler Messages Types of Compiler Messages 310 Invalid macro name An invalid macro name is defined. 311 hexadecimal constant must have at least one digit A constant beginning with "0X" or "0x" has been defined without any following digits. 312 escape sequence value must must fit in unsigned char The escape sequence is too large to fit in an unsigned char value. Use a different data type. 313 escape sequence value must must fit in w_char The escape sequence is too large to fit in a w_char value.
TNS C Compiler Messages Types of Compiler Messages 320 mapinclude directive string text duplicated and ignored A mapinclude directive was previously specified for this string. 321 variable sqlcode should be type short 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. The C compiler supports a maximum of 255 block nesting levels.
21 Native C and C++ Compiler Messages The native C and C++ compilers emit four types of messages: • • • • Catastrophe Error Warning Remark Native C and C++ compiler messages of these four types are listed in Table 21-1. In the messages, variables (such as %s, %t, and %sfd) are expanded to represent the specific source-file elements that triggered the message. Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1. Native C and C++ Compiler Messages (page 9 of 20) Message Number Message Type Message Text 363 error the global scope has no %s 364 error qualified name is not allowed 365 error NULL reference is not allowed 366 error initialization with "{...
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
Native C and C++ Compiler Messages Table 21-1.
22 • • • • • • • • Run-Time Messages Trap and Signal Messages on page 22-1 (messages 1-10) CRE Service Function Messages on page 22-4 (messages 11-29) Heap-Management Messages on page 22-10 (message 30-39) Function Parameter Message on page 22-13 (message 40) Math Function Messages on page 22-13 (messages 41-49) Function Parameter Messages on page 22-15 (messages 55-57) Input/Output Messages on page 22-16 (messages 59-91) Environment Messages on page 22-23 (messages 275-276) This section presents the err
Trap and Signal Messages Run-Time Messages 3 Instruction failure An attempt was made to: • • • Execute a code word that is not an instruction. Execute a privileged instruction by a nonprivileged process. Reference an illegal extended address. 4 Arithmetic fault In the TNS environment, the overflow bit in the environment-register, ENV.<10>, was set to 1. In the native environment, a SIGFPE was raised.
Trap and Signal Messages Run-Time Messages 7 Memory manager read error An unrecoverable, read error occurred while the program was trying to bring in a page from virtual memory. 8 Not enough physical memory This fault occurs for one of the following reasons: • A page fault occurred, but there were no physical memory pages available for overlay. • Disk space could not be allocated while the program is using extensible segments. 9 Uncorrectable memory error An uncorrectable memory error occurred.
CRE Service Function Messages Run-Time Messages CRE Service Function Messages The CRE writes the messages in this subsection if an error occurs during its own processing or if it receives a request from a run-time library to report a specific message. 11 Corrupted environment 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.
CRE Service Function Messages Run-Time Messages 13 MCB pointer corrupt Cause. The pointer at location G[0] of the program’s user data segment to its primary data structure—the Master Control Block (MCB)—does not point to the MCB. Both the CRE and run-time libraries can report this error. In the native environment, this error can occur if the MCB run-time data structure has been corrupted. Effect. The CRE attempts to restore the pointer at G[0] and to write a message to the standard log file.
CRE Service Function Messages Run-Time Messages 16 Checkpoint list exhausted Cause. The CRE did not have enough room to store all of the checkpoint information required by the program. Effect. Program behavior is language and application dependent. Recovery. Increase the checkpoint list object’s size. For the routine that allocates your checkpoint list, see the language manual. 17 Cannot obtain control space Cause. The CRE or a run-time library could not obtain heap space for all of its data. Effect.
CRE Service Function Messages Run-Time Messages 21 Cannot read initialization messages ( error ) Cause. During program initialization, the CRE could not read all of the messages (start-up message, PARAM message, ASSIGN messages, and so forth) it expected from the file system. error is the file-system error number the CRE received when it couldn’t read an initialization message. Effect. The CRE terminates the program. Recovery. Consult your system administrator. 22 Cannot obtain program filename Cause.
CRE Service Function Messages Run-Time Messages The first ASSIGN specifies that the logical name A can appear in no more than one program file. The second assign specifies that the name A can appear in an arbitrary number of program files. The CRE cannot determine whether to use the file C.D on volume $B1 or on volume $B2. Effect. The CRE terminates the program. Recovery. Correct the ASSIGNs in your TACL environment. For more information on using ASSIGNs, see the TACL Reference Manual.
CRE Service Function Messages Run-Time Messages 27 Ambiguity in application of PARAM PARAM name 'value' Cause. A PARAM specifies a value that is ambiguous in the current context. For example, the PARAM specification: PARAM PRINTER-CONTROL A is ambiguous if the program contains more than one logical file named A. Effect. The CRE terminates the program. Recovery. Correct the PARAM in your TACL environment. For more information on using ASSIGNs, see the TACL Reference Manual.
Heap-Management Messages Run-Time Messages Heap-Management Messages The CRE or run-time libraries report the messages in this subsection if they detect an error while accessing the heap. 30 Unknown heap error Cause. A heap-management routine was called with an invalid error number. Effect. The CRE terminates the program. Recovery. Refer to the reference manual that corresponds to the language in which the routine that requests heap space is written. You might need to consult your system administrator.
Heap-Management Messages Run-Time Messages 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. Use a symbolic debugger to help isolate the problem or consult your system administrator. If this error occurs in the native environment, use a symbolic debugger to help isolate the problem.
Heap-Management Messages Run-Time Messages 36 Invalid operation for heap 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.
Function Parameter Message Run-Time Messages Function Parameter Message Run-time libraries report the message in this subsection if an error is detected in a parameter passed to a function. 40 Invalid function parameter Cause. A function detected a problem with its parameters. Effect. Program behavior is language and application dependent. Recovery. Correct the parameter you are passing.
Math Function Messages Run-Time Messages 43 Arcsin domain fault Cause. The parameter passed to the arcsin function was not in the range: -1.0 < parameter < 1.0 Effect. Program behavior is language and application dependent. Recovery. Modify the program to pass a valid value to the arcsin function. 44 Arctan domain fault Cause. Both of the parameters to an arctan2 function were zero. At least one of the parameters must be nonzero. Effect. Program behavior is language and application dependent. Recovery.
Function Parameter Messages Run-Time Messages 48 Exponentiation domain fault Cause. Parameters to a Power function were not acceptable. Given the expression y x the following parameter combinations produce this message: x = 0 and y < 0 x < 0 and y is not an integral value Effect. Program behavior is language and application dependent. Recovery. Modify the program to pass values that do not violate the above combinations. 49 Square root domain fault Cause.
Input/Output Messages Run-Time Messages 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. Recovery. Correct the program to pass a valid parameter value. 57 Parameter value not accepted Cause. The value passed as a procedure parameter is not acceptable in the context in which it is passed.
Input/Output Messages Run-Time Messages If the error was caused by a read request from the CRE, consult your system administrator. If the error was caused during program initialization, specify an acceptable input file when executing your program. 60 Standard output file error ( error ) Unable to open filename Cause. The file system reported an error when the CRE called a file system procedure to access standard output. error is the file-system error number.
Input/Output Messages Run-Time Messages 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.
Input/Output Messages Run-Time Messages 66 Unsupported file device Cause. The CRE received a request to access a device that it does not support. Effect. Program behavior is language and application dependent. 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.
Input/Output Messages Run-Time Messages 70 Options not accepted Cause. The value of an open operation options parameter was not valid in the context in which it was used. Effect. Program behavior is language and application dependent. Recovery. Consult your system administrator. 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.
Input/Output Messages Run-Time Messages 77 EDITREADINIT failed ( error ) Cause. A call to EDITREADINIT failed. error, if present, gives the reason for the failure. Possible values of error are: Effect. Program behavior is language and application dependent. For more information, see the Guardian Procedure Calls Reference Manual. Recovery. Recovery is language and application dependent. 78 EDITREAD failed ( error ) Cause. A call to EDITREAD failed. error, if present, gives the reason for the failure.
Input/Output Messages Run-Time Messages 81 End of file Cause. A routine detected an end-of-file condition. Effect. Program behavior is language and application dependent. Recovery. Correct your program to allow for an end-of-file condition or ensure that your program can determine when all of the data has been read. 82 Guardian I/O error nnn Cause. An operating system routine returned file-system error nnn.
Environment Messages Run-Time Messages Recovery. Modify your program to use different logical names or coordinate logical names between the two routines so that they do not open the same logical file at the same time. 91 Spooler job already started Cause. A FORTRAN routine attempted to open a spooler but the spooler was already open with attributes that conflict with those in the current open.
Run-Time Messages Environment Messages HP C/C++ Programmer’s Guide for NonStop Systems —429301-008 22 -24
23 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.
Misalignment Tracing Facility Handling TNS Data Alignment Product Number Manual or Addendum (continued) TNS/E EpTAL T9248 pTAL Reference Manual TNS/R pTAL T9248 pTAL Reference Manual TNS TAL T9250 TAL Programmer’s Guide Data Alignment Addendum Misalignment Tracing Facility The misalignment tracing facility is enabled or disabled on a system-wide basis (that is, for all processors in the node). By default, it is enabled (set to ON).
Handling TNS Data Alignment Misalignment Handling Sampling is short and infrequent enough to avoid flooding the EMS log, even for a continuous process with many misaligned-address exceptions. One sample logs a maximum of 100 events, and at most one event is logged for any process. If misaligned-address exceptions occur in different periods of a process, the operating system produces multiple EMS events for the same process, and these EMS events might have different program addresses.
Handling TNS Data Alignment C/C++ Misalignment Examples Table 23-1. TNS Misalignment Handling Methods (page 2 of 2) Method Description FAIL Instead of rounding down a misaligned address and proceeding to access the target, the operating system considers the instruction to have failed. For a Guardian process, this failure generates an Instruction Failure trap (trap #1).
Handling TNS Data Alignment C/C++ Misalignment Examples and the system configuration, but they might include erratic “rounding down” and abnormal program termination. In a TNS-compiled C or C++ program, some actions that can cause misaligned addresses are: 1. Using a null or uninitialized pointer When a structure pointer is null or uninitialized, the structure’s fields are random bits, which could give a random misaligned address if a pointer field is dereferenced. Examples: a.
Handling TNS Data Alignment C/C++ Misalignment Examples See: • • • Example 23-2 on page 23-8 Example 23-3 on page 23-8 Example 23-7 on page 23-9 3. Using a pointer union without direct assignment Union of a pointer with other pointers or with integers is safe when the values of the unions are mutually exclusive in time or when an equivalent explicit assignment of the address value would be correct at run time. See Example 23-4 on page 23-8. 4.
Handling TNS Data Alignment C/C++ Misalignment Examples 9. Using string check-sum or hashing functions that use 16-bit or 32-bit ADD or XOR operations Some TNS programs use check-sum or hashing functions that use a series of 16bit or 32-bit ADD or XOR operations to reduce an arbitrary length byte string to 16 or 32 bits.
Handling TNS Data Alignment C/C++ Misalignment Examples Example 23-2. C/C++ Invalid Cast From char to Integer Pointer (Item 2, Item 10) Change this: /* extract 16-bit length from front of long string: */ unsigned char *name; lth = * (unsigned short *) name; /* misalignment traps here */ name += 2; To this: /* extract 16-bit length from front of long string: */ unsigned char *name; lth = (name[0] << 8) | name[1] name += 2; Example 23-3.
C/C++ Misalignment Examples Handling TNS Data Alignment Example 23-6. C/C++ External Structure With Misaligned Parts (Item 8) Change this: /* An interface as struct { short a; char b; short c; } s; declared and used on 8-bit CPUs: */ /* offset 0 */ /* offset 2 */ /* offset 3 */ /* moves to offset 4 on TNS */ i = s.c; s.
Handling TNS Data Alignment C/C++ Misalignment Examples HP C/C++ Programmer’s Guide for NonStop Systems —429301-008 23 -10
A HP C Implementation-Defined Behavior • • • Implementation-Defined Behavior of Native C on page A-2 ° G.3.1 Translation on page A-2 ° G.3.2 Environment on page A-2 ° G.3.3 Identifiers on page A-2 ° G.3.4 Characters on page A-2 ° G.3.5 Integers on page A-3 ° G.3.6 Floating Point on page A-3 ° G.3.7 Arrays and Pointers on page A-4 ° G.3.8 Registers on page A-4 ° G.3.9 Structures, Unions, Enumerations, and Bit Fields on page A-4 ° G.3.10 Qualifiers on page A-5 ° G.3.11 Declarators on page A-5 ° G.3.
Implementation-Defined Behavior of Native C 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.
HP C Implementation-Defined Behavior • G.3.
G.3.7 Arrays and Pointers HP C Implementation-Defined Behavior Table A-1.
HP C Implementation-Defined Behavior G.3.10 Qualifiers Each member of a structure is aligned on the boundary required by its type. Padding is added between members as necessary. A plain int bit field is a signed int bit field. Bits within an integer bit field are allocated most significant bit first. A bit field cannot straddle a word boundary.
HP C Implementation-Defined Behavior G.3.14 Library Functions When an include file is specified as : • • If the compiler is running in the Guardian environment, the only subvolume searched is the compiler’s subvolume (usually, $system.system) If the compiler is running in the OSS environment, the only directory searched is /usr/include.
HP C Implementation-Defined Behavior G.3.14 Library Functions The default handling is reset if a SIGILL signal is received by a handler specified to the signal() function. Streams and Files The last line of a text stream does not require a terminating newline character. The file is written with the characters requested. The space characters that are written out to a text stream immediately before a newlinenewline character appear when the stream is read back in.
HP C Implementation-Defined Behavior G.3.14 Library Functions tmpfile() An open temporary file is removed if the program terminates abnormally. errno The macro errno is set to 4009 by the fgetpos() or ftell() function on failure. A call to the perror() function prints the textual error message corresponding to the value of the errno, optionally preceded by a specified string.
G.3.14 Library Functions HP C Implementation-Defined Behavior 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.
G.3.14 Library Functions HP C Implementation-Defined Behavior Table A-2.
G.4 Locale Behavior HP C Implementation-Defined Behavior Table A-2.
HP C Implementation-Defined Behavior G.5 Common Extensions Multibyte Characters and Wide Characters Multibyte characters and wide characters support Asian alphabets that often contain a very large number of characters. The Guardian native C run-time library functions, except for the strcoll() and strxfrm() functions, support these character sets: Tandem Kanji, Chinese Big 5, Chinese PC, Hangul and KSC5601. The following discussion of multibyte characters applies only to the Guardian environment.
G.5 Common Extensions HP C Implementation-Defined Behavior Wide characters are integers of type wchar_t, defined in the headers stddef.h and stdlib.h as: typedef unsigned short wchar_t; Such an integer can represent distinct codes for each of the characters in the extended character set. The codes for the basic C character set have the same values as their single-character forms.
HP C Implementation-Defined Behavior Translation Limits for Native C Compilers Translation Limits for Native C Compilers Native C uses dynamic data structures, so some program components are limited by the amount of available memory. The following list indicates minimums that are guaranteed (that is, a program that meets but does not exceed each minimum is guaranteed to compile).
HP C Implementation-Defined Behavior G.3.1 Translation corresponds to Annex G.3 of the ISO C standard or Appendix F of the ANSI C standard. G.3.1 Translation Each nonempty sequence of white-space characters, other than newline, is retained. The form of the diagnostic messages displayed by the TNS compiler is such that the source line is displayed first, followed by a line of the form: file name line diagnostictype: diagnostic message. For example: 100 foo (); **** \prune.$data.test.
HP C Implementation-Defined Behavior • G.3.3 Identifiers When a program calls exit() or terminate_program(), the process completes with normal or abnormal termination depending upon the completion code assigned to the status or options parameters, respectively. HP TNS C allows the declaration of up to three parameters to the program's function main.
HP C Implementation-Defined Behavior G.3.4 Characters G.3.4 Characters There are no source and execution characters that are not explicitly specified by the ISO/ANSI C Standard.
G.3.5 Integers HP C Implementation-Defined Behavior G.3.
HP C Implementation-Defined Behavior G.3.7 Arrays and Pointers When an integral number is converted to a floating-point number that cannot exactly represent the original value, the direction of truncation is up. When a floating-point number is converted to a narrower floating-point number, the direction of truncation, or rounding is up. G.3.7 Arrays and Pointers An unsigned long integer is required to hold the maximum size of an array, that is the type of the size of operator size_t.
HP C Implementation-Defined Behavior G.3.11 Declarators G.3.11 Declarators There is no practical limit to the maximum number of declarators that may modify an arithmetic, structure, or union type. G.3.12 Statements The maximum number of case values in a switch statement is MAX_INT. G.3.
HP C Implementation-Defined Behavior G.3.14 Library Functions G.3.14 Library Functions OL is the null pointer constant to which the macro NULL expands. 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, refer to the assert() function in the Guardian TNS C Library Calls Reference Manual.
HP C Implementation-Defined Behavior G.3.14 Library Functions The file position indicator of an append mode stream is initially positioned at the start of the file. A write on a text stream does not cause the associated file to be truncated beyond that point. Full buffering best describes the file buffering of the TNS C run-time. A zero-length file can actually exist.
HP C Implementation-Defined Behavior G.3.14 Library Functions Memory The behavior of the calloc(), malloc(), or realloc() function if the size requested is zero is: • • In the Guardian environment, calloc(), malloc(), and realloc() abort with runtime error 40. In the OSS environment on G-series systems, calloc(), malloc(), and realloc() return a non-NULL pointer. These pointers should not be dereferenced. abort() When the abort() function is called, all open and temporary files are closed.
G.3.14 Library Functions HP C Implementation-Defined Behavior 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.
G.3.14 Library Functions HP C Implementation-Defined Behavior Table A-3.
G.4 Locale Behavior HP C Implementation-Defined Behavior Table A-3.
HP C Implementation-Defined Behavior G.5 Common Extensions Multibyte Characters and Wide Characters Multibyte characters and wide characters support Asian alphabets that often contain a very large number of characters. The Guardian TNS C run-time library functions, except for the strcoll() and strxfrm() functions, support these character sets: Tandem Kanji, Chinese Big 5, Chinese PC, Hangul and KSC5601. The following discussion of multibyte characters applies only to the Guardian environment.
G.5 Common Extensions HP C Implementation-Defined Behavior Wide characters are integers of type wchar_t, defined in the headers stddef.h and stdlib.h as: typedef unsigned short wchar_t; Such an integer can represent distinct codes for each of the characters in the extended character set. The codes for the basic C character set have the same values as their single-character forms.
HP C Implementation-Defined Behavior G.5 Common Extensions pointers are those of type long int or those of type int with the 32-bit (wide) data model in effect, in which case an int is represented by 32 bits. TNS systems are word-aligned. In the following example, the size of str differs depending on whether this code is executed on a word-aligned or byte aligned machine. On a word aligned machine str is allocated 6 bytes of storage. On a bytealigned machine, str is allocated 5 bytes of storage.
HP C Implementation-Defined Behavior G.
B TNS C++ Implementation-Defined Behavior • • • HP Specific Features for OSS and Guardian Environments on page B-1 ° Length of Identifiers on page B-1 ° Length of String Literals on page B-2 ° Data Types on page B-2 ° Type Qualifiers on page B-2 ° Templates (Parameterized Types) on page B-2 ° Class Libraries on page B-2 ° Interfacing to the Standard C Run-Time Library on page B-3 ° Interfacing to User-Defined C Libraries on page B-3 ° Interfacing to User-Defined C Functions on page B-3 ° Interfacing to No
TNS C++ Implementation-Defined Behavior Length of String Literals Length of String Literals Cfront supports a maximum string literal size of 4096 characters, which is compatible with the string literal size supported by the C compiler. Data Types HP C++ supports the standard data types supported in the HP C programming language, including data types signed char and long long, a 64 bit-integer. The data type signed char is an HP extension to Cfront.
TNS C++ Implementation-Defined Behavior Interfacing to the Standard C Run-Time Library 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.
TNS C++ Implementation-Defined Behavior Interfacing to NonStop SQL/MP Interfacing to NonStop SQL/MP Cfront does not support embedded SQL. Embedded SQL support is provided by binding in C modules containing the desired SQL statements. Keep all SQL statements in one or more separately compiled C modules and bind these C modules into the executable C++ object file with Binder.
TNS C++ Implementation-Defined Behavior Pragma SYSTYPE to run in the other environment and describes the differences that exist between an executable C++ program file in the two environments. Pragma SYSTYPE The pragma SYSTYPE specifies whether a C++ program is targeted to run in the OSS or the Guardian environment. The Guardian version of Cfront defaults to generating code that is targeted for the Guardian environment.
TNS C++ Implementation-Defined Behavior HP C/C++ Programmer’s Guide for NonStop Systems —429301-008 B- 6 Applicable Pragmas
C ASCII Character Set ASCII Character Set in Numerical Order on page C-1 ASCII Character Set in Alphabetical Order on page C-6 Overview The two tables of the ASCII character set contained in this appendix use the following 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.
ASCII Character Set in Numerical Order ASCII Character Set Table C-1.
ASCII Character Set in Numerical Order ASCII Character Set Table C-1. ASCII Character Set in Numerical Order (page 3 of 5) 45 026000 000054 2C 44 , Comma 46 026400 000055 2D 45 - Hyphen (minus) 47 027000 000056 2E 46 .
ASCII Character Set in Numerical Order ASCII Character Set Table C-1.
ASCII Character Set in Numerical Order ASCII Character Set Table C-1.
ASCII Character Set in Alphabetical Order ASCII Character Set ASCII Character Set in Alphabetical Order Table C-2 presents the ASCII character set in alphabetical order—that is, alphabetic character codes (in the column labeled “Char.”) are in alphabetical order. Table C-2.
ASCII Character Set in Alphabetical Order ASCII Character Set Table C-2.
ASCII Character Set in Alphabetical Order ASCII Character Set Table C-2.
ASCII Character Set in Alphabetical Order ASCII Character Set Table C-2.
ASCII Character Set ASCII Character Set in Alphabetical Order HP C/C++ Programmer’s Guide for NonStop Systems —429301-008 C -10
D • • • • • • • Data Type Correspondence Table D-1, Integer Types, Part 1, on page D-1 Table D-2, Integer Types, Part 2, on page D-3 Table D-3, Floating, Fixed, and Complex Types, on page D-4 Table D-4, Character Types, on page D-5 Table D-5, Structured, Logical, Set, and File Types, on page D-6 Table D-6, Pointer Types, on page D-7 Table D-7, Address Types1, on page D-8 The following tables contain the return value size generated by HP language compilers for each data type.
Data Type Correspondence Table D-1.
Data Type Correspondence Table D-2.
Data Type Correspondence Table D-3.
Data Type Correspondence Table D-4. Character Types C-series BASIC STRING STRING -- C and C++ signed char unsigned char pointer to char struct { int len; char val [n] }; COBOL Alphabetic Numeric DISPLAY Alphanumeric-Edited Alphanumeric Numeric-Edited Alphabetic Numeric DISPLAY Alphanumeric-Edited Alphanumeric Numeric-Edited 01 name. 03 len USAGE IS NATIVE-21 03 val PIC X(n).
Data Type Correspondence Table D-5.
Data Type Correspondence Table D-6.
Data Type Correspondence Table D-7. Address Types1 C-series BASIC -- -- -- -- C -- -- -- -- COBOL -- -- -- -- FORTRAN -- -- -- -- D-series Pascal -- -- -- -- SQL -- -- -- -- pTAL PROCADDR BADDR WADDR EXTADDR SGBADDR SGWADDR SGXBADDR SGXWADDR CBADDR CWADDR 1 or 2, depends on declared pointer size 1 or 2, depends on declared pointer size Return Value Size (Words) 1 or 2, depends on declared pointer size 1 or 2, depends on declared pointer size 1.
E Features and Keywords of Version 2 Native C++ • • • • Features Supported in VERSION2 Features Not Supported in VERSION2 on page E-4 Keywords Added for the D45 Product Release on page E-5 Defining Virtual Function Tables on page E-5 Features Supported in VERSION2 The following features are accepted in the VERSION2 dialect of native C++.
Features and Keywords of Version 2 Native C++ • • • • • • • • • • • • • • • • Features Supported in VERSION2 A cast can be used to select one out of a set of overloaded functions when taking the address of a function. [13.4 Address of overloaded functions] Type template parameters are permitted to have default arguments. [14.1 Template parameters] Function templates may have nontype template parameters. [14.1 Template parameters] A reference to const volatile cannot be bound to an rvalue. [8.5.
Features and Keywords of Version 2 Native C++ • • • • • • • • • • • • • • • Features Supported in VERSION2 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.
Features and Keywords of Version 2 Native C++ • • • • • • Features Not Supported in VERSION2 An array allocated via a placement new can be deallocated via delete. [18.4.1.2 Array forms] Covariant return types on overriding virtual functions are supported. [10.3 (5) Virtual functions] enum types are considered to be nonintegral types. [7.2 Enumeration types] Partial specialization of class templates is implemented. [14.5.
Features and Keywords of Version 2 Native C++ • • • Keywords Added for the D45 Product Release The notation :: template (and ->template, etc.) is not implemented [3.4.5 Class member access] Template template parameters are not implemented. [14.1 Template parameters] Finding friend functions of the argument class types on name lookup on the function name in calls is not implemented. [14.5.3 Friends] Keywords Added for the D45 Product Release The following keywords were introduced at the D45 release.
Features and Keywords of Version 2 Native C++ Defining Virtual Function Tables non-inline virtual member function. Duplicate virtual function tables are generated for classes that define all virtual member functions within the class definition. 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.
F MIGRATION_CHECK Messages Table F-1 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.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 2 of 25) No. Class/Member Function Name Warnings Displayed Notes bitset: VERSION3 header file, continued class bitset (continued) 7. Field 'size_t bitset::bistset_size' is not supported in version 3 library. 8. Constructor 'bitset::bitset(const bitset&)' is not supported in version 3 library. 9. Operator& is defined as 'bitset bitset::operator&(const bitset)' in version 3 library. 10.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 3 of 25) No. Class/Member Function Name Warnings Displayed Notes common.h: VERSION3 header file 1 struct common 1."struct common not supported in Version 3.’ Equivalent file common.h is not defined in Version 3. complex: VERSION3 header file class complex None class complex All classes are supported in Version 3. class complex class complex deque: VERSION3 header file 1 class deque 1.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 4 of 25) No. Class/Member Function Name Warnings Displayed Notes deque: VERSION3 header file, continued 1 2 class deque, continued Class const_iterator (inner class) 12.'void init_aux ( InputIterator first, InputIterator last, _RW_is_not_integer)' is not supported in version 3. 12.No equivalent function defined in Version 3. 13.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 5 of 25) No. Class/Member Function Name Warnings Displayed Notes deque: VERSION3 header file, continued 2 Class const_iterator (inner class) continued Class iterator (inner class) 24.'pointer first' is not supported in version 3. 24.No equivalent field is defined in Version 3. 25.'pointer last' is not supported in version 3. 25.No equivalent field is defined in Version 3. 26.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 6 of 25) No. Class/Member Function Name Warnings Displayed Notes fstream/fstream.h: VERSION3 header file, continued 4 5 ofstream fstream 1.'ofstream(int fd, char* p, int l)' is not supported in version 3. 1.Equivalent class in Version 3 is 'basic_ofstream' type defined to 'ofstream'. 2.Class 'fstreambase' is not supported in version3 library 2.No equivalent constructor is defined in Version 3. 1.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 7 of 25) No. Class/Member Function Name Warnings Displayed Notes functional: VERSION3 header file, continued 18 templateclass unary_compose No warning issued. 19 template class pointer_to_unary_function No warning issued. 20 template class pointer_to_binary_function No warning issued. iomanip/iomanip.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 8 of 25) No. Class/Member Function Name Warnings Displayed Notes iostream/iostream.h: VERSION3 header file, continued 2 3 class streambuf class istream 2.'class streambuf' is defined inside namespace std in version 3. 2.Equivalent class 'basic_streambuf' is defined in file streambuf type defined to streambuf. 3.'virtual int doallocate()' is not supported in version 3. 3.No equivalent function in Version 3. 4.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 9 of 25) No. Class/Member Function Name Warnings Displayed Notes iostream/iostream.h: VERSION3 header file, continued 4 class ostream 15.'class ostream' is defined inside namespace std in version 3. 15.Equivalent class 'basic_ostream' is defined in file -ostream type defined to 'ostream'. 16.'ostream& complicated_put(char c)' is not supported in Version 3. 16.No equivalent function is defined in Version 3. 17.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 10 of 25) No. Class/Member Function Name Warnings Displayed Notes iterator: VERSION3 header file, continued 4 Struct bidirectional_ iterator 4.'struct bidirectional_iterator' is not supported in version 3. 4.No equivalent structure is defined in Version 3. 5 Struct random_access_ iterator 5.'struct random_access_iterator' is not supported in version 3. 5.No equivalent structure is defined in Version 3.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 11 of 25) No.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 12 of 25) No. Class/Member Function Name Warnings Displayed Notes list: VERSION3 header file, continued 1 class list continued 9.'void init(size_type n)' is not supported in version 3. 9.'No equivalent function in Version 3. 10.'void init_aux (InputIterator first, InputIterator last, _RW_is_not_integer)' is not supported in version 3. 10.'No equivalent function in Version 3. 11.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 13 of 25) No. Class/Member Function Name Warnings Displayed Notes list: VERSION3 header file, continued 1 class list continued 23.'link_type next_avail' is not supported in version 3. 23.'No equivalent function in Version 3. 24.'link_type last' is not supported in version 3. 24.'No equivalent function in Version 3. 25.'link_type node' is not supported in version 3 25.'No equivalent function in Version 3. 26.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 14 of 25) No. Class/Member Function Name Warnings Displayed Notes map: VERSION3 header file, continued 4 class multimap 6.'multimap (const multimap& x)' is not supported in version 3. 6.No equivalent constructor is defined in Version 3. 7.'size_type allocation_size()' is not supported in version 3. 7.No equivalent finction in Version 3. 8.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 15 of 25) No. Class/Member Function Name Warnings Displayed Notes memory and xmemory: VERSION3 header files, continued 7 8 class auto_ptr 1.template RWSTD_TRICKY _INLINE void destroy (ForwardIterator first, ForwardIterator last) 7.'explicit auto_ptr (X* p = 0)' is not supported in version 3. 7.No equivalent function in Version 3. 8.'auto_ptr (const auto_ptr& a)' is not supported in version 3. 8.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 16 of 25) No. Class/Member Function Name Warnings Displayed Notes queue: VERSION3 header file 1 class queue 1.Class queue : Template Mismatch Version 2 library: template . Version 3 library: template. 2 class priority_queue 2.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 17 of 25) No. Class/Member Function Name Warnings Displayed Notes queue: VERSION3 header file, continued 3 template inline bool operator== (const queue& x, const queue& y) 1.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 18 of 25) No. Class/Member Function Name Warnings Displayed Notes rwexcept: VERSION2 header file None. Equivalent implementation of rwexcept is found in exception in Version 3. rwnew: VERSION2 header file 1 class RWSTDExport bad_alloc None. Equivalent implementation of rwnew is found in new in Version 3. rwstdex: VERSION2 header file 1.class RWSTDExport logic_error 2.class RWSTDExport domain_error 3.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 19 of 25) No. Class/Member Function Name Warnings Displayed Notes stack: VERSION3 header file 1 class stack 1.class stack: Template Mismatch Version 2 library: template . Version 3 library: template. stdexcept2: VERSION2 header file 1 class exception None. Equivalent implementation of stdexcept2 is found in exception in Version 3.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 20 of 25) No. Class/Member Function Name Warnings Displayed Notes string: VERSION3 header file, continued 2 template struct RWSTDExport string_char_traits 2.'struct RWSTDExport string_char_traits' is not supported in version 3. 3 template struct RWSTDExport string_char_traits 3.'struct RWSTDExport string_char_traits' is not supported in version 3.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 21 of 25) No. Class/Member Function Name Warnings Displayed Notes string: VERSION3 header file, continued 10 class RWSTDHuge basic_string 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.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 22 of 25) No. Class/Member Function Name Warnings Displayed Notes strstream.h: VERSION3 header file, continued 4 5 class ostrstream class strstream string_char_traits 7.'class ostrstream' is defined in namespace std in version 3. 7.Equivalent 'class ostrstream' is defined in strstream in Version 3 8.'super class strstreambase' is not supported in version 3 library. 8.Not supported in Version 3. 9.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 23 of 25) No. Class/Member Function Name Warnings Displayed Notes vector: VERSION3 header file 1 class vector 1.'explicit vector (size_type n, const Allocator& alloc RWSTD_DEFAULT_ARG(Allocator ()))' is not supported in version 3. 1.No equivalent constructor is defined in Version 3. 2.'buffer_size' is not supported in Version 3. 2.Equivalent variable is not supported in Version 3. 3.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 24 of 25) No. Class/Member Function Name Warnings Displayed Notes vector: VERSION3 header file, continued 1 class vector continued 2 3 class RWSTDExport vector class reference (inner class) 12.'void assign (size_type n)' is not supported in version 3 12.No equivalent function is defined in Version 3. 13.'size_type allocation_size()' is not supported in version 3. 13.
MIGRATION_CHECK Messages Table F-1. MIGRATION_CHECK Warning Messages (page 25 of 25) No. 4 5 Class/Member Function Name Warnings Displayed Notes class iterator (inner class) 1.'iterator (unsigned int* x, unsigned int y)' is not supported in version 3 1.No equivalent constructor in Version 3. 2.'void bump_up ()' is not supported in version 3 2.No equivalent function in Version 3. 3.'void bump_down ()' is not supported in version 3. 3.No equivalent function in Version 3. 4.
MIGRATION_CHECK Messages Code Examples Code Examples • • For VERSION3, all classes defined in the C++ Standard are put into namespace std. For VERSION2,several classes were in global namespace.
Glossary absolute pathname. A pathname that begins with a slash (/) character and is resolved beginning with the root directory. Contrast with relative pathname. accelerate. To speed up emulated execution of a TNS object file by applying the Accelerator on TNS/R systems or the Object Code Accelerator (OCA) on TNS/E systems before running the object file. accelerated mode. See TNS accelerated mode. Accelerator mode.
Binder Glossary Binder. A programming utility that combines one or more compilation units’ TNS object code files to create an executable TNS object code file for a TNS program or library. Used only with TNS object files. block scope. Scope that continues until the end of the enclosing block. c89. The OSS utility that drives the C and C++ compilers. c89 has also been ported to the PC environment, where it drives the native C/C++ cross compiler and handles embedded SQL statements C-series system.
domain error Glossary domain error. A mathematical error that occurs when an argument value falls outside the defined bounds, or domain, of the specified mathematical operation. dynamic-link library (DLL). A PIC (position-independent code) library file that offers functions and data for use by other loadfiles. In UNIX, a DLL is known as a shared object file or a dynamic shared object (DSO). DLLs are supported in both Guardian and Open System Services environments. eld utility.
HP NonStop Technical Library (NTL) Glossary HP NonStop Technical Library (NTL). Browser based and built on internet standards, the HP NonStop Technical Library replaces the Total Information Manager (TIM). hybrid SRL. A TNS/R native shared run-time library (TNS/R native SRL) that has been altered so that PIC (Position-Independent Code) clients and DLLs, as well as non-PIC clients, can call functions in the hybrid SRL.
ld utility Glossary ld utility. The TNS/R native linker for PIC (Position-Independent Code). See linker. Compare to the nld utility. lexical elements. The elemental tokens into which C parses source code when checking the syntax and semantics of a translation unit. linkable object file. An object file that can be used in linking. linkage. The identifier attribute that enables two lexically equivalent identifiers to denote the same entity, regardless of the respective scopes of the identifiers. linker.
main function Glossary main function. The first function to execute when a program is run. The main function determines the run-time environment for a program. It is the function declared with the main keyword. misaligned. In TNS mode and accelerated mode, an address that is odd-byte aligned; in TNS/R native mode, an address that is not aligned. MIPS region of a TNS object file.
nld utility Glossary nld utility. The TNS/R native linker for non-PIC TNS/R code. See linker. Compare with the ld utility, the native linker for PIC (Position-Independent Code). noft utility. The native object file tool (noft) utility reads and displays information from TNS/R native object files. See also enoft utility. NonStop Open System Services (OSS). An application program interface (API) to the HP NonStop operating system and associated tools and utilities.
pTAL Glossary pTAL. Portable Transaction Application Language. A machine-independent system programming language based on Transaction Application Language (TAL). The pTAL language excludes architecture-specific TAL constructs and includes new constructs that replace the architecture-specific constructs. Contrast with Transaction Application Language (TAL). pTAL compiler. An optimizing TNS/R native-mode compiler for the pTAL language. range error.
SCF Glossary and the process terminates abnormally. Other debuggers can create a save file but refer to the result as a process snapshot file. See also process snapshot file. SCF. See Subsystem Control Facility (SCF). scope. The portion of a program in which an identifier is visible (that is, it can be used to denote a unique entity). shared run-time library (SRL). An object file or loadfile that the operating system links to a program file at run time.
TNS accelerated mode Glossary TNS accelerated mode. A TNS emulation environment on a TNS/R or TNS/E system in which accelerated TNS object files are run. TNS instructions have been previously translated into optimized sequences of MIPS or Itanium instructions. TNS accelerated mode runs much faster than TNS interpreted mode. Accelerated or interpreted TNS object code cannot be mixed with or called by native mode object code. See also TNS Object Code Accelerator (OCA).
TNS process Glossary TNS process. A process whose main program object file is a TNS object file, compiled using a TNS compiler. A TNS process executes in interpreted or accelerated mode while within itself, when calling a user library, or when calling into TNS system libraries. A TNS process temporarily executes in native mode when calling into native-compiled parts of the system library.
TNS/E native process Glossary TNS/E native process. A process initiated by executing a TNS/E native object file. Contrast with TNS process and TNS/R native process. TNS/E native user library. A user library available to TNS/E native processes in both the Guardian and Open System Services (OSS) environments. A TNS/E native user library is implemented as a TNS/E native dynamic-link library (DLL). TNS/R.
translation phases Glossary translation phases. The logical steps that compose the process C uses to translate a source file into an object file. translation unit. A source file and all of the header files and source files it includes (using #include), except for any source lines skipped as the result of conditional preprocessing directives. trap.
working directory Glossary HP C/C++ Programmer’s Guide for NonStop Systems—429301-008 Glossary -14
Index Numbers | A | B | C | D | E | F | G | H | I | K | L | M | N | O | P | R | S | T | U | V | W | X | Z Special Characters Numbers 16-bit addressable parameters 3-6 16-bit data model 1-5, 1-6, 1-13, 15-13, 19-9 32-bit data model 1-5, 1-6, 1-13, 2-21, 7-9, 15-13, 19-9, 19-10 32-bit int 2-21 A Abnormal program termination 23-5 abort, native C A-8 abort, TNS C A-23 Accelerating C programs 14-11 Accelerator 1-2, 14-13, 15-1, 15-15 Accessing environment information 19-4 Active backup processes 4-8, 16-14, 17
C Index Bit fields (continued) user-defined features native C A-4 TNS C A-19 Bit operations 7-23 Borland C++ 18-4 BUILD_NEUTRAL_LIBRARY pragma 5-13 C C active backup programs 16-14, 17-13 calling pTAL 8-9 calling TAL 3-2, 7-11 CCPLMAIN file 17-13 compilation system 14-13 compiler 1-5, 1-12, 14-2, 14-13, 15-1, 15-15 pragmas 15-3, 15-4 RUN command syntax 14-4, 15-8, 16-10, 17-10 CRTLMAIN file 16-14 data model 1-5, 1-13 files 4-4 interoperability 1-6, 1-13, 1-22 ISO/ANSI standard 1-5, 1-12 Kernighan & Ritch
D Index COBOL 2-10 Code space, specifying 9-1 Codewright 18-8 COLUMNS pragma 13-15, 15-3 Command line syntax 14-4, 15-8, 16-10, 17-10, 19-1 COMMON Binder group 14-10 Common Run-Time Environmen (CRE) See CRE Common Run-Time Library 19-2 Common-Usage C 1-5, 1-12, 1-21 Compiler C 1-5, 1-12 C++ 1-5, 1-13 definition 1-1, 14-13 errors and warnings 20-1 pragmas 13-1 See also individual pragmas Compiling a C module 14-4 a native C module 16-9, 17-9 C++ programs Guardian environment 15-1, 15-10, 16-9, 17-9 OSS env
E Index Data models (continued) TNS C++ B-5 Data type extensions decimal 2-20 long long 2-20 TNS C++ B-2 Data types, compatibility with C data types 7-8, 8-7 Debug 19-12 DEBUG utility 13-53 decimal 2-20 decimal type 2-20 Declarations extensible functions 9-5 external routines 13-37 syntax 2-2 variable functions 9-5 Declarators user-defined features TNS C A-20 TNS/R native C A-5 Default misalignment handling method 23-3, 23-4 DEFINE directive 12-2 Development platform 14-2, 16-2, 17-2 Diagnostic message fo
F Index exception header file 5-7, 5-8 Executing a C program 19-1, 19-2 Execution environments -xxiii exit() function, native C A-8 exit() function, TNS C A-23 export$ keyword 2-4, 16-18, 17-16 export-attribute 2-4 Extended data segments, TAL and C 7-27, 8-25 Extended indirection, TAL and C 7-17 extensible attribute 9-5 Extensions 2-1 attribute specifier 2-10 _cc_status 2-7 _cspace 2-9 _lowmem 2-2 EXTENSIONS pragma 2-1, 13-25 External data items 23-6 External functions 23-6 External procedures, interfacin
H Index Global data (continued) sharing TAL data with C modules using BLOCK declarations 7-16, 8-15 using pointers 7-14 Guardian and OSS, TNS C++ B-4 Guardian environment binding 14-6 developing in 14-4, 15-1 running programs from 19-1 Guardian procedures, calling 3-1, 4-10 Guardian tools 14-4 H Hashing functions 23-7 Header files 3-1, 14-3, 16-3, 17-3 Standard C++ Library 5-7, 5-8, 13-110 HEADERS pragma 13-39 Heap allocation, customizing 23-6 Heap management messages 22-10 Heap objects 23-5 HEAP pragma
K Index Interoperability 1-6, 1-13, 1-22, 4-10, B-4 ISO/ANSI C standard 1-1, 1-5, 1-12, 1-21 I/O functions 4-2 messages 22-16 K Kernighan & Ritchie (K&R) C 1-5, 1-12, 13-54 Keywords extensions 2-1 TNS/R C++ E-5 KR pragma 13-54 K&R See Kernighan & Ritchie (K&R) C L Language attributes 13-37 C++ 1-5, 1-13 extensions 2-1 preprocessor 14-12 LARGESYM pragma 13-55 Large-memory model 1-5, 1-6, 1-13, 3-6, 13-113, 19-7 ld utility 1-7, 13-13, 16-13, 16-18, Glossary-5 LD(arg) pragma 13-56 LIBCA file 15-13 LIBCOBEY
N Index MAP pragma 13-60 MAPINCLUDE pragma 5-12, 6-6, 13-61 Math function messages 22-13 Mathematical functions 4-6 MAXALIGN pragma 13-62 MB_CUR_MAX macro A-13, A-28 Memory models 1-5, 1-6, 1-13, 13-113, 19-7, 19-9 files 14-11 TAL and C guidelines 7-9 Messages compiler 21-1 CRE service 22-4 function parameter 22-13, 22-15, 22-16 heap management 22-10 input/output (I/O) 22-16 math function 22-13, 22-15 MIGRATION_CHECK F-1 trap 22-1 Migration tool 1-10, 1-17, 11-1 MIGRATION_CHECK pragma 13-63, F-1 MISALIGNL
O Index O Object Code Accelerator (OCA) 1-2 offsetof() macro 23-6 Offsets for fields 23-6 OLD Binder group 14-10 OLDCALLS pragma 13-69, 15-3 OLIMIT pragma 13-70 ONCE pragma 13-71 Operators 2-18 _arg_present 2-18 _bitlength 2-18 _optional 2-19 OPTFILE pragma 13-71 OPTIMIZE pragma 13-70, 13-72 OSS environment 15-15 and Guardian, TNS C++ B-4 c89 utility 14-12 developing in 14-12 file interoperability 4-10 running programs from 19-2 OSS functions 3-6, 4-10 OSS tools 14-12 OSS_TARGET 12-15 OVERFLOW_TRAPS pragm
R Index PROC(32) parameter type passing C routines to TAL 7-26, 8-23 passing TAL routines to C 7-24, 8-22 Production systems 23-4 Program initialization 19-2 startup 19-2 termination 19-6 Programming practices 1-20 pTAL 2-10, 8-6 cross compiler 18-6 data types 8-8 pTAL and C guidelines arrays of structures 8-20 identifiers 8-7 pTAL calling C 8-8 PUSH pragma 13-76 putenv() function 19-5 R Redefinitions, TAL and C guidelines 7-20, 8-20 REFALIGNED pragma 13-77 Register storage class specifier A-4, A-19 Rema
S Index TAL data with C modules using BLOCK declarations 7-16 using pointers 7-14, 8-13 SIGILL signal (signal #4) 23-4 Signals, native C A-6 Signals, TNS C A-21 signed char type 2-21 16-bit data model 1-5, 1-6, 1-13 sizeof instruction 23-6 SLMAP file 5-12 Small-memory model 1-5, 1-13, 3-6, 13-113, 19-7 Source files, acceptable types of 14-6, 16-11, 17-11 Specifying header files 14-3, 16-3, 17-3 library files 14-8, 14-15 SQL data-type conversion functions 4-11 SQL pragma 13-86 SQLMEM pragma 13-89 SQL/MP co
T Index System library 9-1 System-level programming, TNS C++ B-4 SYSTYPE pragma 13-101 GUARDIAN 12-15 OSS 12-15 TNS C++ B-5 T TACL macro, for compilation 15-1 TAL 2-10, 3-2 calling C 7-10, 8-8 TAL and C guidelines 3-2 arrays 7-18, 8-17 arrays of structures 7-20 bit-field manipulation 7-23 C calling TAL 7-11, 8-9 C enumeration variables 7-22, 8-21 data sharing 7-13 data types 7-8, 8-7 identifiers 7-7 indirection 7-17 memory usage 7-9 multidimensional arrays 7-20, 8-19 passing C routines to TAL 7-26, 8-23
V Index Unions C version of redefinitions 7-20, 8-20 pointer-valued members of 23-5 user-defined features TNS C A-19 TNS/R native C A-4 without direct assignments 23-6 UNSIGNED data type 7-23 User code 9-1 User library 9-1, 13-90 V Value parameters passing C routines to TAL 7-26, 8-23 passing TAL routines to C 7-24, 8-22 Variable and extensible functions 9-4 variable attribute 9-5 Variadic macros 12-12 VERSION1 pragma 1-6, 13-104 VERSION2 features E-1 VERSION2 library 5-5 VERSION2 pragma 1-7, 1-14, 13-45
Special Characters Index ZSECDLL 17-15, 17-16 ZSECSRL 16-16, 16-17 ZSTFNSRL 16-16, 16-17 ZSTLSRL 13-110, 16-15, 16-17, 17-14 ZSYSC file 3-2 ZTLH7DLL 17-15, 17-16 ZTLHSRL 16-16, 16-17 ZUTILDLL 17-15 ZUTILSRL 16-17 Special Characters $RECEIVE 4-5 -Wcplusplus 5-12 -Wnld_obey option 13-105 -Wtarget=TNS/R flag 16-1, 17-1 _alias attribute 2-12 _arg_present() operator 2-18, 9-5 _baddr pointer modifier 2-15 _bitlength() operator 2-18 _BOOL feature-test macro 12-13 _cc_status 2-7, 8-5 _cspace type qualifier 2-9,
