VMS / OpenVMS C to ANSI C
Detects and remediates most VMS / OpenVMS Extensions
Detects RMS I/O in open/close/read/write and uses VX/RT replacement API's which interface to VX/RMS
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 is a utility for converting VMS / 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/Windows 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. |
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} |
| 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/Windows. (IE., Linuxlib.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 Linux) |
| 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) |
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.
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).
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.
Output
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.
Text
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 Linux 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: