VX/Cpp Convert OpenVMS C to ANSI C - OpenVMS Migration

VX/Cpp (VX C language pre-processor) is Sector7's automated tool for identifying flagging and correcting OpenVMS C source code to produce portable POSIX compliant source code. VX/Cpp will also detect processor-specific problems and correct them This documents the operation of VX/Cpp and the functions that it performs.


Learn More


VX/Cpp is intended to be run in much the same manner as a C compiler. A command line that may contain switch settings and a C source file name invokes the program. VX/Cpp accepts most of the usual C compiler switches so that a Makefile constructed for compiling a system of source code may be easily transformed into a VX/Cpp processing file. In addition to the C compiler-like switches, VX/Cpp accepts its own switch s for directing which features and functions are to be performed. A configuration file is provided to permit specification of standard options to be used.

The output produced by VX/Cpp is a printed report (on stderr) of what was found in the source file under the direction of the configuration file and switch settings. A cross-reference database file is also updated with the same information in tab-separated format that is useful for automatic processing. When a feature action code indicates that the code be changed, VX/Cpp produces a sed script (automatic edit script) of the changes to be applied.


VX/Cpp Operation

VX/Cpp is a utility for converting OpenVMS VMS C source code to ANSI C source code. Its function is to parse a C program source module in much the same manner as a C compiler. To wit, VX/Cpp accepts a command line and an environment that is very similar to the standard "cc" C compiler command for Linux/UNIX systems. #include statements within the C source code are processed in the same manner as the C preprocessor-compiler combination.

The following sections describe the operation of VX/Cpp and the output it produces.

A command line for VX/Cpp has the format:

vxcpp [ switch_list ] file_name [ , file_name_list ]

switch_list is a list of switch names , separated by spaces and preceded by a "-" (minus sign). switch_list may be null. Valid switch names may be either C compiler switches or VX/Cpp switches. The switches control various optional functions of the program. Switch settings supersede settings in the configuration file.

VX/Cpp switches have the following format:

-X function switch_name

where function is one of:

function Meaning
f Invoke the feature code given by switch_name at the fix level.
d Invoke the feature code given by switch_name at the display level.
i ignore the feature code given by switch_name.
o Set the option code given by switch_name.

VX/Cpp switch function codes

Some examples of VX/Cpp command lines using VX/Cpp switches:

vxcpp -Xf 01.01 atest_file.c {sets feature 01.01 to "fix"}
vxcpp -Xo include_case upper btest.c {if feature 05.04 is "fix", change name to all upper case}


VX/Cpp feature codes

