Porting between HP C and VMS C

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:

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. HP 9000 workstations and servers treat 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, HP 9000 workstations and servers detect 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 implicitly 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 HP 9000 workstations and servers, change the typedef to include the type specifier:

typedef unsigned long t;
t x;

Or use a #define:

#define t long
unsigned t x;

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:

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.

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.