HP 3000 Manuals HP 3000 Manuals
Porting between HP C and VMS C
The C language itself is easy to port from VMS to HP-UX for two main
reasons:
* There is a high degree of compatibility between HP C and other
common industry implementations of C as well as within the HP-UX
family.
* The C language itself does not consider file manipulation or
input/output to be part of the core language. These issues are
handled via libraries. Thus, C avoids some of the thorniest
issues of portability.
In most cases, HP C (in compatibility mode) is a superset of VMS C.
Therefore, porting from VMS to HP-UX is easier than porting in the other
direction. The next several subsections describe features of C that can
cause problems in porting.
Core Language Features
* Basic data types in VMS have the same general sizes as their
counterparts on HP-UX. In particular, all integral and floating-
point types have the same number of bits. structs and unions do
not necessarily have the same size because of different alignment
rules.
* Basic data types are aligned on arbitrary byte boundaries in VMS
C. HP-UX counterparts generally have more restrictive alignments.
* Type char is signed by default on both VMS and HP-UX.
* The unsigned adjective is recognized by both systems and is usable
on char, short, int, and long. It can also be used alone to refer
to unsigned int.
* Both VMS and HP-UX support void and enum data types although the
allowable uses of enum vary between the two systems. HP-UX is
generally less restrictive.
* The VMS C storage class specifiers globaldef, globalref, and
globalvalue have no direct counterparts on HP-UX or other
implementations of UNIX. On HP-UX, variables are either local or
global, based strictly on scope or static class specifiers.
* The VMS C class modifiers readonly and noshare have no direct
counterparts on HP-UX.
* structs are packed differently on the two systems. All elements
are byte aligned in VMS whereas they are aligned more
restrictively on the different HP-UX architectures based upon
their type. Organization of fields within the struct differs as
well.
* Bit-fields within structs are more general on HP-UX than on VMS.
VMS requires that they be of type int or unsigned whereas they may
be any integral type on HP-UX.
* Assignment of one struct to another is supported on both systems.
However, VMS permits assignment of structs provided the types of
both sides have the same size. HP-UX is more restrictive because
it requires that the two sides be of the same type.
* VMS C stores floating-point data in memory using a proprietary
scheme. Floats are stored in F_floating format. Doubles are
stored either in D_floating format or G_floating format.
D_floating format is the default. HP-UX uses IEEE standard
formats which are not compatible with VMS types but which are
compatible with most other industry implementations of UNIX.
* VMS C converts floats to doubles by padding the mantissa with 0s.
HP-UX uses IEEE formats for floating-point data and therefore must
do a conversion by means of floating-point hardware or by use of
library functions. When doubles are converted to floats in VMS C,
the mantissa is rounded toward zero, then truncated. HP-UX uses
either floating point hardware or library calls for these
conversions.
The VMS D_floating format can hide programming errors. In
particular, you might not immediately notice that mismatches exist
between formal and actual function arguments if one is declared
float and the counterpart is declared double because the only
difference in the internal representation is the length of the
mantissa.
* Due to the different internal representations of floating-point
data, the range and precision of floating-point numbers differs on
the two systems according to the following tables:
Table 5-3. VMS C Floating-Point Types
---------------------------------------------------------------------------------------
| | | |
| Format | Approximate Range of |x| | Approximate Precision |
| | | |
---------------------------------------------------------------------------------------
| | | |
| F_floating | 0.29E-38 to 1.7E38 | 7 decimal digits |
| | | |
| D_floating | 0.29E-38 to 1.7E38 | 16 decimal digits |
| | | |
| G_floating | 0.56E-308 to 0.99E308 | 15 decimal digits |
| | | |
---------------------------------------------------------------------------------------
Table 5-4. HP-UX C Floating-Point Types
---------------------------------------------------------------------------------------
| | | |
| Format | Approximate Range of |x| | Approximate Precision |
| | | |
---------------------------------------------------------------------------------------
| | | |
| float | 1.17E-38 to 3.40E38 | 7 decimal digits |
| | | |
| double | 2.2E-308 to 1.8E308 | 16 decimal digits |
| | | |
| long double | 3.36E-4932 to 1.19E4932 | 31 decimal digits |
| | | |
---------------------------------------------------------------------------------------
* VMS C identifiers are significant to the 31st character. HP-UX C
identifiers are significant to 255 characters.
* register declarations are handled differently in VMS. The register
reserved word is regarded by the compiler to be a strong hint to
assign a dedicated register for the variable. On Series 300/400,
the register declaration causes an integral or pointer type to be
assigned a dedicated register to the limits of the system, unless
optimization at level +O2 or greater is requested, in which case
the compiler ignores register declarations. Series 700/800 treats
register declarations as hints to the compiler.
* If a variable is declared to be register in VMS and the & address
operator is used in conjunction with that variable, no error is
reported. Instead, the VMS compiler converts the class of that
variable to auto. HP-UX compilers will report an error.
* Type conversions on both systems follow the usual progression
found on implementations of UNIX.
* Character constants (not to be confused with string constants) are
different on VMS. Each character constant can contain up to four
ASCII characters. If it contains fewer, as is the normal case, it
is padded on the left by NULLs. However, only the low order byte
is printed when the %c descriptor is used with printf.
Multicharacter character constants are treated as an overflow
condition on Series 300/400 if the numerical value exceeds 127
(the overflow is silent). In compatibility mode, Series 700/800
detects all multicharacter character constants as error conditions
and reports them at compile time.
* String constants can have a maximum length of 65535 characters in
VMS. They are essentially unlimited on HP-UX.
* VMS provides an alternative means of identifying a function as
being the main program by the use of the adjective main program
that is placed on the function definition. This extension is not
supported on HP-UX. Both systems support the special meaning of
main(), however.
* VMS implicity initializes pointers to 0. HP-UX makes no implicit
initialization of pointers unless they are static, so
dereferencing an uninitialized pointer is an undefined operation
on HP-UX.
* VMS permits combining type specifiers with typedef names. So, for
example:
typedef long t;
unsigned t x;
is permitted on VMS. This is permitted only in compatibility mode
on Series 300/400; it is not allowed in ANSI C mode on any HP-UX
system. To accomplish this on Series 700/800, change the typedef
to include the type specifier:
typedef unsigned long t;
t x;
Or use a #define:
#define t long
unsigned t x;
Preprocessor Features
* VMS supports an unlimited nesting of #includes. HP-UX in
compatibility mode guarantees 35 levels of nesting. HP-UX in ANSI
mode guarantees 57 levels of nesting.
* The algorithms for searching for #includes differs on the two
systems. VMS has two variables, VAXC$INCLUDE and C$INCLUDE which
control the order of searching. HP-UX follows the usual order of
searching found on most implementations of UNIX.
* #dictionary and #module are recognized in VMS but not on HP-UX.
* The following symbols are predefined in VMS but not on HP-UX: vms,
vax, vaxc, vax11c, vms_version, CC$gfloat, VMS, VAX, VAXC, VAX11C,
and VMS_VERSION.
* The following symbols are predefined on all HP-UX systems but not
in VMS:
__hp9000s300 on Series 300/400
__hp9000s700 on Series 700
__hp9000s800 on Series 700/800
__hppa on Series 700/800
__hpux and __unix on all systems
* HP-UX preprocessors do not include white space in the replacement
text of a macro. The VMS preprocessor does include the trailing
white space. If your HP C program depends on the inclusion of the
white space, you can place white space around the macro
invocation.
Compiler Environment
* In VMS, files with a suffix of .C are assumed to be C source
files, .OBJ suffixes imply object files, and .EXE suffixes imply
executable files. HP-UX uses the normal conventions on UNIX that
.c implies a C source file, .o implies an object file, and a.out
is the default executable file (but there is no other convention
for executable files).
* varargs is supported on VMS and all HP-UX implementations. See
vprintf(3S) and varargs(5) for a description and examples.
* curses is supported on VMS and all HP-UX implementations. See
curses(3X) for a description.
* VMS supports VAXC$ERRNO and errno as two system variables to
return error conditions. HP-UX supports errno although there may
be differences in the error codes or conditions.
* VMS supplies getchar and putchar as functions only, not as macros.
HP-UX supplies them as macros and also supplies the functions
fgetc and fputc which are the function versions.
* Major differences exist between the file systems of the two
operating systems. One of these is that the VMS directory
SYS$LIBRARY contains many standard definition files for macros.
The HP-UX directory /usr/include has a rough correspondence but
the contents differ greatly.
* A VMS user must explicitly link the RTL libraries
SYS$LIBRARY:VAXCURSE.OLB, SYS$LIBRARY:VAXCRTLG.OLB or
SYS$LIBRARY:VAXCRTL.OLB to perform C input/output operations. The
HP-UX input/output utilities are included in /lib/libc, which is
linked automatically by cc without being specified by the user.
* Certain standard functions may have different interfaces on the
two systems. For example, strcpy() copies one string to another
but the resulting destination may not be NULL terminated on VMS
whereas it always will be on HP-UX.
* The commonly used HP-UX names end, edata and etext are not
available on VMS.