HP OpenVMS Systems

This release contains a number of new features aimed primarily at ease of use and programmer productivity.

• Enhanced diagnostic message controls. The /WARNINGS command line qualifier and its matching #pragma message have had a number of new features added in an upwardly-compatible way. Refer to the online help for /WARNINGS for specific usage information. Features include:
  • Specify whether a message is issued only once per compilation, or at each occurrence.
  • Reduce the severity of any message that has a default severity of informational or warning, or increase the severity of any message. Reducing a warning to an informational can allow generation of a "warning-free object module", without suppressing the diagnostic altogether. Increasing the severity of an informational or warning to an error can help enforce programming practices by causing specific diagnostics to "break" a build.
  • Control optional messages using a single numeric "importance level". The "check" group of messages basically allowed enabling a large number of additional messages, some useful, some not very useful in many cases. Messages have now been grouped into 5 importance levels, named level1-level6. The default is level3. The "check" group is now treated as a synonym for level5. The "all" group is treated as a synonym for level6. The level1 and level2 groups correspond to "quiet" and slightly more "noisy" versions of Digital UNIX compilers, respectively. Enabling a level enables optional messages at that level and all lower levels. Disabling a level disables optional messages at that level and all higher levels.
  • Control optional messages using functional groups. The previous functional groups (c_to_cxx, check, portable, all) have been retained, and a number of new groups have been added. Many of the names for the new functional groups correspond to groups recognized by the "lint" utility on DIGITAL UNIX: ALIGNMENT, DEFUNCT, NOANSI, OBSOLESCENT, OVERFLOW, PERFORMANCE, PREPROCESSOR, QUESTCODE, RETURNCHECKS, UNINIT, UNUSED, CDD.
  • /WARNINGS=VERBOSE adds explanatory help text following each diagnostic message output.
  
  Besides the new features, the entire set of compiler messages was reviewed and updated. As a result, the exact set of messages reported by a default compilation is somehwat different. Overall, the default level3 setting is slightly quieter, particularly because the default mode of relaxed_ansi does not report uses of language extensions. Also, the severity of many warning messages has been reduced to informational. Finally, the Messages subtopic for CC now contains useful additional information about each message.
• New command line qualifier /SHOW=SYMBOLS . This will add a symbol table map to the listing (if a listing is requested). This is similar, but not identical, to the output from the VAX C compiler.
• New command line qualifier /SHOW=BRIEF . This qualifier is similar to the new qualifier /SHOW=SYMBOLS , except that unreferenced symbols declared in header files are omitted.
• New command line qualifier /CROSS_REFERENCE , or equivalently /SHOW=CROSS_REFERENCE . This qualifier adds a list of line numbers at which each listed symbol is referenced (if a listing is requested). If the /SHOW qualifier is omitted, this qualifier causes the /SHOW=BRIEF symbols to be listed. When appropriate, the line number designating a reference to a symbol is annotated with a suffix indicating the way in which the symbol was used on that line, as follows:
  • = Assigned or initialized.
  • & Address taken.
  • () Function called.
  • * Simple dereference.
  • -> Member dereference.
  • . Member selection (no indirection).
  • [] Subscripted (i.e. using [] syntax).
  • b Invoked as a builtin function.
• New command line qualifier /ACCEPT=[NO]feature . This qualifier tells the compiler to accept (or reject) particular language features, regardless of the setting of the /STANDARD qualifier. There are two features that can be controlled in this way:
  • VAXC_KEYWORDS . Specifying this feature tells the compiler to recognize and process the following identifiers as keywords: _align, globaldef, globalref, globalvalue, noshare, readonly, variant_struct, variant_union. Specifying NOVAXC_KEYWORDS tells the compiler to treat these as ordinary identifiers. The default is to recognize these as keywords in all language modes other than strict ANSI and common modes.
  • RESTRICT_KEYWORD . Specifying this feature tells the compiler to recognize and process the C9X keyword restrict as a type qualifier keyword. By default, in current language modes only the reserved-namespace spelling __restrict is treated as a keyword.
