HP C/C++ Programmer’s Guide for NonStop Systems Abstract This guide describes HP extensions to the C and C++ languages for HP NonStop™ S-series systems and HP Integrity NonStop NS-series 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-004 NA May 2004 429301-006 NA December 2004 429301-008 H01 July 2005 429301-009 G07 and H01 September 2005 429301-010 G07 and H01 February 2006
HP C/C++ Programmer’s Guide for NonStop Systems Glossary Index Examples What’s New in This Manual xix Manual Information xix New and Changed Information About This Guide xxvii Audience xxix Documentation Set Organization Related Manuals xxx Guide Organization xxxiii Notation Conventions xxxv Figures xx xxix 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) 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-22 3.
5. Using the Standard C++ Library Contents 5.
Contents 7. Mixed-Language Programming for TNS Programs (continued) 7. Mixed-Language Programming for TNS Programs (continued) Calling TAL Routines From TNS C Modules 7-11 TAL Procedures That You Cannot Directly Call 7-12 Sharing Data 7-14 Variables and Parameters 7-17 Extended Data Segments 7-27 Interfacing to TNS COBOL 7-30 8.
9. System-Level Programming Contents 9. System-Level Programming Specifying a Code Space 9-1 Passing Pointers to Constants Between Code Spaces 9-2 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.
13. Compiler Pragmas (continued) Contents 13.
13. Compiler Pragmas (continued) Contents 13.
13. Compiler Pragmas (continued) Contents 13. Compiler Pragmas (continued) TRIGRAPH 13-105 VERSION1 13-106 VERSION2 13-108 VERSION3 13-110 WARN 13-114 WIDE 13-115 XMEM 13-116 XVAR 13-117 14.
15. Compiling, Binding, and Accelerating TNS C++ Programs (continued) Contents 15. Compiling, Binding, and Accelerating TNS C++ Programs (continued) Working in the G-Series OSS Environment 15-14 TNS c89 Flags 15-15 TNS c89 Operands 15-16 Input Files 15-17 Binding 15-17 Examples 15-17 Error Messages in the OSS Environment 15-18 16.
18. Using ETK and Native C/C++ Cross Compiler on the PC (continued) Contents 18. Using ETK and Native C/C++ Cross Compiler on the PC (continued) Cross Compilers 18-6 Native C/C++ PC Cross Compiler 18-6 pTAL Cross Compiler 18-6 EpTAL Cross Compiler 18-7 COBOL85 Cross Compilers 18-7 PC Tools 18-8 HP Extensions for Codewright (TEC) 18-8 Visual Inspect 18-9 ar Tool (File Archive) 18-9 19.
21. Native C and C++ Compiler Messages Contents 21. Native C and C++ Compiler Messages 22. Run-Time Messages Trap and Signal Messages 22-1 CRE Service Function Messages 22-3 Heap-Management Messages 22-9 Function Parameter Message 22-12 Math Function Messages 22-12 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.
A. HP C Implementation-Defined Behavior (continued) Contents A. HP C Implementation-Defined Behavior (continued) G.3.4 Characters A-17 G.3.5 Integers A-18 G.3.6 Floating Point A-18 G.3.7 Arrays and Pointers A-19 G.3.8 Registers A-19 G.3.9 Structures, Unions, Enumerations and Bit Fields 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-27 A-19 B.
C. ASCII Character Set Contents C. ASCII Character Set Overview C-1 ASCII Character Set in Numeric Order C-1 ASCII Character Set in Alphabetic Order C-6 D. Data Type Correspondence 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-6 E-5 F. MIGRATION_CHECK Messages Code Examples F-26 Glossary Index Examples Example 3-1. Example 3-2. Example 7-1.
Figures Contents Figures Figure i. Figure 19-1. Organization of HP C and C++ Documentation Set Memory Models 19-8 xxx Tables Table i. Table ii. Table iii. 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.
Tables (continued) Contents Tables (continued) Table 14-1. Table 14-2. Table 14-3. Table 14-4. Table 14-5. Table 14-6. 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.
Tables (continued) Contents Tables (continued) Table D-2. Table D-3. Table D-4. Table D-5. Table D-6. Table D-7. Table F-1.
Contents HP C/C++ Programmer’s Guide for NonStop Systems—429301-010 xviii
What’s New in This Manual Manual 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™ S-series systems and HP Integrity NonStop NS-series 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 Manual New and Changed Information This manual contains information about some of the following G-series development tools. On HP Integrity NonStop NS-series servers, these tools are supported only in H06.05 and subsequent H-series RVUs.
Changes to Previous Revisions of This Manual What’s New in This Manual Section Change (continued) Section 3, Interfacing to Guardian Procedures and OSS Functions Clarified the header file folder information under Declaring Guardian Procedures on page 3-1. Section 5, Using the Standard C++ Library Clarified the requirement for manual installation under Installation Notes for VERSION3 on page 5-6 and Installation Notes for VERSION2 on page 5-7.
Changes to Previous Revisions of This Manual What’s New in This Manual Section Change (continued) Section 18, Using ETK and Native C/C++ Cross Compiler on the PC Removed the Usage Guidelines on page 18-3 about specifying the -Wtarget=TNS/R flag to produce programs on G-series TNS/R servers. Appendix A, HP C Implementation-Defined Behavior Removed the TNS/E restriction for the unsigned long long data type under G.3.5 Integers on page A-3 because this data type now also supports TNS/R.
Changes to Previous Revisions of This Manual What’s New in This Manual Section Change (continued) Section 4, Using the C Run-Time Library Updated terminology throughout. Added the new Guardian and OSS TNS/E native C run-time libraries. Indicated that the TNS/E default floating-point is not TANDEM_FLOAT but is IEEE_FLOAT in IEEE Floating-Point Arithmetic on page 4-7. Section 5, Using the Standard C++ Library Indicated that Version 1 of the library is not supported on TNS/E servers.
Changes to Previous Revisions of This Manual What’s New in This Manual Section Change (continued) Section 14, 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 15, Compiling, Binding, and Accelerating TNS C++ Programs Added OCA as the accelerator for TNS programs to be run on a TNS/E platform.
What’s New in This Manual Changes to Previous Revisions of This Manual HP C/C++ Programmer’s Guide for NonStop Systems—429301-010 xxv
What’s New in This Manual Changes to Previous Revisions of This Manual HP C/C++ Programmer’s Guide for NonStop Systems—429301-010 xxvi
About This Guide This guide describes the implementation of the C and C++ programming languages for HP NonStop systems. This guide describes these products: • • • • • • • • TNS C compiler in the Guardian and G-series OSS environments. TNS C preprocessor (Cprep) and TNS C++ translator (Cfront) in the Guardian and G-series OSS environments. TNS/R and TNS/E native C and C++ compilers in the Guardian and OSS environments. TNS/R and TNS/E native C/C++ cross compiler on the PC in ETK and TDS.
About This Guide When you do mixed language programming, remember these points: • There are three HP compilers for the COBOL language, invoked by six separate commands.
Audience About This Guide Audience This guide is intended for systems and applications programmers familiar with the C and C++ programming languages, HP NonStop servers, and the HP NonStop OS. This manual does not describe the C/C++ standards, but does describe HP extensions and enhancements to the standards, in addition to implementation-defined behavior.
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 for C/C++ programs to interface with pTAL or native COBOL programs. 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 . . . 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. A HP C Implementation-Defined Behavior Describes HP implementation-defined features.
General Syntax Notation About This Guide General Syntax Notation This list summarizes the notation conventions for syntax presentation in this manual. 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.
Notation for Messages About This Guide An ellipsis immediately following a single syntax item indicates that you can repeat that syntax item any number of times. For example: "s-char…" 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.
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 Change bars are used to indicate substantive differences between this manual and its preceding version.
Change Bar Notation About This Guide HP C/C++ Programmer’s Guide for NonStop Systems —429301-010 xl
1 Introduction to HP C and C++ for NonStop Systems • • • • • • • • • • TNS C Language System 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-22 Porting Without Data Alignment Problems on page 1-23 Guardian and OSS Environm
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 in addition to 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 In the Guardian environment, support is also provided for: • Mixed language programming using interface declarations • Completion codes for error detection Exception Handling Is Not Supported Exception handling is described in The Annotated C++ Reference Manual. However, exception handling is not implemented in either USL Cfront or HP Cfront.
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 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 see the c89(1) reference page either online or in the Open System Services Shell and Utilities Reference Manual. • On a PC running the Windows operating system, use ETK or TDS to compile C++ code. You can also use the command-line cross compiler (named c89) outside ETK or TDS. (TDS does not support VERSION3.
Introduction to HP C and C++ for NonStop Systems • • • C++ Run-Time Library and Standard C++ Library The HP NonStop C run-time library (file ZCRTLSRL) The HP NonStop C++ run-time library (product T9227, Guardian version in file ZCPLGSRL; OSS version in file ZCPLOSRL) Tools.h++ version 6.
Introduction to HP C and C++ for NonStop Systems TNS/R Native Linkers (nld and ld Utilities) TNS/R Native Linkers (nld and ld Utilities) The nld native linker links one or more TNS/R native object files (files generated by the native compilers or nld) to produce either an executable (a loadfile) or relinkable native object file (linkfile). nld 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 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 NonStop SQL/MP Compiler and NonStop SQL/MX Compiler Linkfiles can be used again as input to TNS/R native linker. Loadfiles can be used as input to TNS/R native linker only for modifying loadfile attributes. Both linkfiles and loadfiles can be used as noft input.
Introduction to HP C and C++ for NonStop Systems Features of TNS/R Native C and C++ This manual is not intended to be a reference manual for ANSI C or for C++. For a complete description of ANSI C, see ANSI X3.159. For a complete description of C++, see ANSI X3J16/96-0225 (VERSION2) and ISO/IEC 14882:1998(E) (VERSION3). Useful references on C and C++ include: • • • • • • ANSI C, American National Standards Institute. ANSI X3.159-1989. Ellis, Margaret A. and Stroustrup, Bjarne.
Introduction to HP C and C++ for NonStop Systems TNS/E Native C and C++ Language System With two file-reference models available, select the model whose I/O services best suit the needs of application. For more details, see Section 4, Using the C RunTime Library. • Access to Guardian system procedures You can call procedures in the Guardian system library using the cextdecs header file in the Guardian environment or the cextdecs.h header file in the OSS or PC environments.
Introduction to HP C and C++ for NonStop Systems TNS/E Native C Compiler TNS/E Native C Compiler The TNS/E native C compiler accepts C language source files that comply with the ISO/ANSI C Standard (ISO/IEC 9899:1990, Programming Languages–C or ANSI C X3.159-1989, Programming Language C) or Common-Usage C (sometimes called Kernighan and Ritchie C, or K&R C). The native C compiler also accepts HP NonStop extensions that support the native architecture.
Introduction to HP C and C++ for NonStop Systems TNS/E Native C Run-Time Library syntax information, see the c89(1) reference page either online or in the Open System Services Shell and Utilities Reference Manual. • On a PC running the Windows operating system, use ETK to compile C++ code. You can also use the command-line cross compiler (named c89) outside ETK.
Introduction to HP C and C++ for NonStop Systems TNS/E Native Linker (eld Utility) VERSION3 Standard C++ Library ISO/IEC For C++ VERSION3 (the default version), these libraries are available: • • The HP NonStop C run-time library (file ZCRTLDLL) The VERSION3 library, which includes: ° The HP NonStop C++ common run-time library (product T2831, file ZCPPCDLL) ° The VERSION3-specific ratified Standard C++ Library ISO/IEC from Dinkumware, based on the standard document: ISO/IEC 14882:1998(E) (product T2
Introduction to HP C and C++ for NonStop Systems Native Inspect Symbolic Debugger Native Inspect Symbolic Debugger The Native Inspect symbolic debugger is an interactive tool that enables you to identify and correct programming errors in programs. You can use Native Inspect to: • Step through code • Set breakpoints • Display source • Display variables For more details on debugging capabilities, see the Native Inspect Manual.
Introduction to HP C and C++ for NonStop Systems NonStop SQL/MP Compiler and NonStop SQL/MX Compiler enoft runs in the Guardian and OSS environments. The enoft syntax and capabilities are nearly identical in each environment. For more details, see the enoft Manual. Native object files are in Executable and Linking Format (ELF), a standard format used for object files, with HP extensions. For more details on native object files, see the eld Manual.
Introduction to HP C and C++ for NonStop Systems Features of TNS/E Native C and C++ the description of pragma VERSION2 on page 13-108. A list of specific features accepted from the working paper appears in Appendix E, Features and Keywords of Version 2 Native C++. • VERSION3 of the native C++ compiler, which is based on the 1998 standard. VERSION3 is the default library used by the native C++ compiler. This manual is not intended to be a reference manual for ANSI C or for C++.
Introduction to HP C and C++ for NonStop Systems ° ° Writing Portable Programs The ANSI model, which uses FILE pointers to identify files The alternate or UNIX-style model, which uses file descriptors to identify files With two file-reference models available, you can select the model whose I/O services best suit the needs of your application. For more details, see Section 4, Using the C Run-Time Library.
Introduction to HP C and C++ for NonStop Systems • • • Complying With Standards X/Open Common Applications Environment (CAE) Specification, System Interface Definitions, Issue 4, Version 2, 1994. ISO/IEC 9945-1:1990, Information Technology—Portable Operating System Interface (POSIX) — Part 1: System Application Program Interface (API) [C Language].
Introduction to HP C and C++ for NonStop Systems Following Good Programming Practices Following Good Programming Practices In general, the more you follow good programming practices, the easier it will be to port your program to other hardware and software environments. A few of the most important good programming practices are: • • • • • • • • • Use strictly conforming C language features as described in the ISO/ANSI C standard as much as possible.
Introduction to HP C and C++ for NonStop Systems • • • • Porting Programs to HP C and C++ for NonStop Systems Horton, Mark. Portable C Software. Prentice Hall, Inc., 1990. Jaeschke, Rex. Portability and the C Language. Hayden Books, 1989. Lapin, J. E. Portable C and UNIX System Programming. Rabbit Software, 1987. Rabinowitz, Henry, and Chaim Schaap. Portable C. Prentice Hall, Inc., 1989. Porting Programs to HP C and C++ for NonStop Systems HP C complies with the ISO/ANSI C standard.
Introduction to HP C and C++ for NonStop Systems Porting Without Data Alignment Problems Porting Without Data Alignment Problems Section 8, Mixed-Language Programming for TNS/R and TNS/E Native Programs, and Section 23, Handling TNS Data Alignment, provide guidance on the use of compiler pragmas to avoid data alignment problems when sharing data between programs in different compiler languages or when porting programs and data between HP development environments or between NonStop platforms.
Introduction to HP C and C++ for NonStop Systems Guardian and OSS Environment Interoperability Some of the interoperable modules created before the D44 product version require code changes and recompilation. For more details and instructions, see Changes Required to Interoperable Compilation Modules at D44 on page 4-10. For more details on Guardian and OSS interoperability, see the Open System Services Programmer’s Guide.
2 • • • • • C and C++ Extensions Keywords Declarations on page 2-2 ° 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 standard-conforming program that might happen to use one of these keywords as an 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.
C and C++ Extensions Declarations 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. In the native environment, _lowmem has no effect on code generation or the storage of objects. It is supported to allow source-level compatibility with TNS C and C++.
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$ import$ 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 • 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. That is, linking or loading errors, or erroneous run-time type checking can occur if either one of these two paradigms is not followed: ° Exactly one compilation unit (and one load unit) explicitly exports the class (wholly or selectively), and all others explicitly import it.
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-35.
C and C++ Extensions Declarations Considerations for Both the 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 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 the native compilers only: • • An _extensible function is limited to 31 parameters. If more are supplied an error message is generated. _extensible and _variable are treated the same, _variable is a synonym for _extensible Considerations for the TNS compilers only: • A function with no prototype declaration or definition under pragma OLDCALLS cannot be _extensible.
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, 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 more details, see the pragma FUNCTION on page 13-35 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, the pointer can contain either a byte address or a TNS word address: 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 2. 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 )); } 3. 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 float float 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 Size of Type int For native C and C++, the data type int is always 32 bits. For TNS OSS programs, the data type int is always 32 bits. For TNS Guardian programs, the size of the data type int can be 16 bits or 32 bits, depending on whether you have specified the 32-bit (wid) data model. To specify the 32-bit (wide) data model, use the WIDE pragma. The WIDE pragma compiles only under the largememory model.
3 Interfacing to Guardian Procedures and OSS Functions • • • Declaring Guardian Procedures 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 or later releases and include the setjmp, tdmsigh, dlaunchh, and histryh header files. To determine the header file that declares the procedure, see the procedure’s reference page in the Guardian Procedure Calls Reference Manual. Each procedure’s reference page includes its C declaration syntax. However, do not use this syntax to declare Guardian procedures. Include the appropriate header file instead.
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, omit the parameter, but 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 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 Functions on page
Input/Output Models Using the C Run-Time Library The C run-time libraries also include HP extension functions for input and output, faulttolerant programming, SQL data-type conversion, EDIT file manipulation, and process startup information retrieval.
Using the C Run-Time Library Logical File Types functions. To find out how to access these procedures, see Section 3, Interfacing to Guardian Procedures and OSS Functions. Logical File Types Regardless of the file-reference model you use, specify the logical file type of a physical file when you open the physical file. When selecting logical type to use, consider two factors: 1. 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 Processes When accessing a process, use either the binary or the text logical type. 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 For example, the XPG4 cos() function definition requires that NaN be returned if the parameter to the function is NaN. The definition further states that errno optionally 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.
Active Backup Programming Functions Using the C Run-Time Library • • IEEE floating-point denormalized numbers avoid computational problems that arise from very small numbers as intermediate results in computations. 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 OS.
Active Backup Programming Functions Using the C Run-Time Library An active backup program executes as a primary and backup process pair running the same program file. The primary and backup processes perform interprocess communication. The primary process sends critical data to the backup process.
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 this table: Type of Compilation Unit Type of Executable 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 Compiling and Li
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 NonStop S-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-62, and its output is described in Appendix F, MIGRATION_CHECK Messages.
VERSION2 Using the Standard C++ Library Using VERSION3 on Guardian environment, 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 NonStop NS-series systems. To run a C++ program on a NonStop NS-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++.
Using the Standard C++ Library Using Header Files With VERSION3 Table 5-2. Installation Details for Standard C++ Library ISO/IEC (VERSION3) (page 2 of 2) Environment Location of Headers Location of Libraries PC running Windows and ETK release 3.0 or later C:\Program Files\Compaq ETK-NSE\rel\usr\include C:\Program Files\Compaq ETKNSE\rel\usr\lib where rel is the release identifier, such as H06.02 where rel is the release identifier, such as H06.
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 2. 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.h” in addition to “new" (renamed rwnew) from //Standard C++ Lib (T5895) 3.
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. An object is neutral when the library and the application using it conform with these rules: • • • The interface that the library provides uses only C linkage, or The interface that the library provides uses C++ linkage and all the parameters in these interfaces are marked as neutral or are strictly user-defined class types.
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-3 ° 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-5 ° 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.h++ version 7 is built on the Standard C++ Library, which is also available to HP NonStop users.
Accessing Middleware Using HP C and C++ for NonStop Systems Migration Considerations for Version 7 Migration Considerations for Version 7 Version 7 and version 6.1 are significantly different and are binarily incompatible. The collection class templates were reengineered between the two versions to make the templates compatible with the Standard C++ Library (VERSION2). If you choose to move to version 7 and you have applications that were built using any earlier version of Tools.
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++ Environment Location of Header Files Location of SRLs or DLLS Guardian Version 6.1: $SYSTEM.ZRW Version 6.1: $SYSTEM.SYSnn.ZTLHGSRL, $SYSTEM.SYSnn.ZTLHOSRL Version 7: $SYSTEM.ZINCRW70 G-series Version 7: $SYSTEM.SYSnn.ZTLHSRL H-series Version 7: $SYSTEM.ZDLLnnn.ZTLH7DLL OSS Version 6.1: /usr/rogue6.
Accessing Middleware Using HP C and C++ for NonStop Systems Tools.h++ Example Files for Versions 6.1 and 7 Tools.h++ Example Files for Versions 6.1 and 7 Several example files are provided with the Tools.h++ header files. Table 6-2 lists the example files provided with version 6.1. The examples assume that the data files are in the current subvolume. BUS is an example of a SmallTalk Collection class. Table 6-2. Tools.h++ Example Files for Version 6.
Accessing Middleware Using HP C and C++ for NonStop Systems Pragmas for Tools.h++ Table 6-3. Tools.h++ Example Files for Version 7 (page 2 of 2) Example File Description of Contents TIMEDATC Example source file TPDTESTC Template example TVDTESTC Template example Pragmas for Tools.h++ You need to use the MAPINCLUDE and CPATHEQ pragmas to map UNIX or OSS pathnames to Guardian file names. This examples illustrate the use of these pragmas: 1.
Accessing Middleware Using HP C and C++ for NonStop Systems Pragmas for Tools.h++ Each set of class library include files from a given vendor uses the same directory for each class library provided. This is not a problem on small systems, because users typically install their own copy of the version they need for their own use. On large multiuser systems, however, it is more likely that users might want to use different versions of a specific class library. For example, to get version 7 of the Tools.
Accessing Middleware Using HP C and C++ for NonStop Systems Pragmas for Tools.h++ Usage Guidelines • • • • • A MAPINCLUDE FILE pragma and a MAPINCLUDE PATH pragma can both operate on the same #include directive. 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.
7 Mixed-Language Programming for TNS Programs • • • • • Introducing the CRE 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-14 ° Variables and Parameters on page 7-17 ° E
Introducing the CRE Mixed-Language Programming for TNS Programs The CRE does not support all possible operations. For example, the CRE supports file sharing only for the three standard files: standard input, standard output, and standard 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.
Mixed-Language Programming for TNS Programs Using Standard Files in Mixed-Language Programs and FORTRAN run-time libraries call CRE library routines if you compile all the 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.
Mixed-Language Programming for TNS Programs • • Writing Interface Declarations 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 this 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 For more details on TNS C and TAL data types, see Variables and Parameters on page 7-17. 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. This 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 .
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 Here are examples of interface declarations for calling TAL routines: _tal _variable short SEGMENT_ALLOCATE_ (short, long, short *, short); _tal _variable _cc_status SEGMENT_DEALLOCATE_ (short, short); _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 in
Mixed-Language Programming for TNS Programs • • TAL Procedures That You Cannot Directly Call Returns the TAL procedures return value indirectly through a pointer parameter Returns the condition code using the function-return type _cc_status To illustrate this technique, this 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 .
Mixed-Language Programming for TNS Programs Sharing Data Sharing Data You can share global data in the user data segment between these types of TAL and TNS C modules: • TAL modules that declare global variables having standard indirection (.) • TNS C small-memory-model modules You can share global data in the automatic extended data segment between these types of TAL and C modules: • TAL modules that declare global variables having extended indirection (.
Sharing Data Mixed-Language Programming for TNS Programs This example shows how to share TAL data with a large-memory-model TNS C module. The TAL module passes to a C routine the addresses of two TAL arrays. The C routine assigns the array addresses to C pointers.
Sharing Data Mixed-Language Programming for TNS Programs 4. In the TAL routine, initialize the pointers with the addresses sent by C. 5. Use the pointers in the TAL module to access the C data. 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 Sharing TAL Data With TNS C Using BLOCK Declarations As of the D20 release, TAL modules can share global data with TNS C modules by declaring each shared variable in its own BLOCK declaration and giving both the variable and the BLOCK the same name. The TNS C modules must also declare each shared variable; the layout of the variable must match in both the TAL and C modules.
Variables and Parameters Mixed-Language Programming for TNS Programs STRING and char Variables TAL STRING and C char simple variables each occupy one byte of a word. These are STRING and char compatibility guidelines: • • Share variables of type TAL STRING and C char by using pointers.
Variables and Parameters Mixed-Language Programming for TNS Programs These are compatible arrays in TAL and TNS C (large-memory model): TAL Code C Code INT .EXT robin[0:9]; INT(32) .EXT gull[0:14]; STRING .EXT grebe[0:9]; short robin [10]; long gull [15]; char grebe [10]; Structures All TAL and C structures begin on a word boundary. These are guidelines for sharing TAL and C structures and passing them as parameters: • Specify the same layout for corresponding TAL and C structures.
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, 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 .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 This 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 this 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 • • The @ operator for a small-memory-model parameter The $XADR standard function for a large-memory-model parameter In this example, a TNS C large-memory-model module contains TNS C routine C_PARAM_FUNC, which is to be passed as a parameter.
Mixed-Language Programming for TNS Programs Extended Data Segments Extended Data Segments In addition to the user data segment, you can store data in: • The automatic extended data segment • One or more explicit extended data segments You should use only the automatic extended data segment if possible. You should not mix the two approaches. If you must use explicit segments and the automatic segment, however, follow guidelines 4 and 11 in Explicit Extended Data Segments. Note.
Mixed-Language Programming for TNS Programs Extended Data Segments 4. If the automatic extended data segment is already in place, SEGMENT_USE_ returns the automatic extended data segment’s number. Save this number so you can later access the automatic extended data segment again. 5. C requires special treatment for SEGMENT_USE_, which returns a value and sets the condition code. 6. You must keep track of addresses stored in extended pointers.
Extended Data Segments Mixed-Language Programming for TNS Programs 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 .EXT arr_ptr; ?PUSHLIST, NOLIST, SOURCE $SYSTEM.SYSTEM.
Mixed-Language Programming for TNS Programs *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 You can write native mixed-language programs targeted for the NonStop environment. Programs can contain routines written in native C, C++, pTAL, and native COBOL. The main() function in a native mixed-language program can be written in native C or C++, native COBOL, but not pTAL. Note. TNS/R native objects cannot be linked with TNS/E native objects.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Declaring External Routines to declare an external function: using a function prototype and a FUNCTION pragma (the preferred method), and using an interface declaration (the traditional method). 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.
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. This function prototype and FUNCTION pragma: void segment_allocate (short, long, short *, short); ... #pragma function segment_allocate (tal, alias (“SEGMENT_ALLOCATE_”), variable) is equivalent to this interface declaration: _tal _variable short SEGMENT_ALLOCATE_ (short, long, short *, short); 5.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL Using Identifiers pTAL and C identifiers differ: • 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 The return type value can be any of these: 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 pTAL Procedures That You Cannot Call Directly Your C program cannot directly call a pTAL procedure that returns both a value and a condition code. To access a pTAL procedure that returns both a value and a condition code, you must write a “jacket” procedure in pTAL that is directly callable by your C program.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL c_code = C_GETPOOL(my_pool,size,&blk_addr); if (_status_eg(c_code)) return( (short *)blk_addr ); else return( NULL ); } Techniques other than this cannot be used on NonStop NS-series systems. For more details, see the Appendix D of the pTAL Reference Manual. Sharing Data Using pointers to share data is easier and safer than trying to match declarations in both languages.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Considerations When Interfacing to pTAL FIELDALIGN PLATFORM is used to share data across languages for the same hardware platform. It lays out components using the platform's C compiler AUTO rules.
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 Arrays pTAL and C arrays differ: 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
Mixed-Language Programming for TNS/R and TNS/E Native Programs • • • Considerations When Interfacing to pTAL In pTAL, pass structures by reference. In C, use the & (ampersand) operator. In pTAL, a routine cannot return a structure as a return value or pass a struct or union by value. This 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. This 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: • 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 TAL_CALLER, a routine that calls C_FUNC and passes TAL_PARAM_PROC as a parameter 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);
Mixed-Language Programming for TNS/R and TNS/E Native Programs • Differences Between Native and TNS MixedLanguage Programs TAL_CALLER, which calls TAL_PROC and passes C_PARAM_FUNC as a parameter 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 To write mixed-language programs that run as both TNS and native processes, you must consider at least these issues: • • • • Data Models on page 8-25 Memory Models on page 8-25 _far Pointer Qualifier on page 8-25 Extended Data Segments on page 8-25 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.
Mixed-Language Programming for TNS/R and TNS/E Native Programs Interfacing to Native COBOL data segments. There are two types of extended data segments: flat segments and selectable segments. Selectable segments are a carryover from TNS system architecture. They continue to be supported on native systems. However, programs written for native systems should use flat segments. The term “extended” has little significance in the context of native systems.
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 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++ functions th
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 This 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 initialized.
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 Declaring Variable Functions instead of variable in native C programs. This 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. If you add parameters to a variable function declaration, all procedures that call it must be recompiled.
Omitting Parameters System-Level Programming In this 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. void errmsg (int x, int p1, int p2); #pragma function errmsg (variable) /* function declaration */ _variable void errmsg (int x, int p1, int *p2) /* function definition */ #define P1_DEFAULT_VALUE -1 { if (!_arg_present(p1)) /* Valid, use default value */ { p1 = P1_DEFAULT_VALUE; /* if p1 is absent */ ...
System-Level Programming Converting Variable Functions to 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 Converting Variable Functions to Extensible Functions HP C/C++ Programmer’s Guide for NonStop Systems—429301-010 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, see 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 • • ° 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. The ISO/ANSI C standard supports only type int as a bitfield type.
Converting C-Series TNS Programs to Use the Current TNS Compiler For example, you must change this C-series macro to use the # directive: C-series macro: #define pr (x, format) printf("The x = %format\n"), (x)) D-series macro: #define str(a) # a #define pr(x, format) printf(str(The x = %format\n), (x)) • Recode your programs to eliminate the use of these HP C supplementary library calls that are not supported by the current compilers: ° extfname_to_intfname() This function is not required because the D
Converting C-Series TNS Programs to Use the Current TNS Compiler 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 You can use the migration tool in either the Guardian or the OSS environment. The migration tool is also integrated into TDS on the PC. For more 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-4 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 Table 12-1. Preprocessor Directives (page 2 of 2) #line Causes the compiler to renumber the lines in the source text. #pragma Introduces a compiler pragma. #undef Deletes a macro definition. #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 #define Usage Guidelines • • • • • If you need more than one physical line to complete the definition of a macro, place a backslash (\) at the end of all but the last line of the definition. The backslashes cause these physical lines to be concatenated into a single logical line. The #ifdef and #ifndef directives enable you to test whether an identifier is currently defined as a macro name.
Preprocessor Directives and Macros #error #error The #error directive allows you to force a compilation error and terminate compilation. #error preprocessor-tokens preprocessor-tokens specifies the tokens to be included in the message text.
Preprocessor Directives and Macros #if, #elif, #ifdef, #ifndef, #else, and #endif if-section: if-group [ else-group ] #endif newline if-group: { { { { #if int-constant-expression #elif int-constant-expression #ifdef identifier #ifndef identifier } 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 identifier to test, and the new line following it terminates the #ifndef directive line. source-text is the source text that is included if identifier is not currently defined as a macro name. #else newline [ source-text ] is the else group of an if section. The new line following the #else directive terminates the directive line.
Preprocessor Directives and Macros #include #if XCOORD == 10 printf("Intersection at (10,5).\n"); #elif YCOORD == 10 printf("Intersection at (5,10).\n"); #else printf("Intersection at (5,5) \n"); #endif 3. This example shows how the #ifdef directive works. Because PC is defined as a macro, the compiler processes the source text following the #ifdef PC directive.
#include Preprocessor Directives and Macros source_specifier specifies the location of the program text that the compiler includes in the compilation. source_file is the file name of the source file you want to include. In the Guardian environment, the compiler searches for source_file using the SSV search list. In the OSS environment, the compiler searches for source_file using operands specified in the c89 utility -I flag. library_header_file is the name of the library header file you want to include.
#include Preprocessor Directives and Macros File File Search (continued) #include "source_file" The specified user-defined file is searched for in the current default Guardian volume and subvolume or OSS working directory. #include "subvolume.file" The specified user-defined file is searched for in the current default Guardian volume. In RVUs preceding D30.00, if the #include specification was of the form #include "subvolume.
Preprocessor Directives and Macros #line 2. This example includes the stdio.h header file, specified for the OSS environment: #include 3. This example includes the file mysource from the current volume and subvolume or current working directory: #include "mysource" #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.
Preprocessor Directives and Macros Predefined Macros Usage Guideline Once you have deleted a macro definition, its identifier no longer exists as a macro name. Consequently, the #ifdef and #ifndef directives will find the identifier to be undefined. 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.
Preprocessor Directives and Macros Predefined Symbols None of these predefined macros can be removed using #undef. This example demonstrates the use of the __FUNCTION__ macro: #include
Feature-Test Macros Preprocessor Directives and Macros arguments that can be referred to by __VA_ARGS__ (includes the separating commas) */ D("%c%s\n" , ’E’, "DG"); /* Expands to "printf("%c%s\n", ’E’, "DG");" */ 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.
Feature-Test Macros Preprocessor Directives and Macros Table 12-3. Predefined Feature-Test Macros (page 2 of 3) Macro What It Defines _GUARDIAN_HOST Identifiers used by the C compiler running in the Guardian environment _GUARDIAN_TARGET Identifiers required for executing in the Guardian environment __G_SERIES_RVU Declarations that depend on a specific G-series RVU and have the value G06.nn. Defined only for the TNS/R native C/C++ compilers.
Feature-Test Macros Preprocessor Directives and Macros Table 12-3. Predefined Feature-Test Macros (page 3 of 3) Macro What It Defines _TNS_E_TARGET Identifiers used by the TNS/E native C and C++ compilers; defined only for the TNS/E native C/C++ compilers. _TNS_R_TARGET Identifiers used by the TNS/R native C and C++ compilers; defined only for the TNS/R native C/C++ compilers. _WIN32_HOST Identifiers required for compiling on a PC running the Windows operating system.
Preprocessor Directives and Macros Preprocessor Operators #if __TANDEM_ARCH_ != 0 printf ("Native system, not TNS\n"); #endif The _IGNORE_LOCALE macro selects macros that support only the C/POSIX locale instead of internationalized functions that support multiple locales. The _IGNORE_LOCALE macro affects functions in the ctypeh or ctype.h header file. The native compilers provide four additional feature-test macros.
Preprocessor Directives and Macros Operator ## argument passed by the macro invocation is enclosed in quotation marks and treated as a string literal. The string literal then replaces each occurrence of a combination of the # operator and the formal parameter within the macro definition. White space preceding the first token of the actual argument and following the last token of the actual argument is deleted.
Preprocessor Directives and Macros HP C/C++ Programmer’s Guide for NonStop Systems—429301-010 12 -18 Operator ##
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 BUILD_NEUTRAL_LIBRARY Directs the TNS/E native compilers to create a C++ library using only those definitions common to the VERSION2 and VERSION3 libraries and to set the CPPNEUTRAL flag in the linkfile. CALL_SHARED Directs the native compilers to generate PIC (PositionIndependent Code) (shared code). This is the default for the TNS/E native compilers.
Compiler Pragmas Table 13-1. Compiler Pragma Descriptions (page 3 of 7) Pragma Purpose HEAP The HEAP pragma specifies the maximum heap size of a program compiled with the RUNNABLE pragma. HIGHPIN Specifies that the object file should be run at an operating system high PIN (256 or greater) or at a low PIN (0 through 254). HIGHREQUESTERS Specifies that the object file supports high PIN requesters if the object file includes the main function.
Compiler Pragmas Table 13-1. Compiler Pragma Descriptions (page 4 of 7) Pragma Purpose LARGESYM 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. LD(arg) Specifies arguments to be passed to the ld utility. LINES Specifies the maximum number of output lines per page for the compiler listing file.
Compiler Pragmas Table 13-1. Compiler Pragma Descriptions (page 5 of 7) Pragma Purpose ONCE Specifies that the file containing this pragma will be compiled only once during the compilation. OPTFILE Specifies an optimizer file, which contains a list of functions that are to be optimized at the level specified in the file. OPTIMIZE Controls the level to which the compiler optimizes the object code.
Compiler Pragmas Table 13-1. Compiler Pragma Descriptions (page 6 of 7) Pragma Purpose SQL Enables the compiler to process subsequent SQL statements. SQLMEM Provides the ability to alter the placement of SQL data structures from extended memory to the user data segment. SRL Specifies that a module is being compiled to link into a native user 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 TRIGRAPH Controls whether the TNS C compiler or Cfront translate trigraphs for the current compilation. VERSION1 Directs the TNS/R native C++ compiler to compile according to the D40 version or dialect of C++. Disables all new features added from the D45 RVU onward. VERSION1 is the default compilation mode for D45 and all RVUs until the G06.20 RVU.
ALLOW_EXTERN_EXPLICIT_INSTANTIATION Compiler Pragmas Usage Guidelines • ALLOW_CPLUSPLUS_COMMENTS is a command-line directive that must be entered on the compiler RUN command line, not in the source text. • The ALLOW_CPLUSPLUS_COMMENTS directive can also be specified with the -Wallow_cplusplus_comments flag of the c89 utility. • 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 (//).
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 is a command-line directive and 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.
CHECK 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 these to the eld or ld linker: ° For a TNS/R program, CCPPMAIN (Guardian) or ccppmain.
COLUMNS Compiler Pragmas 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. Usage Guidelines • • • • • In the Guardian environment, the CHECK pragma must be entered on the compiler RUN command line. In the OSS environment, the CHECK pragma must be entered in the source file.
CPATHEQ 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 COLUMNS pragma can be entered on the compiler RUN command line or in the source text.
CPATHEQ Compiler Pragmas SSV pragmas; a CPATHEQ file that contains command-line options is not treated as part of the command line but as a source file. CPATHEQ [ "file-name" ] file-name identifies a CPATHEQ file. The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS and PC TNS C compiler Not set Not set G-series TNS c89 utility N.A. N.A. TNS/R native C and C++ compilers Not set N.A. Native c89 utility N.A. N.A. TNS/E native C and C++ compilers Not set N.A.
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 more 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 ENV The ENV pragma specifies the intended run-time environment of an object file. ENV env-option env-option: { { { { COMMON EMBEDDED LIBRARY LIBSPACE } } } } 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.
ENV Compiler Pragmas relocatable data blocks (global data). Native user library programs can call the entire C run-time library. For the native C and C++ compilers, this option sets the _LIBRARY feature-test macro. LIBSPACE specifies that the module does not require resources provided by the CRE and that it meets the requirements to run in the user library space or system library space. You must verify that code does not use the C run-time library and other CRE resources.
ENV Compiler Pragmas Table 13-2. ENV Options and the Availability of Run-Time Library and Language Features (page 2 of 2) Feature COMMON EMBEDDED LIBRARY LIBSPACE Main routine Yes No No No Relocatable data blocks Yes Yes No No Functions that set errno Yes No Yes No *ENV LIBRARY permits the use of high-level language I/O facilities if direct access to relocatable data blocks is not needed for the operations.
ERRORFILE Compiler Pragmas ERRORFILE The ERRORFILE pragma directs the compiler to send error and warning messages to a specified file location. ERRORFILE { filename | define-name } filename is the name of the error-logging file. It must be a disk file name. define-name is the name of a MAP DEFINE that refers to a disk file. The compiler uses the disk file as the error-logging file.
ERRORS Compiler Pragmas ° If you specified a DEFINE name for the name of the source file, the name of the file to which the DEFINE evaluated appears in this entry ° ° ° The EDIT line number in which the error or warning occurred The column number in the line where the compiler detected the error/warning The error or warning message text ERRORS The ERRORS pragma directs the compiler to terminate compilation if it detects more than a specified number of errors.
EXTENSIONS 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 NOEXTENSIONS NOEXTENSIONS Native c89 utility NOEXTENSIONS NOEXTENSIONS TNS/E native C and C++ compilers NOEXTENSIONS NOEXTENSIONS Usage Guidelines • • • • • • • • The EXTENSIONS pragma can be entered on the compiler RUN command line or be specified with the -W[no]extensions flag of the c89 utility.
EXTENSIONS Compiler Pragmas • No warning is displayed when the EXTENSIONS pragma is used with the TNS/E native mode compiler and all these are true: ° ° ° The formal parameter type is a pointer to an integer type The actual parameter type is a pointer to an integer type Both integer types have the same size If the integer types have the same size, but are not both signed or both unsigned, a warning is displayed. If the integers are of different sizes, an error occurs.
EXTERN_DATA Compiler Pragmas ° 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. A predicate name is given a definition by a preprocessing directive of the form: #assert name #assert name (token-sequence) which defines the predicate name. In the first form, the predicate is not given a value.
EXTERN_DATA Compiler Pragmas 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. variable-name identifies a variable that has previously been declared. 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.
FIELDALIGN Compiler Pragmas ° ° ° Use the default value for EXTERN_DATA, which is NO_GP. Use the correct header file to declare the SRL data. Add a #pragma extern_data no_gp SRL-variable-name for each SRL data object that the program explicitly declares. EXTERN_DATA has no effect if the compilation specifies the SRL directive. Examples /* “excerpt” from */ #pragma push extern_data #pragma extern_data no_gp extern int errno; /* References to errno will not use GP-relative addressing.
FIELDALIGN Compiler Pragmas CSHARED2 directs the TNS C, native C, and native C++ compilers to lay out components using the TNS C compiler AUTO alignment rules. Substructures and derived classes with AUTO alignment and pointers with platform-dependent sizes are not allowed when CSHARED2 is specified. SHARED2 directs the TNS C, native C, and native C++ compilers to lay out components using the default TAL compiler SHARED2 alignment rules.
FIELDALIGN Compiler Pragmas Usage Guidelines • • • • • • • • • • • • • • The FIELDALIGN pragma can be entered on the compiler RUN command line or in the source text. It can also be specified with the -Wfieldalign flag of the c89 utility. Components whose sizes are different in TNS mode and native mode (_baddr, _waddr, _near, _sg pointers) are not allowed in CSHARED2, SHARED2, and SHARED8 structures. Components with AUTO alignment are not allowed in CSHARED2, SHARED2, PLATFORM, and SHARED8 structures.
FIELDALIGN Compiler Pragmas ° ° Templates cannot be specified in FIELDALIGN pragmas and always have FIELDALIGN AUTO. Nested structs are not implemented for templates. Templates can contain non-AUTO structs declared using tags. No other pragmas can appear on the same source line as #pragma FIELDALIGN. Examples 1. Global pragma FIELDALIGN is allowed anywhere in the source, not just at the beginning, and it can also be used as an argument to pragmas PUSH and POP.
FORCE_VTBL Compiler Pragmas 4.
FORCE_STATIC_TYPEINFO 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 set Not set TNS/E native C and C++ compilers Not set Not set Usage Guidelines • • • FORCE_VTBL can be entered on the compiler RUN command line (NMCPLUS or CPPCOMP) or be specified with the -Wforce_vtbl option of c89.
FORCE_STATIC_VTBL Compiler Pragmas FORCE_STATIC_VTBL The FORCE_STATIC_VTBL command-line option forces the virtual function tables that are created by the compiler to be static to the file and are not exported. This option is applicable only to variables that are not part of an exported or imported class. FORCE_STATIC_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.
FUNCTION Compiler Pragmas c-function-name is the name used inside the program to refer to the external routine. language is the name of the language of the external routine. tal identifies both TAL and pTAL routines. attribute specifies a function attribute, which is one of: alias ("external-name") identifies the name of the external routine used by Binder or a linker. external-name can include any character that Binder or a linker recognizes.
FUNCTION Compiler Pragmas directs the compiler to treat all parameters of the function as though they were optional, even if some parameters are required by your code. You can add new formal parameters to an extensible function without recompiling callers unless the callers use the new parameters. extensible functions are equivalent to EXTENSIBLE procedures in TAL, pTAL, and D-series Pascal. For more details, see Writing Variable and Extensible Functions on page 9-4.
FUNCTION Compiler Pragmas • • • • • • • • • The extensible and variable attributes cannot both be specified for the same function. If you declare an external procedure as unspecified, the actual procedure cannot be both written in C and compiled using the OLDCALLS pragma. Unlike previous methods for declaring external functions, the FUNCTION pragma is compliant with the ISO/ANSI C standard. The language attribute tal identifies both TAL and pTAL procedures.
HEADERS Compiler Pragmas HEADERS The HEADERS pragma directs the native C and C++ compilers to print a list of included header files. HEADERS 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.
HEAP Compiler Pragmas The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler HEAP 1 PAGES HEAP 1 PAGES G-series TNS c89 utility HEAP 1 PAGES HEAP 1 PAGES TNS/R native C and C++ compilers Not set (see Usage Guidelines) Not set (see Usage Guidelines) Native c89 utility Not set (see Usage Guidelines) Not set (see Usage Guidelines) TNS/E native C and C++ compilers Not set (see Usage Guidelines) Not set (see Usage Guidelines) Usage Guidelines • • • • • • If the RUNNABLE
HIGHPIN Compiler Pragmas causes the value used to be determined by the first of these that has a nonzero value: 1. The pe_heap_max value assigned to the program file by a process that launches it 2. The heap_max attribute of the program file If the heap_max attribute remains zero, all the user data area (minus that area used for global data segments and the argv[] and envp[] arrays) is available for the heap.
HIGHPIN Compiler Pragmas The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler Not set Not set G-series TNS c89 utility HIGHPIN HIGHPIN TNS/R native C and C++ compilers HIGHPIN HIGHPIN Native c89 utility HIGHPIN HIGHPIN TNS/E native C and C++ compilers HIGHPIN HIGHPIN Usage Guidelines • For the TNS C compiler, Cfront, and the TNS c89 utility, the HIGHPIN pragma can be placed in the source text or in the RUN command that executes the compiler.
HIGHREQUESTERS Compiler Pragmas You can set the HIGHPIN flag of a native object file either: • ° During compilation by using the HIGHPIN pragma, if an executable file is produced by the compilation ° After compilation and linking of an executable object file by using an eld, ld, or nld command For more details on using high PINs and converting a C program to run at a high PIN, see the Guardian Programmer’s Guide.
ICODE Compiler Pragmas • For more details on setting the HIGHREQUESTERS object-file attribute, see the Guardian Programmer’s Guide. ICODE The ICODE pragma controls whether the compiler listing includes the instruction-code mnemonics generated for each function immediately following the source text of the function. The ICODE pragma directs the compiler to list these mnemonics, and NOICODE directs it to not list them.
IEEE_FLOAT 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.
IEEE_FLOAT Compiler Pragmas ° • IEEE floating-point denormalized numbers avoid computational problems that arise from very small numbers as intermediate results in computations. Table 13-4 lists the macros in the float.h file that have different values for the two floating-point formats. Table 13-4. IEEE and Tandem Floating-Point Macro Values in float.h Macro Name Tandem Format IEEE Format FLT_ROUNDS 1 1 FLT_RADIX 2 2 FLT_MANT_DIG 23 24 DBL_MANT_DIG 55 53 FLT_EPSILON 2.3841858e-07 1.
INLINE Compiler Pragmas • When converting from fixed-point to floating-point format or from a floating-point number to a narrower floating-point number, IEEE floating point typically rounds to the nearest value according to the current IEEE floating-point rounding mode. When converting from floating-point to fixed-point formats, IEEE floating-point normally truncates the nearest representable value, as specified by the ANSI C standard.
INLINE Compiler Pragmas Usage Guidelines • • • For the native C++ compiler, the INLINE pragma must be entered on the compiler RUN command line. For TNS C and c89 in the OSS environment, the pragmas can be entered on the compiler RUN command line or specified with the -W[no]inline flag of the c89 utility. For the TNS/E native compiler, inlining is not performed for optimization level 0.
INLINE_COMPILER_GENERATED_FUNCTIONS Compiler Pragmas INLINE_COMPILER_GENERATED_FUNCTIONS The INLINE_COMPILER_GENERATED_FUNCTIONS command-line option allows all compiler-generated functions to be inlined. The default behavior is that compiler-generated functions are not inlined and are exported. INLINE_COMPILER_GENERATED_FUNCTIONS 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.
INLINE_STRING_LITERALS Compiler Pragmas 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. 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.
INNERLIST Compiler Pragmas • This pragma is only valid for TNS/R-target compilations. INNERLIST The INNERLIST pragma controls whether the compiler listing includes the instructioncode mnemonics generated for each statement immediately following the source text of the statement. The INNERLIST pragma directs the compiler to list these mnemonics, and NOINNERLIST directs it not to list them.
INSPECT Compiler Pragmas Usage Guidelines • • • • • • • • For native C/C++, the INSPECT pragma must be entered on the compiler RUN command line. For TNS C, the pragma can also be entered in the source file. In the OSS environment, the pragma must be specified with the -W[no]inspect flag of the c89 utility. For TNS programs, the last INSPECT or NOINSPECT pragma in a translation unit determines the default debugger for the entire translation unit.
KR Compiler Pragmas • • NOINSPECT selects, in order of precedence: NonStop S-series NonStop NS-series DEBUG Native Inspect INSPECT selects, in order of precedence: NonStop S-series non-PIC NonStop S-series PIC NonStop NS-series Visual Inspect Visual Inspect Visual Inspect Inspect DEBUG Native Inspect DEBUG When the TACL RUNV command or OSS runv utility is used, then this debugger pragma selects: ° ° ° Visual Inspect on NonStop S-series Visual Inspect on NonStop NS-series for INSPECT Nativ
LARGESYM 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. for C++ Usage Guidelines • • • For native C and C++, the KR pragma must be entered on the compiler RUN command line. For OSS, the KR pragma can be specified with the -Wkr flag of the c89 utility.
LD(arg) Compiler Pragmas used in all compilations, the symbol region might be extremely large. The default action for the compiler is to generate an optimized symbol region. • The native C and C++ compilers do not support this pragma; the compilers generate complete symbols information.
LINES Compiler Pragmas Usage Guidelines • • • • • On Guardian environment, the LD pragma must be entered on the compiler RUN command line for TNS/R native C/C++. On OSS environment, specify the LD pragma by using the -Wld=arg option with the c89 utility. If you are linking non-PIC files, you must use the NLD(arg) pragma, which specifies arguments to the TNS/R native non-PIC linker, the nld utility. The LD pragma does not actually invoke the ld linker.
LINKFILE Compiler Pragmas LINKFILE The LINKFILE pragma invokes the appropriate linker and specifies a command file to be passed to either: • The nld utility when working with conventional code • The eld or ld utility when working with PIC (Position-Independent Code), as when compiling a dynamic-link library (DLL) LINKFILE "file-name" file-name specifies a valid command file for the eld utility, the ld utility, or the nld utility. • For syntax and semantics of eld command files, see the eld Manual.
LIST Compiler Pragmas LIST The LIST pragmas control the generation of compiler-listing text. The LIST pragma enables the generation of compiler-listing text, and the NOLIST pragma disables it.
MAP Compiler Pragmas * specifies both ALPHA and LOC. The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler NOLMAP * NOLMAP * G-series TNS c89 utility NOLMAP * NOLMAP * TNS/R native C and C++ compilers N.A. N.A. Native c89 utility N.A. N.A. TNS/E native C and C++ compilers N.A. N.A. Usage Guidelines • For the TNS C compiler, the LMAP pragma can be entered on the compiler RUN command line or in the source text.
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 and PC TNS C compiler Not set Not set G-series TNS c89 utility N.A. N.A. TNS/R native C and C++ compilers Not set Not set Native c89 utility N.A. N.A.
MAXALIGN Compiler Pragmas ° This MAPINCLUDE pragma changes only the exact file name n.h and does not affect the file name machin.h: mapinclude "n.h" = "e95nh" ° This 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 int J; }; // 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), this 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_alloc() class bad_cast() 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 • • The NLD pragma does not invoke the linker. To invoke nld, you must include other pragmas such as RUNNABLE or LINKFILE. If nld is not invoked, the NLD pragma is ignored.
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.
NON_SHARED Compiler Pragmas ° If you specify the -c option with -Wnon_shared, the linker is not called, and the result is a non-PIC linkable object file (linkfile).
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 compilations 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.
PAGE 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.
POOL_STRING_LITERALS Compiler Pragmas 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. Usage Guidelines • • • • The PAGE pragma cannot appear on the command line, but it can appear at any point in the source text. The quotation marks enclosing title-string are required delimiters; they are not printed. If the title string is longer than 61 characters, the compiler prints only the first 61.
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, 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.
RVU 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 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.
SAVEABEND Compiler Pragmas The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler NOSAVEABEND NOSAVEABEND G-series TNS c89 utility NOSAVEABEND NOSAVEABEND TNS/R native C and C++ compilers NOSAVEABEND NOSAVEABEND Native c89 utility NOSAVEABEND NOSAVEABEND TNS/E native C and C++ compilers NOSAVEABEND NOSAVEABEND Usage Guidelines • • • • • • • The SAVEABEND pragma can appear only on the compiler RUN command line for native C and C++.
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 ° ° ° ° • DLL Programmer’s Guide for TNS/E Systems 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 Compiler Pragmas If you do not specify either SQLMAP or NOSQLMAP, the C compiler assumes NOSQLMAP. 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.
SQL 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 for C, N.A. for C++ Not set for C, N.A. for C++ TNS/R native C and C++ compilers Not set for C, N.A. for C++ Not set for C, N.A. for C++ Native c89 utility Not set for C, N.A. for C++ Not set for C, N.A. for C++ TNS/E native C and C++ compilers Not set for C, N.A. for C++ Not set for C, N.A.
SQL Compiler Pragmas • For PC compilations, many more options exist. See the documentation for the apppropriate PC-based compilation tool.
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. In general, the subvolumes are searched in the order specified in the search subvolume list, starting with SSV0, then SSV1, and so on. SSVn { "[node.]$volume" { "[$volume.
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 However, 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 numeric 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 Examples 1. This example specifies three search subvolumes: c / in testc, out $s.#xxx / obj;run,ssv0 "$a.b", ssv1 "$b.d", ssv2 "$system.system" 2. This example specifies a search subvolume ($A.B) and a search volume ($C): #pragma ssv0 "$a.b", ssv1 "$c" 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.
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 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 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 FORCE_VTBL on page 13-33.
SYNTAX Compiler Pragmas Usage Guidelines • • • For native C and C++ programs, the SYMBOLS pragma can be entered only on the compiler RUN command line or be specified with the -g option of the c89 utility. For TNS C and C++ programs, the SYMBOLS pragma must appear on the compiler RUN command line or at the start of the source text before any declarations or source code statements.
SYSTYPE Compiler Pragmas SYSTYPE The SYSTYPE pragma controls whether the generated code’s target execution environment is the NonStop environment. SYSTYPE { GUARDIAN | OSS } The pragma default settings are: Guardian Environment OSS Environment TNS C compiler GUARDIAN N.A. G-series TNS c89 utility N.A. OSS 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.
TANDEM_FLOAT Compiler Pragmas TANDEM_FLOAT The TANDEM_FLOAT directive specifies that the native C or C++ compiler is to use the proprietary Tandem floating-point format for performing floating-point operations. TANDEM_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.
VERSION1 Compiler Pragmas The pragma default settings are: SYSTYPE GUARDIAN SYSTYPE OSS TNS C compiler NOTRIGRAPH NOTRIGRAPH G-series TNS c89 utility NOTRIGRAPH NOTRIGRAPH 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. 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.
VERSION1 Compiler Pragmas Usage Guidelines • • • • As of G06.20, the default for native mode C++ compilation is VERSION3 (not VERSION1). If you are going to recompile an application that used the previous default (VERSION1), you must specify the VERSION1 pragma. See also VERSION2 on page 13-108 and VERSION3 on page 13-110.
VERSION2 Compiler Pragmas ° • • LIBCOBEY for a TNS/R program (an OBEY file that links the C run-time library and the Common Run-Time Environment [CRE]) VERSION1 supports version 6.1 of Tools.h++. To use the Tools.h++ library (version 6.1) when using VERSION1, you need to link ZTLHGSRL (the Guardian Tools.h++ library) or ZTLHOSRL (the OSS Tools.h++ library). If you are compiling a loadfile (using RUNNABLE in Guardian), you can link to Tools.
VERSION2 Compiler Pragmas ° ° ° ° ° ° ° ° ° ° Namespaces The bool type The wchar_t type Array new and delete Run-time type identification (RTTI) New-style casts (static_cast, reinterpret_cast, and const_cast) Explicit instantiation of templates Support of partial specialization of templates Support of extern inline functions enum types are considered to be nonintegral types These language features are part of the proposed C++ standard introduced by the Working Paper for Draft Proposed International Stan
VERSION3 Compiler Pragmas • • • In the G06.20 RVU, all the native C++ header files were combined into one product number. These headers were modified to identify the version used in the compile and to redirect calls to the correct library.
VERSION3 Compiler Pragmas Wversion3 flag when specifying c89 in the OSS environment. You cannot enter the VERSION3 directive in the source file. • • • VERSION3 is the default version of the native C++ compiler for the G06.20 RVU and for subsequent RVUs until a new version of the compiler is released. If you specify no version directive (or if you include the VERSION3 directive) with the G06.20 native C++ compiler, you will produce a binary that is compatible with binaries produced by the G06.
VERSION3 Compiler Pragmas • • • • ° ° nld Manual noft Manual Before compiling existing applications using VERSION3, you should first use the MIGRATION_CHECK on page 13-62 directive along with the VERSION2 pragma to examine the code for references to functions in changed or unsupported headers. The VERSION3 Standard C++ Library supports wide characters as described in the standard, and converts from Multi-Byte to wide. At the G06.
VERSION3 Compiler Pragmas For information about TNS/R SRLs, see Shared Run-Time Libraries (SRLs) on page 16-13. For more details about the TNS/E DLLs, see Dynamic-Link Libraries (DLLs) on page 17-13.
WARN Compiler Pragmas WARN The WARN pragma controls the generation of all or selected warning messages. The WARN pragma enables the compiler to generate all or a selected set of warning messages, and NOWARN disables the compiler from generating all or a selected set of warning messages. [NO]WARN [ warning-list ] warning-list: ( warning-number [, warning-number ]... ) warning-list is a parenthesized, comma-separated list of warning-message numbers.
WIDE Compiler Pragmas Examples 1. In this example, the compiler generates only warning messages 153 and 157. #pragma nowarn #pragma warn (153,157) 2. In this example, the compiler generates all warning messages except warning 153. #pragma nowarn (153) 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.
XMEM Compiler Pragmas • • • Programs composed of Guardian modules (modules compiled for the Guardian environment) and OSS modules (modules compiled for the OSS environment) must use the 32-bit data model. For more details about the two data models, see Two Data Models: 16-Bit and 32Bit on page 19-9. The preprocessor variable __INT32 is defined when the WIDE pragma is in effect. XMEM The XMEM pragma controls which memory model, large or small, the object file uses.
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.
XVAR Compiler Pragmas HP C/C++ Programmer’s Guide for NonStop Systems —429301-010 13- 118
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 There are two TNS C compilers. One compiler runs in the Guardian environment, and the other compiler runs in the OSS environment. Each compiler compiles Guardian and OSS programs and produces identical code. However, each compiler has different default pragma settings.
Compiling, Binding, and Accelerating TNS C Programs • • Specifying Header Files You cannot use the RUNNABLE and SEARCH pragmas. However, you can direct the TNS c89 utility to bind implicitly after a compilation. You can also specify library files to be searched using the TNS c89 -L flag. 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.
Compiling, Binding, and Accelerating TNS C Programs Working in the Guardian Environment For more details, see the TNS c89 online reference page. To view this reference page, enter: man -M /nonnative/usr/share/man c89 The c89 reference page in D40 and later versions of the Open System Services Shell and Utilities Reference Manual describes the native c89 utility.
Compiling, Binding, and Accelerating TNS C Programs Compiling a C Module [ RUN ] C is the TACL command to start the C compiler process. Note that the command keyword RUN is optional. IN source specifies the primary source file of the 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.
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 For more details on selecting the correct model-dependent library file, see Specifying Library Files on page 14-8. The model-dependent-library-file file name must be fully qualified. The files are located in $SYSTEM.SYSTEM by default. SELECT RUNNABLE OBJECT ON directs Binder to create an executable object file (a program file) when it builds the object file.
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 details, see the Binder Manual.
Compiling, Binding, and Accelerating TNS C Programs Working in the OSS Environment To save time in accelerating your programs, to produce the smallest possible accelerated object files, and to ensure that the Accelerator or OCA produces the most efficient code, to do these: • • Use C function prototypes for all your C routines. Generate and retain the Binder and Inspect symbols regions for your programs.
Compiling, Binding, and Accelerating TNS C Programs Components of the TNS c89 Utility Components of the TNS c89 Utility The TNS c89 utility enables you to compile ISO-compliant C programs for NonStop environment. By default, c89 generates code for the OSS environment.
Compiling, Binding, and Accelerating TNS C Programs Using the TNS c89 Utility Table 14-5 summarizes commonly used operands. Table 14-5. Commonly Used TNS c89 Operands To specify this type of file Specify this operand A C source file filename.c An object file filename.o Table 14-6 summarizes commonly used TNS c89 flags and describes equivalent Guardian environment actions. Table 14-6.
Compiling, Binding, and Accelerating TNS C Programs Binding an OSS TNS Module Table 14-6. Commonly Used TNS c89 Flags and Guardian Environment Equivalents (page 2 of 2) Equivalent Guardian environment action To direct c89 to: Specify this flag: Select dynamic binding -WBdynamic No equivalent in the Guardian environment Select static binding -WBstatic Default behavior Suppress the invocation of Binder -Wnobind Do not specify the RUNNABLE pragma Use the pathname outfile instead of the default a.
Compiling, Binding, and Accelerating TNS C Programs Examples of Working in the OSS Environment libraries can be used for dynamic binding. The Binder resolves external references using all the specified static libraries before using the SRL. Binding Considerations • • • To bind a Guardian program with the TNS c89 utility, specify the libgwc.a library. libgwc.a is equivalent to the Guardian file CWIDE. The -Wsystype=guardian flag sets the default library to libgwc.a.
Compiling, Binding, and Accelerating TNS C Programs Examples of Working in the OSS Environment 6. In this example, c89 compiles the source file gprogram.c and binds the object file into program file a.out. Binder uses the default library for the Guardian environment, libgwc.a, to resolve external references. Static binding is performed: c89 -Wsystype=Guardian gprogram.c 7. In this example, c89 produces a statically bound program: c89 -o test3 -O -D TYPE=3 -I /usr/myself/header -I /usr/friend -WBstatic x1.
Compiling, Binding, and Accelerating TNS C Programs Examples of Working in the OSS Environment HP C/C++ Programmer’s Guide for NonStop Systems —429301-010 14 -18
15 Compiling, Binding, and Accelerating TNS C++ Programs • • Working in the Guardian Environment ° 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-10 ° 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-14 ° TNS c89 Flags on page 15-15 ° TNS c89 Operands on page 15-16 °
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment step, and what is the possible output from each compilation step. This section provides you with this information. 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.
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 more details, see SSV on page 13-96. pragma is a C compiler pragma.
Compiling, Binding, and Accelerating TNS C++ Programs • Working in the Guardian Environment Cprep and Cfront both send error and warning messages to stderr. The default location for stderr is the terminal. You can assign stderr to a specific file and collect all Cprep and Cfront error and warning messages there. To send error and warning messages to a file, assign stderr to the desired file name prior to invoking Cprep.
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 Cprep and Cfront both send error and warning messages to stderr. The default location for stderr is the terminal. You can assign stderr to a specific file and collect all Cprep and Cfront error and warning messages there. To send error and warning messages to a file, assign stderr to the desired file name prior to invoking Cprep.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment run-options is a comma-separated list of additional options for the RUN command. These options are described in the TACL Reference Manual. Object specifies the file to which the TNS 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.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment File Formats The input to Cprep is a C++ source file of a form acceptable to the TNS C run-time library: • EDIT disk files, which are file type 101 • C disk files, which are odd-unstructured files and are file type 180 • Processes • 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.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment Before compiling this program, purge any existing intermediate files: purge intfile1 purge intfile2 To compile this program, enter these run commands: cprep/in progcp, out intfile1/define __cplusplus, & SSV0 "$system.system" cfront/in intfile1, out intfile2/ c/in intfile2, out $s.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment The total count of errors and warnings appears as a comment after the error and warning messages. Cprep's error and warning messages that appear in stderr are a subset of those of the TNS C compiler. For descriptions of the TNS C compiler error and warning messages, see Section 20, TNS C Compiler Messages.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the Guardian Environment SELECT CHECK PARAMETER OFF disables checking of parameter number, type, and mode (value or reference) and of function return type across code blocks. If you do not disable these checks, Binder might generate several extraneous warning messages.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the G-Series OSS Environment For more details regarding Binder and its commands, see the Binder Manual. Requirements for Binding Modules These requirements apply when you are binding two or more compiled modules to create a single executable C++ object file: • • Each of the C++ modules must be based on the same data model.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the G-Series OSS Environment The simplified syntax of the TNS c89 utility is: c89 [flag...] operand... flag is a valid c89 utility flag. operand, is a valid c89 utility operand. TNS c89 Flags You can invoke Cfront through the TNS c89 utility with the -Wcfront flag using this syntax: -Wcfront[="args"] When TNS c89 sees the ="args" portion of the -Wcfront flag, c89 passes to Cprep the argument string enclosed in the double quotation marks.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the G-Series OSS Environment Table 15-2. Commonly Used TNS c89 Flags (page 2 of 2) Flag Function -Wsystype=guardian Specifies the Guardian execution environment. -Wsystype=oss Specifies the OSS execution environment (this is the default environment). -Wverbose Displays more detailed information during the program generation process from the C compiler, Binder, Accelerator, and SQL compiler.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the G-Series OSS Environment Input Files Input files to TNS c89 can be: • C++ language source files • TNS object files generated by c89 -c • Libraries of TNS object files produced by the ar utility • Libraries of TNS object files produced by Binder • Executable TNS object files produced by Binder Binding The -lc and -lC operands specify these libraries: -lc This library contains all library functions specified in the POSIX.
Compiling, Binding, and Accelerating TNS C++ Programs Working in the G-Series OSS Environment 3. This example preprocesses hello.C with Cprep and translates it with Cfront. The output from Cfront is saved in a file named hello.i. No compilation by the TNS C compiler is performed because the -Wcfonly flag has been specified. c89 -Wcfonly -o hello.i 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 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, in addition to variables and types that complete that set.
Compiling and Linking TNS/R Native C and C++ Programs Compiling and Linking Floating-Point Programs You might also need to specify header files for the Standard C++ Library and Tools.h++ library 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/R Native C and C++ Programs Using Compiler Pragmas IEEE_Float and Tandem_Float Tandem Floating-Point Format IEEE Floating-Point Format (continued) Remains default format on TNS and TNS/R systems, and is available for TNS C and C++, FORTRAN, TAL, pTAL, Pascal, COBOL, and native C and C++ programs For TNS/R native C and C++ programs, IEEE floating-point format becomes effective only by specifying IEEE_FLOAT in the command directive Requires conversion routines for data intercha
Compiling and Linking TNS/R Native C and C++ Programs Using Link Options to Specify Floating-Point Format When modifying an existing object file, TNS/R native linker sets the state as specified by the -change floattype flag. Link-Time Consistency Checking The TNS/R native linker 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 shows the results of each floating-point state when the floattype attribute is explicitly specified. Table 16-4. Floating-Point State as Determined by TNS/R Native Linker 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.
Compiling and Linking TNS/R Native C and C++ Programs Using Link Options to Specify Floating-Point Format using one floating-point format calls a function using the other format. Checks are performed 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 This example illustrates linking a mixed-language program that uses IEEE floatingpoint format: > ld $system.system.ccppmain cobj ptalobj -obey & $system.system.libcobey -set floattype ieee_float -o myexec 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.
Compiling and Linking TNS/R Native C and C++ Programs • Compiling a Module A nonexecutable object file, if the compiler encountered no errors during the compilation. After compiling all the modules that compose your program, you collect and combine them into a program file (an executable object file) by using the nld utility for conventional code or the ld utility for PIC (Position-Independent Code).
Compiling and Linking TNS/R Native C and C++ Programs Compiling a Module IN source specifies the primary source file of the module. The file must be a valid Guardian file name for either a type 101 (EDIT) or type 180 disk file. Interactive input from a terminal or a process is not accepted. 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.
Compiling and Linking TNS/R Native C and C++ Programs Linking a TNS/R Module Usage Guidelines • • The 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 compiler returns one of these completion codes: 0 The compilation completed successfully. 1 The compilation completed with warnings (but no errors). 2 The compilation completed with errors.
Compiling and Linking TNS/R Native C and C++ Programs Linking a TNS/R Module This subsection provides a summary of linking C and C++ programs using the nld utility, the TNS/R native linker for conventional applications. For complete details about using nld, see the nld Manual. The ld utility is the linker for PIC (Position-Independent Code).
Compiling and Linking TNS/R Native C and C++ Programs Linking a TNS/R Module packaged as SRLs for TNS/R native processes. HP supplies public SRLs; you cannot create your own public SRLs. Each processor loads its public SRLs at startup from the active SYSnn subvolume. The SYSnn subvolume, located on $SYSTEM, contains a version of the operating system image for a particular node. A node can have more than one SYSnn subvolume, but only one active (running) SYSnn subvolume.
Compiling and Linking TNS/R Native C and C++ Programs • • • • • Linking a TNS/R Module Uses the C run-time library Uses the C++ run-time library Uses the Tools.h++ library (and whether Version 6.1 or Version 7) Uses the Standard C++ Library Uses the TCP/IP sockets library 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 this table, CRTL represents the SRL named ZCRTLSRL (the C run-time library).
Compiling and Linking TNS/R Native C and C++ Programs Linking a TNS/R Module For more details, see: • Section 5, Using the Standard C++ Library • Pragmas VERSION1 on page 13-106, VERSION2 on page 13-108, and VERSION3 on page 13-110 • C++ Run-Time Library and Standard C++ Library on page 1-6 Additional SRLs might be required for other run-time libraries and services.
Compiling and Linking TNS/R Native C and C++ Programs Linking a TNS/R Module Table 16-6. Using the Guardian TNS/R Native Linker Utilities to Link SRLs (page 2 of 2) If your program uses: You should specify these TNS/R native linker utility flags: VERSION2 Standard C++ Library, Tools.h++ (version 7) and runs in the Guardian environment -l ZTLHSRL -l ZRWSLSRL -l ZCPLSRL -OBEY $SYSTEM.SYSTEM.LIBCOBEY or -l ZTLHSRL -l ZRWSLSRL -l ZCPLSRL -l ZCRTLSRL -l ZCRESRL VERSION2 Standard C++ Library, Tools.
Compiling and Linking TNS/R Native C and C++ Programs Linking a TNS/R Module 3. A simplified version of the previous example: > NLD $SYSTEM.SYSTEM.CRTLMAIN MYOBJ -o MYEXEC & -OBEY $SYSTEM.SYSTEM.LIBCOBEY & -l ZTLHSRL -l ZRWSLSRL -l ZCPLSRL 4. Linking with the ld linker and the VERSION3 Standard C++ Library (the default beginning library beginning with G06.20): > LD $SYSTEM.SYSTEM.CCPPMAIN MYOBJ -o MYEXEC & -OBEY $SYSTEM.SYSTEM.LIBCOBEY -l ZSTLSRL 5.
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 For information about compiling and binding native C++ programs using the Windows PC environment, see the online help for the HP Enterprise Tool Kit—NonStop Edition (ETK). In this guide, the Enterprise Tool Kit is introduced in Section 18, Using ETK and Native C/C++ Cross Compiler on the PC.
Compiling and Linking TNS/E Native C and C++ Programs Specifying Header Files These restrictions apply to developing Guardian programs with OSS tools: • • You cannot use the RUNNABLE and SEARCH pragmas. However, you can direct the c89 utility to bind implicitly after a compilation. You can also specify library files to be searched using the c89 -L flag. 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 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 These 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 this 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 TNS/E 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 TNS/E Module A similar initialization file for doing fault-tolerant programming, named CRTLNSE, also might need to be linked. On OSS environment, the file is named crtlnse.o. 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.
Compiling and Linking TNS/E Native C and C++ Programs Linking a TNS/E Module You use the eld utility to create a linkable object file or linkfile. You can also use eld to create an executable (known as a loadable object file or a loadfile) in PIC format that can function as a dynamic-link library (DLL). Shared run-time libraries are not supported for TNS/E code.
Compiling and Linking TNS/E Native C and C++ Programs Linking a TNS/E Module Table 17-5. DLLs Available When Using VERSION2 and VERSION3 (page 2 of 2) VERSION 2 VERSION 3 Guardian OSS Guardian OSS CRTL CRTL CRE CRE OS OSS OS OSS OS OS OS OS Notes: DLL names are shown without the leading Z and these DLL; therefore, CPPC represents ZCPPCDLL, and TLH7 represents ZTLH7DLL. OS represents the HP NonStop OS. OSS represents the Open System Services environment.
Compiling and Linking TNS/E Native C and C++ Programs Linking a TNS/E 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: VERSION2 C++ run-time library and runs in the OSS environment -l -l -l -l VERSION2 Standard C++ Library, Tools.h++ (version 7) and runs in the Guardian environment -l ZTLH7DLL -l ZCRTLDLL -l ZCPP2DLL -l ZCREDLL -l ZCPPCDLL VERSION2 Standard C++ Library, Tools.
Compiling and Linking TNS/E Native C and C++ Programs Linking a TNS/E Module 3. Linking with the eld linker and the VERSION3 Standard C++ Library (the default library): > ELD $SYSTEM.SYSTEM.CCPLMAIN MYOBJ -o MYEXEC & -l ZCPP3DLL -l ZCPPCDLL 4. Compiling PIC (Position-Independent Code) using the default TNS/E 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.
Compiling and Linking TNS/E Native C and C++ Programs Linking a TNS/E Module HP C/C++ Programmer’s Guide for NonStop Systems —429301-010 17 -18
18 Using ETK and Native C/C++ Cross Compiler on the PC • • • • ETK ° Hardware and Software Requirements on page 18-3 ° Online Help on page 18-3 ° Usage Guidelines on page 18-3 TDS on page 18-4 ° Hardware and Software Requirements on page 18-4 ° Online Help on page 18-5 ° 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 ° COBOL85 Cross Compilers on page 18-7 PC Tools on page 18-8 ° HP Extensions for Codewright (TEC
Using ETK and Native C/C++ Cross Compiler on the PC Capabilities of ETK Capabilities of ETK ETK works with Visual Studio.net, and the optional cross compilers to allow application developers to design, build, and deploy applications targeted at the NonStop server environment. ETK release 3 contains features that support TNS/E systems.
Using ETK and Native C/C++ Cross Compiler on the PC Hardware and Software Requirements Hardware and Software Requirements ETK is supported on the Windows NT, Windows 2000, and Windows XP operating systems. For the latest PC and NonStop server hardware and software requirements, review ETK online help. Online Help Online help is the only user documentation for ETK.
Using ETK and Native C/C++ Cross Compiler on the PC TDS files from the server to the PC using file transfer protocol (FTP). When your source files are on the PC, they can be distributed anywhere in the PC namespace. Likewise, any files that are output from the PC cross compilers can be distributed anywhere in the PC namespace. • • • • PC source files with #include path names use the backslash (\) separator. These path names are correctly interpreted by the PC cross compilers.
Using ETK and Native C/C++ Cross Compiler on the PC Online Help Online Help Online help is the only user documentation for TDS. The online help is composed of these components: • Context-sensitive help for GUI objects • Help topics, such as “Setting Compiler Options” • Glossary of terms • Tutorial introducing the application Usage Guidelines TDS version of the TNS/R native C/C++ cross compiler produces object code that runs only on NonStop S-series system in either the Guardian or the OSS environment.
Using ETK and Native C/C++ Cross Compiler on the PC Cross Compilers specifying the Guardian file to c89. Therefore, the Guardian file name $VOL.SUBVOL.FILEC is specified to c89 as /G/VOL/SUBVOL/FILE.c. • Many products have shared run-time libraries (SRLs) for linking on the PC. If a product does not have an SRL on the PC, perform final linking on a NonStop server that does have the appropriate SRL.
Using ETK and Native C/C++ Cross Compiler on the PC • EpTAL Cross Compiler Can produce: ° Object files suitable for input to the TNS/R native linker ° Executable files suitable for running on TNS/R systems These files are identical, except for embedded file names, to objects and executable files created on other platforms by the pTAL compiler.
Using ETK and Native C/C++ Cross Compiler on the PC • • • • • PC Tools Link ECOBOL, C/C++, and EpTAL objects into a single executable file Link NMCOBOL, C/C++, and pTAL objects into a single executable file When multiple RVUs are installed, choose any installed RVUs of the cross compilers, tools, and libraries On ETK and TDS platforms, enter ADD, MODIFY, SET, and DELETE statements into a TACL DEFINE file On ETK and command-line platforms, compile SQL/MP or SQL/MX statements embedded in native COBOL sourc
Using ETK and Native C/C++ Cross Compiler on the PC • • • • Visual Inspect Provides language-specific programming support for C, C++, TAL, pTAL, and COBOL. Features chromacoding, which allows you to select colors to enhance the visibility of comments, keywords, strings, numbers, preprocessor commands, and braces. Improves source readability and helps eliminate typing errors. Allows you to select from several ways to view or collapse source files: by function, by paragraph, by pragma, or by normal view.
Using ETK and Native C/C++ Cross Compiler on the PC HP C/C++ Programmer’s Guide for NonStop Systems —429301-010 18 -10 ar Tool (File Archive)
19 Running and Debugging C and C++ Programs • • • • • • • • • Running Programs in the Guardian Environment Running Programs in the OSS Environment on page 19-2 Program Initialization on page 19-3 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-11 Debugging C and C++ Programs on page 19-12 Running Programs in the Guardian Envi
Running and Debugging C and C++ Programs Running Programs in the OSS Environment IN file-name specifies the standard input file (stdin) for the new process. If you do not include the IN option, the new process uses the command interpreter's default input file, which is usually your home terminal. OUT file-name specifies the standard output file (stdout) for the new process.
Running and Debugging C and C++ Programs Program Initialization Program Initialization Your program begins execution when the operating system transfers control to your program’s object code. Before executing the code, however, the C run-time library initializes its run-time environment. The C run-time library also calls a CRE initialization function.
Running and Debugging C and C++ Programs Invocation of Constructors for Global and Static Variables The three standard files for ANSI-model I/O are associated to physical files: • • • stdin denotes the physical file specified by the IN option of the RUN command. If you do not use the IN option, stdin denotes the command interpreter’s default input file, which is usually your home terminal. stdout denotes the physical file specified by the OUT option of the RUN command.
Running and Debugging C and C++ Programs Parameters to the Function main Parameters to the Function main C enables you to declare up to three parameters to your program’s main function. int main(int argc, char *argv[], char *env[]); argc is an integer value specifying the number of elements in the argument array argv. 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.
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.
Selecting Memory and Data Models Running and Debugging C and C++ Programs Table 19-4. Relationship Between Memory Models and Data Models Memory Model Data Model C Compiler Pragmas Size of Pointer Size of Type int Small 16-bit NOXMEM, NOWIDE 16-bit 16 bits Small 32-bit or wide Not available 16-bit 32 bits Large 16-bit XMEM, NOWIDE 32-bit 16 bits Large 32-bit or wide XMEM, WIDE 32-bit 32 bits Note that the small-memory model and the 32-bit data model cannot be selected together.
Running and Debugging C and C++ Programs Converting Programs to the 32-Bit Data Model Converting Programs to the 32-Bit Data Model HP strongly recommends that you convert your TNS C and C++ programs from the 16-bit data model to the 32-bit (or wide) data model. The native C and C++ compilers do not support the 16-bit data model. This list provides guidelines for this conversion using the TNS C compiler and Cfront: • • Compile your program using the STRICT pragma.
Running and Debugging C and C++ Programs Debugging C and C++ Programs TCP/IP sockets library functions, and Guardian system procedures might require type int. Debugging C and C++ Programs To debug C and C++ programs, you can use several debuggers: • Debug on NonStop S-series systems • Inspect on NonStop S-series or HP Integrity NonStop NS-series systems • Native Inspect on NonStop NS-series systems • The Visual Inspect debugger These subsections introduce some of the features of each debugger.
Running and Debugging C and C++ Programs Native Inspect Native Inspect Native Inspect is a symbolic debugger for NonStop NS-series systems and is based upon the open-source GNU dbg utility. Native Inspect provides both machine-level and source-level process debugging. If you compile your TNS/E native program using the SYMBOLS pragma, you can use the source-level commands to access your process in terms of variables, functions, statements, and other source-level entities.
Running and Debugging C and C++ Programs Visual Inspect Symbolic Debugger HP C/C++ Programmer’s Guide for NonStop Systems —429301-010 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 this 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 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, this #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 these: • a simple variable declaration • an array declaration • a pointer declaration • a function definition or a function prototype. The compiler encountered one of these entities that contains two storage class specifiers.
TNS C Compiler Messages Types of Compiler Messages 179 incompatible type was specified This error message is generated if two types are used to declare a variable. The invalid declaration can comprise two types, or a type and a typedef name, or two typedef names.
Types of Compiler Messages TNS C Compiler Messages 184 format is offsetof ( type , member ) The call to the offsetof function has the wrong parameters. 185 first argument of offsetof is not a structure type The first parameter of the offsetof function must be a structure or union type. 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.
TNS C Compiler Messages Types of Compiler Messages 190 illegal usage of const attribute The C compiler issues this error if a const variable is used in the left-hand side of an assignment. 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 197 illegal conversion to _extensible Only variable functions (functions with the _variable attribute) can be converted to extensible functions. The number specified in the _extensible parameter count argument must be in the range of 1 through 15. 198 illegal number of parameters count/size 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.
TNS C Compiler Messages Types of Compiler Messages 205 tag name cannot be used with fieldalign pragma Pragma FIELDALIGN is used with an enumeration tag. It can be used only with structure and union tags. 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 211 _cspace must be accompanied by const The _cspace qualifier must be specified in conjunction with the const qualifier. 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.
TNS C Compiler Messages Types of Compiler Messages 218 no statement following a label A label has been specified immediately before the end of a compound statement. 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 226 invalid value for enum literal literal-name Enumerated types must be compatible with the type int. Therefore, the value assigned to an enumerated type cannot exceed the range of integer for a given memory model. For example, an int in the large-memory model is 16 bits signed, so an enumerated value cannot exceed 32767. 228 fatal error, compiler terminates The compiler issues this message if physical limitations prevent further compilation.
TNS C Compiler Messages Types of Compiler Messages 235 Unable to position input file The compiler cannot set the position for reading the input file. 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.
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 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 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 (messages 1-10) CRE Service Function Messages on page 22-3 (messages 11-29) Heap-Management Messages on page 22-9 (message 30-39) Function Parameter Message on page 22-12 (message 40) Math Function Messages on page 22-12 (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 error messages th
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 non privileged 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.
CRE Service Function 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 these 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 Recovery. In the TNS environment, the program might have written data in the upper 32K words of the user data segment. The upper 32K words are reserved for TNS CRE and run-time library data. In the native environment, the run-time environment has been corrupted. You may have written data over run-time data structures. Check the program’s logic. Use a symbolic debugger to help isolate the problem or consult your system administrator. 12 Logic error Cause.
CRE Service Function Messages Run-Time Messages 14 Premature takeover Cause. The CRE backup process received an operating system message that it had become the primary process but it had not yet received all of its initial checkpoint information from its predecessor primary process. Effect. The CRE invokes PROCESS_STOP_, specifying the ABEND variant and the text “Premature takeover.” Recovery. If the takeover occurred because of faulty program logic, correct the program’s logic.
CRE Service Function Messages Run-Time Messages Recovery. You might be able to increase the amount of control space available to your program by reducing the number of files your program has open at the same time or by decreasing the size of buffers allocated to open files. 18 Extended Stack Overflow Cause. A module could not obtain sufficient extended stack space for its local data. Effect. Program behavior is language and application dependent. Recovery. Increase the extended stack’s size.
CRE Service Function Messages Run-Time Messages Recovery. Consult your system administrator. 23 Cannot determine filename ( error ) program_name.logical_name Cause. The CRE could not determine the physical file name associated with program_name.logical_name. Effect. The CRE terminates the program. Recovery. Correct the program_name.logical_name and rerun your program. For general information on ASSIGN commands, see the TACL Reference Manual.
CRE Service Function Messages Run-Time Messages Recovery. Correct the ASSIGNs in your TACL environment. For more details on using ASSIGNs, see the TACL Reference Manual. 26 Invalid PARAM value text ( error ) PARAM name 'value' Cause. A PARAM specifies a value that is not defined by the CRE. For example, the value for a DEBUG PARAM must be either ON or OFF: PARAM DEBUG [ ON ] [ OFF ] The CRE reports this error if a DEBUG PARAM has a value other than ON or OFF. error, if present, is a file-system error.
Heap-Management Messages Run-Time Messages 29 Program incompatible with run-time library -- language Cause. The language compiler used features that are not supported by the language run-time library that the program used. Effect. The CRE terminates the program. Recovery. Use a compiler and run-time library that are compatible. You might need to consult your system administrator.
Heap-Management Messages Run-Time Messages 32 Invalid heap or heap control block Process heap size is 0 Cause. The CRE or a run-time library found invalid data in the user heap or in the heap control block. Your program might be writing information over the heap or heap control block. An invalid pointer or indexing operation could cause this error. “Process heap size is 0” appears when your program or a run-time library requested space, but the process has no user heap. Effect.
Heap-Management Messages Run-Time Messages 35 Heap corrupted ( 32-bit_octal_address ) Cause. The CRE or a run-time library found invalid information at location 32-bit_octal_address of the heap. Effect. Program behavior is language and application dependent. Recovery. The program might have written data over the heap. In a small-memory model, the heap is allocated in the lower 32K words of the user data segment, just below the run-time stack.
Function Parameter Message Run-Time Messages 39 C signal raised -- signal Cause. The raise() function is executed in a TNS C program. signal identifies the signal (for example. SIGTERM). Effect. The CRE terminates the program. Recovery. Modify the application so that it does not invoke raise(). 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.
Math Function Messages Run-Time Messages 42 Arccos domain fault Cause. The parameter passed to the arccos 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 arccos function. 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.
Math Function Messages Run-Time Messages 47 Modulo function domain fault Cause. The value of the second parameter to a modulo function was zero. The second parameter to a modulo function must be nonzero. Effect. Program behavior is language and application dependent. Recovery. Modify the program to pass a nonzero value to the modulo function. 48 Exponentiation domain fault Cause. Parameters to a Power function were not acceptable.
Function Parameter Messages Run-Time Messages Function Parameter Messages The CRE or run-time libraries report the messages in this subsection if there is a problem with the parameters passed to a function. 55 Missing or invalid parameter Cause. A required parameter is missing or too many parameters were passed. Effect. Program behavior depends on the function that was called and the language in which it is written. Recovery. Correct the program to pass a valid parameter.
Input/Output Messages Run-Time Messages Input/Output Messages The CRE or run-time libraries report the messages in this subsection if an error occurs when calling an I/O function. 59 Standard input file error ( error ) Unable to open filename Cause. The file system reported an error when a routine tried to access the standard input file. error is a file-system error number. “Unable to open filename” appears when the C run-time library cannot open the standard input file during program initialization.
Input/Output Messages Run-Time Messages this manual and in the language manual for the routine in your program that detected the error. If the error was caused by a write request from the CRE, consult your system administrator. If the error was caused during program initialization, specify an acceptable output file when executing your program. 61 Standard log file error ( error ) Unable to open filename Cause.
Input/Output Messages Run-Time Messages 64 File not open Cause. A request to open a file failed because the file device is not supported. Effect. Program behavior is language and application dependent. Recovery. Consult your system administrator. 65 Invalid attribute value Cause. A parameter to an open operation was not a meaningful value. For example, the CRE_File_Open_ sync_receive_depth parameter must be a nonnegative number.
Input/Output Messages Run-Time Messages 68 Nowait value not accepted Cause. The value of the no_wait parameter to an open operation was not valid in the context in which it was used. For example, it is invalid to specify a nonzero value for no_wait for a device that does not support nowait operations. Effect. Program behavior is language and application dependent. Recovery. Consult your system administrator. 69 Syncdepth not accepted Cause.
Input/Output Messages Run-Time Messages 75 Cannot obtain buffer space Cause. A routine was not able to obtain buffer space. Effect. Program behavior is language and application dependent. Recovery. Program recovery is language and application dependent. 76 Invalid external filename ( error ) Cause. A value that was expected to be a Guardian external file name is not in the correct format. Effect. Program behavior is language and application dependent. Recovery.
Input/Output Messages Run-Time Messages 79 OpenEdit failed ( error ) Cause. A call to OPENEDIT_ failed. error, if present, is the error returned by OPENEDIT_. A negative number is a format error. A positive number is a file-system error number. Effect. Program behavior is language and application dependent. Recovery. For more details, see the Guardian Procedure Calls Reference Manual. 80 Spooler initialization failed ( error ) Cause. An initialization operation to a spooler collector failed.
Input/Output Messages Run-Time Messages 83 Operation incompatible with file type or status (error) Cause. The program attempted an operation on a file whose type or current status is unsuitable for execution of that operation. For example, a COBOL program calls a file manipulation utility for a file that is using Fast I/O. error, if present, is as file-system error number. Effect. Program behavior is language and application dependent. Recovery.
Environment Messages Run-Time Messages Environment Messages 275 Ambiguity in application of errno Cause. errno is defined in the user’s object file. The native CRE reports this error if errno has been defined in the object file, and it is not the same errno defined by the native CRE shared run-time library instance data item errno. Effect. The run-time library terminates your program. Recovery. Make sure the only defined errno in a program is the one defined in the native CRE shared run-time library.
Run-Time Messages Environment Messages HP C/C++ Programmer’s Guide for NonStop Systems —429301-010 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 Method Description ROUND (default)* After rounding down a misaligned address, the system proceeds to access the address, as in G06.16 and earlier RVUs. 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 In TNS mode and accelerated mode, the targets of C and C++ pointers (except pointers to char items) must be aligned on 2-byte memory boundaries for correct operation. The results of odd-byte addresses depend on the specific NonStop server 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.
Handling TNS Data Alignment • C/C++ Misalignment Examples Calculated items ° char subscripts ° Incremented char or void pointers ° Casts of odd-valued integer expressions into a pointer types See: • Example 23-2 on page 23-8 • Example 23-3 on page 23-9 • Example 23-7 on page 23-10 3.
Handling TNS Data Alignment C/C++ Misalignment Examples 8. Addressing an external data item that contains misaligned parts (as short or larger items) If a TNS program uses external data items (files or structures) that have misaligned parts (such as those on computer systems that have no data alignment requirements), it must declare and directly access them as char arrays rather than as short or larger items. See Example 23-6 on page 23-10. 9.
Handling TNS Data Alignment C/C++ Misalignment Examples Example 23-1. C/C++ Null Pointer Check (Item 1b) Change this: struct listnode { int *kind; ... struct listnode *next; }; struct listnode *listhead, *node; node = listhead; while (*node->kind == 4 /* used too soon */ && node != NULL) { ... node = node->next; } To this: struct listnode { int *kind; ... struct listnode *next; }; struct listnode *listhead, *node; node = listhead; while (node != NULL && *node->kind == 4) { ...
Handling TNS Data Alignment C/C++ Misalignment Examples Example 23-3. C/C++ Invalid Cast From char to Integer Pointer (Item 2, Item 10) Change this: /* insert 16-bit length at front of long string: */ unsigned char *name; unsigned short lth; * (unsigned short *) name = lth; To this: /* insert 16-bit length at front of long string: */ unsigned char *name; unsigned short lth; name[0] = lth >> 8; name[1] = lth; Example 23-4.
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.
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 The conversion behavior for IEEE floating-point types is: 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 For each signal recognized by the signal() function, at program startup the handler SIG_DFL is registered for the all the signals by the C runtime. 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.
HP C Implementation-Defined Behavior G.3.14 Library Functions The hyphen character (-) is treated as just another character in the scan list if it is not the first or the last character in the scan list. 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.
G.3.14 Library Functions HP C Implementation-Defined Behavior To alter the Guardian environment list obtained by a call to the getenv() function, use the PARAM command, the syntax for which is: PARAM param_name param_setting param_name is the run-time environment parameter name param_setting is the string that will be returned when getenv is called with param_name as its parameter.
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 No characters have been added to the execution set required by the ISO/ANSI C standard. The direction of printing is left to right, and top to bottom. The decimal point character is a period (.). G.5 Common Extensions There are no common extensions to the formats for time and date. Multibyte Characters and Wide Characters Multibyte characters and wide characters support Asian alphabets that often contain a very large number of characters.
G.5 Common Extensions HP C Implementation-Defined Behavior multibyte characters are members of the so-called extended character set. A regular single-byte C character is just a special case of a multibyte sequence where the sequence has a length of one. Wide Characters • Some of the inconvenience of handling multibyte characters is eliminated if all characters are of a uniform number of bytes or bits.
HP C Implementation-Defined Behavior Translation Limits for Native C Compilers Alignment Issues Native C and C++ considers objects of integral types to exist only on word boundaries. Consequently, it is invalid to use an odd-byte address to access such an object. On TNS/R or TNS/E systems, the results of using an integer type extended pointer containing an odd-byte address are undefined. The code might continue executing or trap.
HP C Implementation-Defined Behavior • • • Implementation-Defined Behavior of TNS C A single struct or union can have 127 members. A single enumeration can have 127 enumeration constants. A single structure declaration can have 15 levels of nested structure or union definitions. Implementation-Defined Behavior of TNS C The ISO standard for C allows implementations to vary in specific instances. This subsection describes the implementation-defined behavior of TNS C.
HP C Implementation-Defined Behavior G.3.2 Environment G.3.2 Environment No library facilities are available to a freestanding program. In a freestanding environment, program termination is: • • • The program termination phase of execution begins when a program returns from the function main, calls the exit() library function, or calls the terminate_program() library function.
HP C Implementation-Defined Behavior • • • G.3.3 Identifiers Asynchronous terminal Paired display and keyboard NonStop OS processes G.3.3 Identifiers No characters beyond 31 are significant in an identifier without external linkage. Beyond 6 characters, only 2 are significant in an identifier with external linkage. Case is significant in an identifier with external linkage. 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 The date and time of translation are always available. 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, see the assert() function in the Guardian TNS C Library Calls Reference Manual.
HP C Implementation-Defined Behavior G.3.14 Library Functions The space characters that are written out to a text stream immediately before a newline character appear when the stream is read back in. Zero null characters may be appended to data written to a binary stream. 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.
HP C Implementation-Defined Behavior G.3.14 Library Functions A call to the perror() function prints the textual error message corresponding to the value of the errno, optionally preceded by a specified string. 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.
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-3.
G.4 Locale Behavior HP C Implementation-Defined Behavior Table A-3.
HP C Implementation-Defined Behavior G.5 Common Extensions G.5 Common Extensions There are no common extensions to the formats for time and date. 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.
G.5 Common Extensions HP C Implementation-Defined Behavior Wide Characters • Some of the inconvenience of handling multibyte characters is eliminated if all characters are of a uniform number of bytes or bits. A 16-bit integer value is used to represent all members because there can be thousands or tens of thousands of ideograms in an Asian character set. Wide characters are integers of type wchar_t, defined in the headers stddef.h and stdlib.
HP C Implementation-Defined Behavior G.5 Common Extensions Alignment Issues TNS C and C++ considers objects of integral types to exist only on word boundaries. Consequently, it is invalid to use an odd-byte address to access such an object. On TNS systems, if an integral type extended pointer contains an odd-byte address, the system ignores the last bit of the address and accesses the object in the even address one byte below.
HP C Implementation-Defined Behavior G.
B TNS C++ Implementation-Defined Behavior • • • HP Specific Features for OSS and Guardian Environments ° Length of Identifiers ° 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-3 ° 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 NonStop SQL/MP on page B-4
TNS C++ Implementation-Defined Behavior Length of String Literals This rule applies to identifiers and global variable names that you provide and that are generated by Cfront as a result of name encoding. 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.
TNS C++ Implementation-Defined Behavior Class Libraries Class Libraries The iostream class library described in The Annotated C++ Reference Manual is available for use with C++. 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 C++ translator and used by the Binder. To indicate that C linkage applies, rather than C++, you must use the extern C construct. 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 Differences Between OSS and Guardian Environments Differences Between OSS and Guardian Environments The OSS and Guardian versions of Cfront each default to generate code that is destined to run in their own environment. This subsection discusses how to target code to run in the other environment and describes the differences that exist between an executable C++ program file in the two environments.
TNS C++ Implementation-Defined Behavior HP C/C++ Programmer’s Guide for NonStop Systems —429301-010 B- 6 Applicable Pragmas
C ASCII Character Set ASCII Character Set in Numeric Order ASCII Character Set in Alphabetic Order on page C-6 Overview The two tables of the ASCII character set contained in this appendix use these column headings: Ord. Character’s ordinal number in the ASCII character set Octal Character’s octal representation (with left and right bytes) Hex. Character’s hexadecimal representation Dec.
ASCII Character Set in Numeric Order ASCII Character Set Table C-1. ASCII Character Set in Numeric Order (page 2 of 5) Octal Ord. Left Right Hex. Dec. Char.
ASCII Character Set in Numeric Order ASCII Character Set Table C-1. ASCII Character Set in Numeric Order (page 3 of 5) Octal Ord. Left Right Hex. Dec. Char.
ASCII Character Set in Numeric Order ASCII Character Set Table C-1. ASCII Character Set in Numeric Order (page 4 of 5) Octal Ord. Left Right Hex. Dec. Char.
ASCII Character Set in Numeric Order ASCII Character Set Table C-1. ASCII Character Set in Numeric Order (page 5 of 5) Octal Ord. Left Right Hex. Dec. Char.
ASCII Character Set in Alphabetic Order ASCII Character Set ASCII Character Set in Alphabetic Order Table C-2 presents the ASCII character set in alphabetic order—that is, alphabetic character codes (in the column labeled “Char.”) are in alphabetic order. Table C-2. ASCII Character Set in Alphabetic Order (page 1 of 4) Octal Char Meaning Ord Left Right Hex. Dec.
ASCII Character Set in Alphabetic Order ASCII Character Set Table C-2. ASCII Character Set in Alphabetic Order (page 2 of 4) Octal Char Meaning Ord Left Right Hex. Dec.
ASCII Character Set in Alphabetic Order ASCII Character Set Table C-2. ASCII Character Set in Alphabetic Order (page 3 of 4) Octal Char Meaning Ord Left Right Hex. Dec.
ASCII Character Set in Alphabetic Order ASCII Character Set Table C-2. ASCII Character Set in Alphabetic Order (page 4 of 4) Octal Char Meaning Ord Left Right Hex. Dec.
ASCII Character Set ASCII Character Set in Alphabetic Order HP C/C++ Programmer’s Guide for NonStop Systems —429301-010 C -10
D • • • • • • • Data Type Correspondence Table D-1, Integer Types, Part 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-4 Table D-5, Structured, Logical, Set, and File Types, on page D-5 Table D-6, Pointer Types, on page D-6 Table D-7, Address Types1, on page D-7 Table D-1 contains 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 (page 2 of 2) D-series Pascal Character Character String CHAR or BYTE value parameter PACKED ARRAY OF CHAR Enumeration, unpacked, < 256 members FSTRING(n) Variable-Length Character String STRING(n) Subrange, unpacked n…m, 0 < n and m < 255 SQL PIC X CHAR CHAR(n) PIC X(n) VARCHAR(n) TAL and pTAL STRING STRING array -- Return Value Size (Words) 1 1 or 2, depends on declared pointer size 1 or 2, depends on declared pointer size 1.
Data Type Correspondence Table D-5. Structured, Logical, Set, and File Types (page 2 of 2) ByteAddressed Structure WordAddressed Structure Logical (true or false) Boolean Set File TAL and pTAL Byteaddressed standard STRUCT pointer Wordaddressed standard STRUCT pointer -- -- -- -- Return Value Size (Words) 1 or 2, depends on declared pointer size 1 or 2, depends on declared pointer size 1 or 2, depends on compiler directive 1 1 1 1. LOGICAL is normally defined as 2 bytes.
Data Type Correspondence Table D-7.
Data Type Correspondence HP C/C++ Programmer’s Guide for NonStop Systems —429301-010 D- 8
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-6 Features Supported in VERSION2 These features are accepted in the VERSION2 dialect of native C++.
Features and Keywords of Version 2 Native C++ Features Supported in VERSION2 initialization to zero as a static object of the class type. [5.2.3 Explicit type conversion (function notation)] • • • • • • • • • • • • • • • 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.
Features and Keywords of Version 2 Native C++ • • • • • • • • • • • • • • • Features Supported in VERSION2 mutable is accepted on nonstatic data member declarations. [7.1.1 (9) Storage class specifiers] Namespaces are implemented, including using declarations and directives. Access declarations are broadened to match the corresponding using declarations. [7.3 Namespaces] Explicit instantiation of templates is implemented. [14.7.2 Explicit instantiation] The typename keyword is recognized. [7.1.5.
Features and Keywords of Version 2 Native C++ • • • • • • • Features Not Supported in VERSION2 Placement delete is implemented. [18.4.1.3 Placement forms] 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 new lookup rules for member references of the form x.A::B and p->A::B are not yet implemented. [3.4.3 Qualified name look up] The notation :: template (and ->template, and so on) is not implemented [3.4.5 Class member access] Template template parameters are not implemented. [14.
Features and Keywords of Version 2 Native C++ Defining Virtual Function Tables Defining Virtual Function Tables Virtual function tables are defined when virtual functions are defined. (These tables are merely declared when there are virtual function declarations.) If a program declares but does not define a virtual function, the declaration exists without the required definition of its corresponding virtual function table (as per the standard).
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 class deque, continued 12.'void init_aux ( InputIterator first, InputIterator last, _RW_is_not_integer)' is not supported in version 3. 13.'void init_aux ( InputIterator first, InputIterator last, _RW_is_integer)' is not supported in version 3. 14.
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 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.'map_pointer node' is not supported 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 ofstream 1.'ofstream(int fd, char* p, int l)' is not supported in version 3. 2.Class 'fstreambase' is not supported in version3 library 5 fstream 1.'ifstream(int fd, char* p, int l)' not supported in version 3. 2.Class 'fstreambase' is not supported in version3 library. 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, in addition to nonPIC 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 OS 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. Denotes fault-tolerant HP computers that: • • Support the NonStop OS.
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 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-010 Glossary -14
Index Numbers 16-bit addressable parameters 3-6 16-bit data model Binder commands 15-13 description of 19-9 TNS/E native C++ compiler 1-14 TNS/E natrive C compiler 1-13 TNS/R native C compiler 1-5 TNS/R native C++ compiler 1-6 32-bit data model Binder commands 15-13 data model 7-9 description of 19-9, 19-11 TNS/E native C compiler 1-13 TNS/E native C++ compiler 1-14 TNS/R native C compiler 1-5 TNS/R native C++ compiler 1-6 Type int 2-22 32-bit int 2-22 A Abnormal program termination 23-5 abort native C A-8
B Index B Backup process description of 4-8 using DLLs 17-13 using SLLs 16-14 Binary operator (##) 12-17 Binder description of 1-2 TNS c89 utility 14-13 TNS/R native linkers 1-8 Binder region 14-12 Binding CLIB 14-9 CRELIB 14-9 C module 14-6 C++ programs Guardian environment 15-12 OSS environment 15-17 examples 14-16 for the CRE 14-10 internationalized programs 14-16 rules 14-10 selecting library files 14-8, 14-16 Bit fields manipulating in TAL and C 7-23 UNSIGNED and C packed 7-23 user-defined features n
C Index run-time library (continued) TNS/E Native 1-14 TNS/R native 1-6 using c 4-1 standard 1-1 TAL and C guidelines 7-7 Tandem extensions components 1-13 TNS/R Native 1-5 c89 utility flags 14-13, 15-15 generating TNS/R code on NonStop NS-series systems 16-1, 17-1 input files 15-17 operands 14-13, 15-16 OSS environment 14-12, 15-14 RVU pragma 13-82 syntax 14-13 Calling procedures C calling TAL 7-11, 8-9 pTAL calling C 8-8 TAL calling C 7-10 CALL_SHARED pragma description of 13-12 example 16-18, 17-17 Cap
D Index Completion codes 15-11 Complying with standards 1-19 Consolidating compilation steps 15-1 Constructors 19-4 COSS file 14-9 CPATHEQ pragma 5-12, 6-6, 13-15 CPPCOMP command syntax 17-10 CPPINIT file 13-110 CPPINIT2 file 13-13, 13-110 CPPINIT3 file 13-112 CPPINIT4 file 13-13, 13-112 CPPNEUTRAL flag 5-14 CPPONLY pragma 13-17, 13-86 Cprep command syntax 15-4 execution of 15-1, 15-3, 15-14 CRE description of 7-1, 8-2, 19-3 service messages 22-3 CRELIB file 14-9 Cross compiler, PC 18-6 CRTLMAIN file 16-1
E Index Default misalignment handling method 23-4 DEFINE directive 12-2 Development platform 14-2, 16-2, 17-2 Diagnostic message format TNS C A-15 TNS/R native C A-2 Dialect See VERSION1 or VERSION2 Directives, preprocessor See Preprocessor directives Displaying native code 1-9, 1-16 DLL See Dynamic-link library (DLL) DLLs linking in 17-13 Dynamic binding 14-9 Dynamic-link library (DLL) description of Glossary-3 example 16-18, 17-17 Export attribute 2-4 SHARED 13-86 E EDIT files description of 4-4, 15-10
F Index extensible attribute 9-5 Extensions attribute specifier 2-10 attributes of 2-1 _cc_status 2-7 _cspace 2-9 _lowmem 2-2 EXTENSIONS pragma 2-1, 13-24 External data items 23-7 External functions 23-6 External procedures, interfacing to 7-1 EXTERN_DATA pragma 13-13, 13-27 F FAIL misalignment handling method 23-4 Fault tolerance 4-8 Fault-tolerant programming 4-8 Feature-test macros 1-20, 12-13 FIELDALIGN pragma 13-29 File formats 15-10 File types 4-3 Files binary 4-3 C 4-4 EDIT 4-4 logical 4-3 physica
H Index Global data sharing C data with pTAL modules using BLOCK declarations 8-15 sharing C data with TAL modules using BLOCK declarations 7-17 using pointers 7-15, 8-14 sharing pTAL data with C modules using pointers 8-13 sharing TAL data with C modules using BLOCK declarations 7-17, 8-15 using pointers 7-14 Guardian and OSS, TNS C++ B-5 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
K Index Inspect debugger 1-2, 1-8, 13-83 description of 19-12 symbols region 14-12 syntax 13-103 types 13-73 INSPECT pragma 13-51, 13-103 Inspect utility 13-52, 13-53 Instruction Failure trap (trap #1) 23-4 int data type 16 bits 7-9 32 bits 7-9 Integers user-defined features TNS C A-18 TNS/R Native C A-3 Integers, size of 1-5, 1-6, 1-13, 1-14 Interface declarations description of 7-3 extenal routines 8-2 pTAL routines 8-9 TNS C routines 7-11 Interfacing to OSS functions 3-6 Standard C Run-Time Library, TN
M Index using nld 16-14 libc.a 14-15 libc.obey file 16-14 libc.so 14-15 libgwc.a 14-16 LIBLA file 15-13 libm.
N Index Messages compiler 21-1 CRE service 22-3 function parameter 22-12, 22-15 heap management 22-9 input/output (I/O) 22-16 math function 22-12, 22-14 MIGRATION_CHECK F-1 trap 22-1 Migration tool TNS/E native C and C++ 1-17 TNS/R native C and C++ 1-10 TNS/R or TNS/E 11-1 MIGRATION_CHECK pragma F-1 MISALIGNLOG attribute (SCF) attributes of 23-3 misalignment tracing facility and 23-2 Misdeclared external functions 23-6 Mixed-language programming considerations 2-10 for TNS 7-1 for TNS/R and TNS/E 8-2 TAL
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 description of 2-18 _arg_present 2-18 _bitlength 2-18 _optional 2-19 OPTFILE pragma 13-71 OPTIMIZE pragma 13-70, 13-72 OSS environment and Guardian, TNS C++ B-5 c89 utility 14-12 developing in 14-12 file interoperability 4-10 running programs from 19-2 with G-series 15-14 OSS functions 3-6, 4-10 OSS tools 14-12 OSS_TARG
R Index Preprocessor (continued) feature-test macros 12-13 operators 12-16 predefined macros 12-11 predefined symbols 12-12 Primary process 4-8 PROC parameter type passing C routines to pTAL 8-23 passing C routines to TAL 7-25 passing pTAL routines to C 8-22 passing TAL routines to C 7-24 Process pairs 4-8 Processes attributes of 1-8 description of 4-5 PROC(32) parameter type passing C routines to TAL 7-25, 8-23 passing TAL routines to C 7-24, 8-22 Production systems 23-4 Program initialization 19-3 start
S Index RUNNAMED pragma 13-80 Running a C program 19-1, 19-2 Run-time environment 7-2, 14-10 errors and warnings 22-1 libraries 9-1, 14-12, 19-3, B-5 initialization 16-14, 17-13 rwstdex header 5-8 S Sample C++ program 15-10 SAVEABEND pragma 13-82 SCF user interface misalignment handling and 23-3 misalignment tracing facility and 23-2 SEARCH pragma 13-84, 15-6 Search subvolumes 13-96 SECTION pragma 13-85, 15-3 SEGMENT_ALLOCATE_ procedure 7-27 SEGMENT_DEALLOCATE_ procedure 7-27 SEGMENT_USE_ procedure 7-27
T Index Standard C++ Library definition 5-1, 16-14, 17-14 example files included 5-9 using pragmas MAPINCLUDE and CPATHEQ 5-12 VERSION1 directive 13-106 VERSION2 directive 13-109 VERSION3 directive 13-111 Standard indirection, TAL and C guidelines 7-17 Standard library 1-2, B-3 Standards conformance 1-1, 1-19, 2-1 Startup information retrieval 4-11, 19-6 Statements user-defined features Native C A-5 TNS C A-20 Static binding 14-9 stderr file 15-6, 15-8, 15-11, 19-4 stdexcept header file 5-8 STDFILES pragm
U Index TAL and C guidelines (continued) structures 7-19, 8-18 TAL calling C 7-10 UNSIGNED and C bit fields 7-23 tal.
V Index V Value parameters passing C routines to TAL 7-25, 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-106 VERSION2 features E-1 VERSION2 library 5-5 VERSION2 pragma c++ library 1-7, 1-14 description of 13-108 guidelines 13-45 using with MIGRATION_CHECK pragma F-1 VERSION3 library 5-4 VERSION3 pragma 1-7, 1-15, 13-110 Virtual function tables 13-101, E-6 Visual Inspect description of 19-13 OPTIMIZE 13-7
Special Characters Index ZSTLSRL 13-112, 16-15, 16-17, 17-14 ZSYSC file 3-2 ZTLH7DLL 17-16 ZTLHSRL 16-17 ZUTILDLL 17-16 ZUTILSRL 16-17 Special Characters $RECEIVE 4-5 -Wcplusplus 5-12 -Wnld_obey option 13-108 -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, 9-4 _extensible attribute 2-12, 8-6 _far pointer modifier 2-15 _GUARDIAN_HOST
Special Characters Index HP C/C++ Programmer’s Guide for NonStop Systems—429301-010 Index -18