Feature Meaning
01.01 Address of constant (a number)
01.02 Address of string
02.01 Initializing structure members to run-time values
03.01 Variant struct/variant union usage
04.01 Assigning unions to unions
05.01 #includes from a text library without quotes or angles
05.02 #includes using a logical name
05.03 #includes using VMS directory specification
05.04 #includes of files in multiple case/all caps
05.05 #includes missing .h extension
05.06 #includes of VMS-specific libraries for items available under Linux/UNIX. (IE., UNIXlib.h) should be #ifdef (VMS) around
05.07 use of .hxx instead of .h for system includes for C should be #ifdef (VMS) around
05.08 missing .h files (ones that might "automatically" be included on VMS might not be under a flavor of UNIX)
06.01 missing arguments in function calls
07.01 #dictionary
07.02 #module
07.03 #pragma (esp, standard, nonstandard)
07.04 using extern modifiers (noshare, etc.) variable declarations
08.01 size of arguments - Endian Issues
08.02 type mismatches
08.03 using a long as a 32-bit integer
08.04 using longs when an address expression should be used
08.05 Storage class mismatches
09.01 inconsistent case in function names or other identifiers (external variables, etc.)
10.01 function calls not supported by standard "C" - va_count
10.02 use of vendor-specific compiler calls (vax$*, decc$*, etc.) vaxc$errno
10.03 use of additional fopen parameters
10.04 incompatible use of POSIX-defined types (stderr, etc.)
10.05 Inconsistent declarations
10.06 Hard-wired VMS file specifications
11.01 use of globalref
11.02 use of globaldef
11.03 use of globalvalue
11.04 use of symbolref
11.05 use of symboldef
12.01 #define using non-all uppercase characters
12.02 /* within comment block (style issue only)
12.03 #define names containing "$"
12.04 function names containing "$"
13.01 use of _align storage class
13.02 structure packing
14.01 pthreads - default attributes aren't the same
15.01 variable being used before set
16.01 undefined return type (depending on compiler default)
16.02 mismatched return types
17.01 external routines not being declared or prototyped
18.01 $crempsc specifying destination address and not using the supplied return address (i.e., requiring that return address = asking address)
19.01 Typecasting on left of assignment



Feature code applied option code option code value  
05.04 include_case upper make name upper case
  include_case lower make name lower case
  include_case ignore ignore case of name
05.02 include_logicals normal log_nam:xyz.h -> log_nam/xyz.h
  include_logicals remove log_nam:xyz.h -> xyz.h
05.01 include_ends quote name -> "name.h"
  include_ends angle name -> <name.h>
05.06 ignore_header file name Enclose header with #ifdef VMS
07.03 ignore_pragma pragma string Enclose pragma with #ifdef VMS
VX/Cpp Controls change_file file name produce formatted list of changes
  option_letter single letter change command line option letter (default is X)


Compiler Switches

The following are the standard C compiler switches that are accepted by VX/Cpp. Most of the switches are simply accepted without affecting the program at all. The significant exception to this is the "-I" switch that specifies #include search path names and most of the warning (W) flags. Since VX/Cpp must parse the #include files, all pathnames must be specified.

  • -I
  • -include
  • -imacros
  • -iprefix
  • -ifoutput
  • -isystem
  • -iwithprefix
  • -o
  • -pedantic
  • -pedantic-errors
  • -pcp
  • -traditional
  • -trigraphs
  • -W[no-]trigraphs
  • -W[no-]comment
  • -W[no-]traditional
  • -W[no-]import
  • -W[no-]error
  • -Wall
  • -W[no-]implicit
  • -W[no-]write-strings
  • -W[no-]cast-qual
  • -W[no-]bad-function-cast
  • -W[no-]pointer-arith
  • -W[no-]strict-prototypes
  • -W[no-]missing-prototypes
  • -W[no-]missing-declarations
  • -W[no-]redundant-declarations
  • -W[no-]nested-externs
  • -W[no-]format
  • -W[no-]char-subscripts
  • -W[no-]conversion
  • -W[no-]parentheses
  • -W[no-]return-type
  • -W[no-]missing-braces
  • -M
  • -MM
  • -MD
  • -MMD
  • -d
  • -g
  • -v
  • -H
  • -D
  • -A
  • -U
  • -C
  • -E
  • -P
  • -$
  • -nostdinc
  • -u
  • -f<whole_series>

Configuration File

The configuration file is a method for setting installation-wide or project-wide features and options. The configuration file is named ".vxcpp" and is looked for in, first the current directory , and then the $HOME directory. The configuration file is a plain text file. Each line on the file has the format:

action_code <white space> tag <white space> [ params.] # comment or | comment
action_codes would be one or more of the following (separated by commas).

  • f fix this if you find it
  • i ignore, do not change this
  • d display only, no changes at all.

tag is either a feature code or an option code (see Table 1 and Table 2).
params are additional parameter information required for some option codes.
comments may be preceded with either a "#" or a "|". Parsing of the configuration file line terminates with either comment symbol.

A typical configuration file is included in Appendix B.


There are three forms of output from VX/Cpp: a report printed on stderr , a database file of all features "fixed" or "displayed" and one or more sed scripts for installing the changes found by VX/Cpp.

The printed report shows all actions taken by VX/Cpp and all non POSIX language constructs found. The format of an output line is a typical compiler error report. A sample of a report follows. The file name begins a line, followed by the line number being reported. What follows is a comment on what was changed or what was detected. The comments are self-explanatory.
testx1.c:7: display 08.04 integer used as pointer testx1.c:17: display 08.02 Multiple character constant testx1.c:26: fix 16.02 Mismatched return type testx1.c:1: replace void with int testx1.c:1: fix 16.02 Mismatched return type testx1.c:32: display 02.01 Initialize to run-time values testx1.c:45: display 19.01 Typecasting on left side of assignment
testx1.c:51: display 04.01 Assign union to union
testx1.c:58: fix 16.01 Undefined return type
testx1.c:57: fix 16.01 Undefined return type
testx1.c:57: replace atest with int atest
testx1.c:58: warning: no previous prototype for `atest'
testx1.c:59: display 17.01 External function undeclared/unprototyped
testx1.c: In function `atest':
testx1.c:60: warning: `return' with no value, in function returning non-void
Database File

The database file is selected with the change_file option in the configuration file. Each record in the file is a tab-separated list of the data items file name, feature code and action code. Since it is a tab-separated file, several UNIX utilities may be used to manipulate the file.

sed Script(s)

For the feature codes that are set to fix ( f ), the changes to the source file are captured in a sed script file. The name of the sed script file is the same as the corresponding source file with ".sed" appended. In other words, if VX/Cpp is run against a source file named "sc_special_source.c" and that source #includes a file named "data_pattern.h", then two sed script files may be produced (depending on whether or not changes were detected). One file would be named "sc_special_source.c.sed" and the other would be named "data_pattern.h.sed". Those files will appear in the same directory as the corresponding original file. To apply the changes produced in the sed script , the sed utility must be run with the following command line:

sed -f < sed_script_file > source_file
For the examples used above, the command lines are:
sed -f sc_special_source.c.sed sc_special_source.c > new_sc_special_source.c and sed -f data_pattern.h.sed data_pattern.h > new_data_pattern.h.
Note that the output of sed must be re-directed in order to keep the changed source. The original input files are not changed. Since the sed script is an ordinary text file, it can be examined and modified using a conventional text editor.