• New command line qualifier /NAMES=SHORTENED . External symbol names longer than 31 characters are, by default, truncated to 31 characters by the compiler in order to conform to the linker limit, as they always have been. This new option instructs the compiler to shorten the name without losing all information about the characters that were removed. The shortened name contains a CRC encoding of the characters removed, similar to way that the C++ compiler treats its mangled names that very often exceeed 31 characters. This allows programs containing long external names that are not unique within the first 31 characters to be linked successfully. Naturally, if a program contains external names longer than 31 characters, all of its modules must be compiled with the same setting of this qualifier in order to link successfully. The default is /NAMES=TRUNCATED .
• New command line qualifier /REPOSITORY=dirspec . This qualifier is only useful in conjunction with /NAMES=SHORTENED , and when the default directory specification of [.CXX_REPOSITORY] is not acceptable. When the compiler shortens a name under the /NAMES=SHORTENED option, it also writes a mapping from the shortened name to the original full-length name in the repository. The CXXDEMANGLE utility, which now also ships with the C compiler, can be used to find the original name corresponding to a shortened name. That utility also assumes that the shortened name repository is located in [.CXX_REPOSITORY] unless a different directory is explicitly specified. See the help for CXXDEMANGLE . An option to perform compatible shortening on long names with extern "C" linkage is planned for a future release of C++. Note that a shortened C name is formed using a convention that will never match a C++ "mangled" name, so a single repository can be shared by C and C++ compilations.

This is primarily a maintenance release focused on bug fixes, usability and message improvements, and providing V7.1 runtime library features on prior versions of VMS. Please see the file SYS$LIBRARY:DECC$CRTL.README for specific information on building applications that need to use new DEC C runtime library features on older versions of OpenVMS.

• Message group C_TO_CXX. This message group contains an optional set of diagnostics that report the use of a number of C language constructs that are not compatible with, or have a slightly different meaning in, the C++ language. This group may be enabled explicitly either on the command line (/WARN=ENABLE=C_TO_CXX) or by #pragma message enable (c_to_cxx).
  
• New diagnostics to detect simple expressions with side effects that are undefined in ANSI C. The C standard formalized defacto rules about side effects in terms of sequence points. An expression that modifies the same object more than once, or that modifies an object and fetches its value for a purpose other than computing the modified value, has undefined behavior unless there is an intervening sequence point. The compiler now warns about such expressions (only for objects that are simple declared variables).
  
• Source listings now include statement level nesting. The annotation at the left margin of the source listing now includes the statement nesting level in effect at the end of that source line. The statement nesting level appears as a simple integer before the listing line number. The block of a function definition is level 1. Outside of function definitions, this field is blank.

This is primarily a maintenance release focused on bug fixes, with very limited new functionality.

• New type qualifier " __restrict "
  The ongoing work to revise the ANSI C language standard will likely incorporate a new type qualifier keyword " restrict " (the existing ANSI type qualifiers are " const " and " volatile "). This feature has been present in the Cray C compiler for some time and is also being adopted by other vendors. The type qualifier applies only to pointer types, and its basic purpose is to assert to the compiler that memory accesses made through a pointer declared with this type do not overlap with other memory accesses within the scope of that pointer, permitting additional optimization. The qualifier (with double leading underscores to avoid violating the ANSI89 namespace) is recognized and its correct compile-time usage is verified, but it does not trigger additional optimizations.
• Initial macros shown in listing file
  At the end of the listing file there is now a section containing a list of all macros in effect at the start of the compilation, along with their values. This includes both those predefined by the compiler (except for ANSI-mandated macros that cannot be undefined or redfined) and the result of applying all /DEFINE and /UNDEFINE qualifiers.

• New qualifier keyword value /STANDARD=MS.
  This qualifier enables language compatibility features to accept some of the language extensions present in 32-bit Microsoft C compilers, and causes the predefined macros "__MS" and "__DECC_MODE_MS" to become defined with a value of 1. It does not provide complete compatibility with a particular version of Microsoft's compiler, but a limited selection of relatively minor extensions that can ease porting of C code developed under Microsoft C. Examples include unnamed struct and unions (same syntax as unnamed unions in C++, similar function to variant struct and union in VAX C), and relaxation of pointer and integer comparisons. It does not include such major extensions as structured exception handling or thread local storage.
  
