Compaq C V6.4 for OpenVMS VAX Release Notes
7.4 New Features in DEC C V5.7
This release contains a number of new features aimed primarily at ease
of use and programmer productivity.
- Enhanced diagnostic message controls. The
command line qualifier and its matching
have had a number of new features added in an upwardly-compatible way.
Refer to the online help for
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,
- /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
. 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
. This qualifier is similar to the new qualifier
, except that unreferenced symbols declared in header files are omitted.
- New command line qualifier
, or equivalently
. This qualifier adds a list of line numbers at which each listed
symbol is referenced (if a listing is requested). If the
qualifier is omitted, this qualifier causes the
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.
Member selection (no indirection).
Subscripted (i.e. using  syntax).
Invoked as a builtin function.
- New command line qualifier
. This qualifier tells the compiler to accept (or reject) particular
language features, regardless of the setting of the
qualifier. There are two features that can be controlled in this way:
. 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.
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.
. Specifying this feature tells the compiler to recognize and process
the C9X keyword
as a type qualifier keyword. By default, in current language modes only
the reserved-namespace spelling
is treated as a keyword.
- New command line qualifier
. 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
- New command line qualifier
. This qualifier is only useful in conjunction with
, and when the default directory specification of
is not acceptable. When the compiler shortens a name under the
option, it also writes a mapping from the shortened name to the
original full-length name in the repository. The
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
unless a different directory is explicitly specified. See the help for
. 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++
7.5 New Features in DEC C V5.6
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.
7.6 New Features in DEC C V5.5
This is primarily a maintenance release focused on bug fixes, with very
limited new functionality.
- New type qualifier "
The ongoing work to revise the ANSI C language standard will
likely incorporate a new type qualifier keyword "
" (the existing ANSI type qualifiers are "
" and "
"). 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.
7.7 New Features in DEC C V5.3
- New qualifier keyword value /STANDARD=MS.
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
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:
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 */
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.
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
mechanism, and not through the
command line qualifier.
- New compiler-generated psect $ADDRESS_DATA
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.
7.8 Changes to #include processing in DEC C V5.3
To support processing of "prologue" and "epilogue"
file inclusion, the V5.2 compiler introduced substantial changes to the
processing of the
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
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
online help for the
$ help cc/decc/include
- New qualifer option,
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
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,
refer to a different file than
. 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",
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
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
- Kit changes for text library packaging of system headers
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
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
syntax. But by default, the logical name is undefined and the compiler
will search the default text libraries to find such headers.
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):
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:
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
remains a VAX-only restriction that the total number of text libraries
searched, including user-specified libraries using the
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
If no errors are caused by missing include files, you can disable
this warning with the
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
directives for system headers in user source code have the standard
syntax rather than the Digital-specific module-name syntax. If
reference copies of headers were extracted at installation time, you
can specify the installed
subdirectories in a search list logical used in a
qualifier or in the
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
. The compiler searches the
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
- 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.
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
- CXX$LIBRARY_INCLUDE defined using DECC$LIBRARY_INCLUDE
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:
- CXX$LIBRARY_INCLUDE defined without DECC$LIBRARY_INCLUDE
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.