Open System Services Programmer's Guide

◦ Avoid hardcoding bit shift values
◦ Avoid hardcoding constants with malloc()and malloc32()
• Bit Shifts and Bit Masks – Bit shifts and bit masks are sometimes coded with the assumption
that the operations are performed in variables that have the same data type as the result. In
cases such as:
a = b operation c
The data type used for the intermediate result of the operation depends on the types of b and
c. The intermediate result is then promoted to the type of a. If the result requires 64 bits, but
b and c are 32-bit data types, then the intermediate result either overflows or is truncated
before being assigned to a.
In the following example, the left operand 1 is a small numeric constant that the compiler
treats as a 32-bit value in both ILP32 and LP64:
unsigned long y;
y = (1 << 32); /* Overflows in both data models. */
This bit shift uses a 32-bit data type as the intermediate result. In 64-bit mode, the operation
overflows and the final result is undefined.
You can use suffixes such as L and UL for long and unsigned long if you need long
constants. For example, in 64-bit mode, the above code fragment can be changed to:
y = (1L << 32); /* 2^32 in LP64. Overflows in ILP32. */
Step 4: Compile in the LP64 Data Model
To compile in the LP64 data model, update makefiles with the appropriate options:
• -Wlp64: For Windows and OSS compiles.
• lp64: For Guardian compiles.
• See “Linker Object Files” (page 297) for details of eld -set data_model options.
If you are building 64-bit applications, verify that 64-bit versions of the NonStop DLLs are installed.
Compiling Code for Both ILP32 and LP64 Data Models
If you have code that needs to be compiled for both ILP32 and LP64 data models and the code is
slightly different between the two models, you can use the __LP64 feature test macro, which is
automatically set to 1 when either the -Wlp64 or the LP64 compiler option is specified. For
example:
#if __LP64
64–bit code goes here
#else
32–bit code goes here
#endif
64-Bit TNS/E Debugger Support
Beginning with the H06.24 and J06.13 RVUs, Native Inspect is derived directly from the industry
standard GDB debugger, version 6.8. The GUI debugging interface is provided by an enhanced
version of Eclipse that uses Native Inspect as its server.
You have two choices for debugging 64-bit programs: command-line-based Native Inspect and
the Eclipse-based NonStop Development Environment for Eclipse (NSDEE) GUI. To use the NSDEE
debugger, the application must be built by the NSDEE IDE, either locally (using Windows hosted
cross-compilers) or remotely using TNS/E compilers. NSDEE uses Native Inspect to implement
debugging operations.
310 64-Bit Support in OSS and Guardian