• New qualifier keyword value /ASSUME=[NO]HEADER_TYPE_DEFAULT
  The negated form of this value disables the compiler's supplying of a default filetype extension of ".H" for source files included by the #include preprocessing directive. This feature is primarily for compatibility with the C++ compiler, where the rules for ANSI C++ header file specifications conflict with the notion of having the compiler supply a filetype. The default is /ASSUME=HEADER_TYPE_DEFAULT, which enables the compiler to supply the filetype ".H" for included files as it always has. Also see Section 7.8 for more information on changes to #include processing.
  
• Attribute controls for psects using #pragma extern_model
  The extern_model pragma has been enhanced to allow explicit control over most psect attributes, not just shr/noshr. The syntax is:

  #pragma extern_model model_spec [attr[,attr]...] where model_spec is one of: common_block relaxed_refdef strict_refdef "name" strict_refdef /* No attr specifications allowed. */ globalvalue /* No attr specifications allowed. */ attr is chosen from (at most one from each line): gbl lcl /* Not allowed with relaxed_refdef */ shr noshr wrt nowrt pic nopic ovr con 2 long 3 quad 4 octa 9 page

  
  A description of these attributes may be found in table 4-4 of the DEC C User's Guide for OpenVMS Systems, and more complete information on each may be found in the OpenVMS Linker Utility Manual. The default attributes are: noshr, pic. For strict_refdef the default is con, and for common_block and relaxed_refdef the default is ovr. The default for wrt/nowrt is determined by the first variable placed in the psect. If the variable has the const type qualifier (or the readonly modifier) the psect will be set to nowrt, otherwise it is set to wrt.
  NOTE: These attributes are normally used by system programmers who need to perform declarations normally done in macro. Most of these attributes are not needed in normal C programs. Also note that the setting of attributes is supported only through the #pragma mechanism, and not through the /EXTERN_MODEL command line qualifier.
• New compiler-generated psect $ADDRESS_DATA
  By default, previous versions of the compiler have placed all static-extent const data in the psect named $CODE. When the const data involved link-time addresses, this caused the entire $CODE psect to become non-shared. In V5.3, static-extent const data initialized with link-time addresses is placed in a new psect named $ADDRESS_DATA, leaving $CODE sharable. For example, given the declarations:

  static const int a = 5; static const int * const b = &a;

  
  variable a will be placed in the $CODE psect because it is initialized to a true compile-time constant value, while variable b will be placed in $ADDRESS_DATA because it is initialized to the address of a, which may differ among different image activations.

To support processing of "prologue" and "epilogue" file inclusion, the V5.2 compiler introduced substantial changes to the processing of the #include directive that allowed for increased code commonality between the OpenVMS Alpha and VAX versions of the compiler. In V5.3, further changes have been made to make the actual #include searching behavior identical for the OpenVMS VAX and Alpha compilers, and to support new ANSI C++ requirements on header file naming conventions. The following are some of the highlights of these modifications. For a complete description of #include processing, see the discussion of file inclusion in the cc online help for the /include_directory qualifier ( $ help cc/decc/include ).

• New qualifer option, /assume=[no]header_type_default
  This option can disable the default file type mechanism for header files. Following VAX C, the DEC C compiler has traditionally supplied a default file type of ".H" for filenames specified without any file type extension in a #include directive using ANSI C syntax. Similarly, the DEC C++ compiler has supplied a default file type of ".HXX". However, the emerging ANSI standard for C++ now requires that, for example, #include <iostream> refer to a different file than #include <iostream.hxx> . V5.3 of both DEC C and DEC C++ support this capability through the /assume=noheader_type_default qualifier option. Under this option, both DEC C and DEC C++ supply a default file type of just "." for files named in standard-syntax #include directives. Thus, for example, if a header file directory contains two files named "STDIO." and "STDIO.H", the directive #include <stdio> will cause DEC C to select "STDIO.H" by default. But under /assume=noheader_type_default, "STDIO." will be selected. Besides matching the ANSI C++ requirement, this behavior is also more compatible with most other C compilers including UNIX and Windows/NT.
• Meaning of empty string in /INCLUDE_DIRECTORY
  The UNIX convention of using -I without a pathname to disable searching of the "standard places" is now fully supported by the /INCLUDE_DIRECTORY qualifier. If an empty string occurs as any element in the list of specifications supplied by this qualifier, the compiler does not search any of its default directories, logical names, or text libraries and uses only the specifications from the command line to find include files.
• Kit changes for text library packaging of system headers
  With this release, the DEC C kit for VAX has been changed to match the OpenVMS Alpha kit with respect to header file installation and searching. Previous releases have depended on the definition of a system logical name DECC$LIBRARY_INCLUDE to find plain text copies of all system header files. In V5.3, DEC C directly searches text libraries for the default runtime system header files just as the Alpha version of the compiler has always done. Previously, the VAX compiler was limited to searching a maximum of two default text libraries (DECC$TEXT_LIBRARY and DECC$RTLDEF.TLB) in addition to any specified by the user on the command line. This limitation has been removed, and as on Alpha the compiler may search several additional default text libraries (see the cc/decc online help for details).
  As on Alpha, the V5.3 DEC C installation procedure for VAX will create header file "REFERENCE" directories containing plain text copies of the header files packaged in the text libraries. This is as a user convenience for viewing and using the SEARCH command, and the compiler will not search these directories by default. Therefore, the system startup procedure for the compiler no longer defines the system logical name DECC$LIBRARY_INCLUDE, and the installation kit deassigns that logical name if it is already defined as a system logical during the installation.
  To maintain functional compatibility with previous releases, however, the V5.3 compiler will still check for a definition of the logical name DECC$LIBRARY_INCLUDE, and if it is defined then the compiler will use it to search for plain text copies of header files, and it will avoid searching the default text libraries for headers included with the quote or angle-bracket #include syntax. But by default, the logical name is undefined and the compiler will search the default text libraries to find such headers.
  The V5.3 kit installation normally extracts reference copies of the headers as mentioned above. The modules from each separate text library file are extracted to a separate directory as shown in the following list - the last component of each directory name matches the file name of the .TLB library file whose modules it contains, and the default filetype for files in each directory is as shown (unless /assume=noheader_type_default is in effect):

  SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF].H SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C].H NOTE: OpenVMS VAX through version V7.0 does not supply a SYS$STARLET_C.TLB as OpenVMS Alpha has always done. The starlet headers are constructed by the compiler kit and placed in the SYS$STARLET_C directory as well as in DECC$RTLDEF.TLB and its directory. A future version of OpenVMS VAX is expected to ship SYS$STARLET_C.TLB as on Alpha.

  
  Although the Alpha compiler normally finds system headers in the default text libraries, in the absence of a definition for the logical names DECC$LIBRARY_INCLUDE or DECC$SYSTEM_INCLUDE it first searches directories with names the same as the reference directories shown above, but with "REFERENCE" changed to "INCLUDE". Normally, no such directories exist on Alpha and so the modules are found in the default text libraries - but if they do exist the files in them will supercede modules of the same name in the default text libraries. Previous versions of the VAX compiler have behaved in a similar way except that they expected a single "flat" structure for include files:

  SYS$COMMON:[DECC$LIB.INCLUDE].H

  
  In previous versions of the VAX compiler, these directories were required to be fully populated since the compiler was unable to search all of the default text libraries anticipated. The V5.3 compiler can search all of the default text libraries, so these directories do not need to exist. Therefore, the V5.3 kit installation looks for a preexisting SYS$COMMON:[DECC$LIB]INCLUDE.DIR, and renames it to OLD_INCLUDE.DIR. It does not create and populate new [DECC$LIB.INCLUDE.*] directories. But to match the Alpha compiler's behavior, the V5.3 VAX compiler does search these directories if they exist and neither DECC$LIBRARY_INCLUDE nor DECC$SYSTEM_INCLUDE are defined as logical names, so any files in them will supercede modules of the same name in the default text libraries just as on Alpha.
  
• Restriction on total number of text libraries searched
  There remains a VAX-only restriction that the total number of text libraries searched, including user-specified libraries using the /LIBRARY qualifier, cannot exceed 16. If the limit of 16 total text libraries is exceeded in a compilation, the following warning message occurs:

  %CC-W-TOOMANYTXTLIB, Too many text libraries. Library 17th-library-name and subsequent will not be searched.

  
  If no errors are caused by missing include files, you can disable this warning with the /warn=disable=TOOMANYTXTLIB qualifier.
  If errors are caused by missing system header files and 17th-library-name is DECC$TEXT_LIBRARY or one of the compiler default text libraries from SYS$LIBRARY, then the solution is to reduce the number of user-specified command-line libraries. An alternative is for the compiler to get system headers from ordinary files in directories. This requires that the #include directives for system headers in user source code have the standard #include syntax rather than the Digital-specific module-name syntax. If reference copies of headers were extracted at installation time, you can specify the installed [.REFERENCE.*] subdirectories in a search list logical used in a /include qualifier or in the DECC$SYSTEM_INCLUDE logical as appropriate.
  If several users on a system encounter the problem of missing system header files because they use too many text libraries, then the system manager may want to install the reference copies of system headers and then rename (or copy) the [.REFERENCE.*] subdirectories to [.INCLUDE.*] . The compiler searches the [.INCLUDE.*] directories by default, so it would not then be necessary for individual users to modify build procedures to look for plain text copies. It would still, however, be necessary to suppress the TOOMANYTXTLIB warning message.
  
• Interaction with older versions of DEC C++
  The DEC C and DEC C++ compilers both ship copies of the DEC C RTL header files and arrange for starlet header files to be constructed and made available during installation. The two compilers have traditionally accessed these headers from the same locations, so that upgrading one of the compilers would upgrade the CRTL and starlet headers accessed by the other compiler even if the other compiler was not upgraded. The V5.3 compilers continue in this fashion, but the interaction with the header files is more complex given the change in the way the new compilers find them. It is generally recommended that if you have both DEC C and DEC C++ installed, that you upgrade them to the same version at the same time, and especially so for upgrading to V5.3.
  Nevertheless, the V5.3 DEC C VAX kit attempts to upgrade the headers without damaging the operation of an earlier installed version of DEC C++. The kit checks for the existence and version of SYS$SYSTEM:CXX$COMPILER.EXE. If it exists and is earlier than V5.3, the kit generates a common compiler startup procedure to define a system logical CXX$LIBRARY_INCLUDE as follows:
  • CXX$LIBRARY_INCLUDE defined using DECC$LIBRARY_INCLUDE
    If the logical name CXX$LIBRARY_INCLUDE is currently defined as a system logical, and it contains the logical name DECC$LIBRARY_INCLUDE as an element in its translation, then the new definition will match the old except that the dependence on DECC$LIBRARY_INCLUDE is removed, and that element of the translation is replaced by the following three elements:

    SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF], SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C], SYS$LIBRARY

  • CXX$LIBRARY_INCLUDE defined without DECC$LIBRARY_INCLUDE
    If the logical name CXX$LIBRARY_INCLUDE is defined as a system logical, but its translation does not contain DECC$LIBRARY_INCLUDE as an element, then the startup procedure will define it as it is currently defined.
  • CXX$LIBRARY_INCLUDE not defined
    If the logical name CXX$LIBRARY_INCLUDE is not currently defined as a system logical, then the startup procedure will not define it.
  
  The first case is the usual case, and it will cause the older DEC C++ compiler to search the new REFERENCE copies of the C headers provided by the C installation. While the V5.3 compilers themselves never implicitly search the REFERENCE copies of header files, a V5.3 installation may cause an older compiler to search the REFERENCE copies. So if you are upgrading DEC C to V5.3 and are not planning to upgrade DEC C++ right away, then you should accept the default of installing reference copies - otherwise the C++ compiler will be unable to find the updated headers and you will need to define CXX$LIBRARY_INCLUDE (manually) to access the old header files. The installation displays the current definitions for all DECC$ and CXX$ logical names before making any changes. Note that the old headers may have been renamed to [.OLD_INCLUDE], depending on whether or not they were previously installed in the default location. The V5.3 kits do not directly support installation of the REFERENCE headers in other than the default location.
  Note that when the DEC C++ compiler is upgraded to V5.3, it will deassign the system logical CXX$LIBRARY_INCLUDE and generate a startup procedure without a definition for it. With both C and C++ compilers at V5.3, the REFERENCE copies are for human convenience only.
  Under no circumstances does the V5.3 C kit define the logical name DECC$LIBRARY_INCLUDE. However, the V5.3 DEC C++ kit may define this logical name if its installation kit detects a version of DEC C older than V5.3. Thus, the compilers may be upgraded in either order. But upgrading only one of the compilers will leave the older compiler searching for system header files in the new REFERENCE directories which are intended only for programmer convenience from V5.3 onward.