____________________________________________________ DEC C V5.5 for OpenVMS Alpha Release Notes October 23, 1996 _________________________________________________________________ Contents 1 News for Application Developers.................. 1 2 Introduction..................................... 2 3 Installation Notes............................... 2 3.1 Installation Requirements ..................... 2 3.2 Header Files .................................. 3 3.3 Startup Procedure ............................. 3 4 Targeting to Pre-6.1 Systems..................... 4 5 Migrating from VAX C to DEC C.................... 6 6 Enhancements and bug fixes....................... 7 6.1 Enhancements in V5.5 .......................... 7 6.2 Enhancements in V5.3 .......................... 9 6.3 Changes to #include processing in V5.3 ........ 12 6.4 Enhancements in V5.2 .......................... 13 6.5 Changes in DEC C RTL Header Files for V5.2 of DEC C/C++...................................... 21 6.6 Enhancements in V5.0 .......................... 27 6.7 Enhancements since V1.3A ...................... 43 6.8 Problems fixed since V5.3 ..................... 47 6.9 Problems fixed since V5.2 ..................... 52 6.10 Problems fixed since V5.0 ..................... 57 6.11 Problems fixed since V4.1 ..................... 62 6.12 Problems fixed since V4.0 ..................... 65 6.13 Problems fixed since V1.3A .................... 68 7 Support for STDARG.H and VARARGS.H............... 70 8 Debugger support................................. 70 9 64 bit support................................... 71 10 Restrictions and known bugs...................... 73 iii Tables 1 New DEC C V5.2 Header Files ................... 21 iv 1 News for Application Developers Digital has received many requests to provide information that helps software application developers build client/server applications for the OpenVMS and Windows NT environment. To assist you in building complex client/server applications, Digital's new Application Developer's Package provides a model and a process for client/server application development across Windows NT and OpenVMS for C/C++ programmers. This package provides essential information about how to create 3-tier client/server applications that run across PCs, Windows NT, and OpenVMS. It includes documentation and working sample applications to describe and demonstrate 3-tier client/server application development. This product consists of the following components: o The Application Developer's Package User's Guide o The sample application source code. This application demonstrates the tools and middleware that you can use to develop 3-tier client/server applications on Windows NT and OpenVMS Alpha systems o A white paper entitled "Things to Consider When Moving to a Client/Server environment" The Application Developer's Package is being distributed through the following channels: o On the Software Products Library o On the World Wide Web at the following URL: http://www.openvms.digital.com/openvms/products/appdevpkg/ The Application Developer's Package User's Guide and sample application do not require the purchase of a separate license to install or use. The terms and conditions for the use of this product are displayed at the beginning of the installation procedure. 1 2 Introduction This document contains the release notes for DEC C V5.5 for OpenVMS Alpha. DEC C V5.5 contains support for: o New command line qualifier o New type qualifier o New listing file information o Bug fixes For additional information on the compiler, see also: o The DEC C User's Guide for OpenVMS systems o Enter the command HELP CC For additional information about the DEC C language and its supported library routines, see also: o The DEC C Language Reference Manual o The DEC C Run-Time Library Reference Manual for OpenVMS Systems The release notes for the DEC C Run Time Library are contained in the Run Time Components for OpenVMS Alpha. 3 Installation Notes 3.1 Installation Requirements DEC C V5.5 requires OpenVMS Alpha V6.1. Following are disk space requirements for installation of DEC C for OpenVMS Alpha, Block Cluster Size=1: Disk space required for 34,000 blocks installation: Disk space required for 22,000 blocks use (permanent): 2 The formula for determining the contiguous free page requirements for installation of DEC C for OpenVMS Alpha is given by P = 5000 + size of DCLTABLES.EXE For more information about installing the kit, refer to the DEC C Installation Guide accompanying these release notes. 3.2 Header Files The installation kit will replace the DECC$RTLDEF.TLB in SYS$LIBRARY unless it finds that the creation date of the file on this kit is earlier than the creation date of the existing file on your system. Whenever DECC$RTLDEF.TLB is replaced, the kit will also place reference copies of the *.H forms of the headers in o SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF] o SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C] The compiler does not normally search these reference areas, instead it searches for and reads these headers directly from the text library files SYS$LIBRARY:DECC$RTLDEF.TLB and SYS$LIBRARY:SYS$STARLET_ C.TLB. The *.H form of the headers are provided as a convenience to users for reference purposes such as searching and browsing, which are not directly supported for text libraries. 3.3 Startup Procedure DEC C for OpenVMS Alpha provides an optional startup procedure, SYS$STARTUP:DECC$STARTUP.COM . This procedure may be invoked by the system startup procedure to perform an install on the compiler and its associated message file to improve compiler performance. 3 4 Targeting to Pre-6.1 Systems Prior to V4.0, DEC C used the same 64 bit machine data type for the C types "double" and "long double." Now, DEC C by default uses a 128 bit machine data type for the C type "long double." This behavior is controlled by the /L_DOUBLE_SIZE command line qualifier. /L_DOUBLE_ SIZE=64 causes the compiler to use the same 64 bit floating point representation for double and long double. /L_ DOUBLE_SIZE=128 causes the compiler to use a 128 bit representation for long double. In order to support this new 128 bit floating point data type, any function in the DEC C RTL that supports the long double data type now has two versions. The old version which processes 64 bit long doubles and the new version that processes 128 bit long doubles. By default, the compiler automatically adds a prefix to the name of any DEC C RTL function called in order to cause the right version of the function to be called (see /PREFIX_LIBRARY_ENTRIES in the help file or User Guide for more information on automatic prefixing). The 128 bit long double support can raise compatibility issues for users of third party libraries or providers of third party software. Users of libraries are affected if the interface to the library uses long double. Long double is part of the library interface if the user program and the library interchange long double data. This might happen by passing long double arguments, function returning long double values, long double external variables used by both the user program and the library, or the user program accessing long double data in the library through a pointer, or the library accessing long double data in the user program through a pointer. Long double is not part of the interface if no long double data is ever exchanged; for example, if the program does not use long double, or if any use of long double by the library or user program is completely internal to the library or user program. 4 If long double is part of the interface, the user program and the library have to agree about the machine data type used for long double. For libraries that have not been updated to use 128 bit floating point, user programs should be compiled with /L_DOUBLE_SIZE=64. Providers of third party libraries are affected if long double is part of the library interface in that users of the library must be compiled with the same setting of the /L_DOUBLE_SIZE as the library itself. Providers of libraries may wish to consider providing two version of their library: one compatible with /L_DOUBLE_SIZE=64 and one compatible with /L_DOUBLE_SIZE=128. Alternatively, one library could be provided with different entry points for each routine whose interface uses long double. Note that using /L_DOUBLE_SIZE=128 requires OpenVMS Alpha V6.1 or later in order to have the DEC C RTL that supports 128 bit long doubles. Code compiled with /L_DOUBLE_SIZE=64 and that uses no new features of the DEC C RTL or compiler is compatible with older versions of the operating system. Providers of software to run on versions of OpenVMS Alpha earlier than V6.1 need to compile with /L_DOUBLE_SIZE=64 even if the software does not use floating point at all. The reason is that printf and scanf can write and read long doubles, and by default the compiler causes versions of printf and scanf only in the new DEC C RTL to be used. By compiling with /L_DOUBLE_SIZE=64, old entry points in the DEC C RTL are used that exist in earlier versions of the DEC C RTL. Providers of software to run on versions of OpenVMS Alpha earlier than V6.1 need also be aware that new DEC C support for IEEE is restricted to 6.1 systems as well. Generation and handling of exceptional values via /IEEE_MODE and rounding (via /ROUNDING_MODE) should not be specified if running on systems earlier than 6.1 . 5 5 Migrating from VAX C to DEC C If you are migrating from VAX C to DEC C, you might find the following publication useful: DEC C Migration Guide for OpenVMS VAX Systems (Order number: AA-Q5AVA-TE) This guide is included with the DEC C for OpenVMS VAX product, to which it primarily applies. However, the following sections of this guide might also prove helpful if you are porting VAX C code to DEC C on an Alpha system: o The following sections in Chapter 1-Migrating to the DEC C Run-Time Library: - Potential Migration Concerns and Solutions - Behavior Differences Between the VAX C RTL and DEC C RTL - DEC C RTL Obsolete Features - Debugging and the DEC C RTL Object Library - Some subsections of C RTL Interoperability Concerns o All of Chapter 2-Migrating to the DEC C Compiler For more information on Linking to the DEC C RTL on OpenVMS Alpha systems, see the section RTL Linking Options on Alpha Systems in Chapter 1 of the DEC C Run-Time Library Reference Manual included in your product documentation. For more information on features helpful in migrating to DEC C, see the DEC C User's Guide included in your product documentation. Such features include: o Command-line qualifiers: /STANDARD /WARNINGS /EXTERN_MODEL /[NO]SHARE_GLOBALS o Preprocessor directives: #pragma message #pragma extern_model 6 The DEC C User's guide also contains a VAX C to DEC C Differences appendix that you might find useful. This appendix summarizes the features that distinguish DEC C for OpenVMS Systems from VAX C Version 3.2. You might also want to read the Common Pitfalls appendix of the user's guide. Note that while the /STANDARD=VAXC qualifier enables a number of language features and behaviors that aid in building programs developed with the VAX C compiler, it is sometimes the case that differences between the two compiler implementations can produce unexpected behavior differences in the compiled program. Also note that the /STANDARD=VAXC qualifier only affects the language dialect the compiler accepts. The DEC C compiler has separate qualifiers that control other environmental characteristics (e.g. /extern_model, /share_globals, and /nested_include) that may affect the ease of building a VAX C code base with DEC C. 6 Enhancements and bug fixes 6.1 Enhancements in V5.5 This is primarily a maintenance release focused on bug fixes, with very limited new functionality. o New command line qualifier /ASSUME=NOPOINTERS_TO_ GLOBALS. This qualifier tells the compiler it is safe to assume that global variables have not had their addresses taken in a separate compilation. By default, the compiler assumes that global variables may have had their addresses taken in separately compiled modules, and that in general any pointer dereference may be accessing the same memory as any global variable. This is often a significant barrier to optimization. The /ANSI_ALIAS command line qualifier allows some resolution based on data type, but this new qualifier provides significant additional resolution and improved optimization in many cases. Note that this qualifier does not tell 7 the compiler that the compilation never uses pointers to access global variables (which is seldom true of real C programs). Instead, it tells the compiler that any global variable accessed through a pointer in the compilation must have had its address taken within that compilation. In combination with /plus_list_ optimize, several source modules can be treated as a single compilation for the purpose of this analysis. Since runtime libraries such as the CRTL do not take the addresses of global variables defined in user programs, it is often possible to combine source modules into a single compilation that allows this qualifier to be used effectively. o 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. In this release, 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 yet trigger additional optimizations. o 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. 8 6.2 Enhancements in V5.3 o 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 (such as the C compiler packaged with Visual C++) 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. o New qualifier keyword value /ASSUME=[NO]HEADER_TYPE_ DEFAULT The negated form of this value disables the compiler's supplying of a default file type 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 file type. The default is /ASSUME=HEADER_TYPE_DEFAULT, which enables the compiler to supply the file type ".H" for included files as it always has. Also see Section 6.3 for more information on changes to #include processing. o 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: 9 #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 /* Not meaningful for Alpha */ ovr con rel abs exe noexe vec novec 0 byte 1 word 2 long 3 quad 4 octa 16 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, rel, noexe, novec, nopic. 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. Restrictions on setting attributes: #pragma extern_model will not set psect attributes for variables declared as tenative definitions in the relaxed_refdef model. A tentative definition is one which does not contain an initializer. For example, consider the code: #pragma extern_model relaxed_refdef long int a; int b = 6; #pragma extern_model common_block long int c; 10 Psect A will be given octaword alignment (the default) because a is a tentative definition. Psect B will correctly be given longword alignment because it is initialized and therefore not a tentative definition. Psect C will also have longword alignment because it is declared in an extern_model other than relaxed_refdef. Also, alignment of word and byte may not currently be specified for any extern model. 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. o New compiler-generated psect $READONLY_ADDR$ By default, previous versions of the compiler have placed all static-extent const data in the psect named $READONLY$. When the const data involved link- time addresses, this caused the entire $READONLY$ to become non-shared. In V5.3, static-extent const data initialized with link-time addresses is placed in a new psect named $READONLY_ADDR$, leaving $READONLY$ sharable. For example, given the declarations: static const int a = 5; static const int * const b = &a; variable a will be placed in the $READONLY$ psect because it is initialized to a true compile-time constant value, while variable b will be placed in $READONLY_ADDR$ because it is initialized to the address of a, which may differ among different image activations. 11 6.3 Changes to #include processing in V5.3 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/include). o 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 refer to a different file than #include . 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 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. o 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 12 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. o ALPHA$LIBRARY system logical DEC C now accesses default header files and libraries using the system logical SYS$LIBRARY rather than ALPHA$LIBRARY. On an OpenVMS Alpha system, the logical name ALPHA$LIBRARY is defined identically to SYS$LIBRARY. The use of ALPHA$LIBRARY originated with internal cross-development environments that are no longer supported. If you have deliberately supplied a different definition of ALPHA$LIBRARY for any reason, you will need to redefine SYS$LIBRARY instead in order to produce the same effect on the compiler. 6.4 Enhancements in V5.2 o The command line qualifier /STANDARD=ISOC94 has been added. This qualifier enables digraph processing and pre- defines the macro __STDC_VERSION__ to the value 199409L. The macro __STDC_VERSION__ is used in certain header files to enable the declaration of additional wide character functions as specified in Amendment 1 to ISO/ANSI C. (Amendment 1, which specifies digraphs, alternate spellings for certain operators, and a number of new wide character functions, was officially adopted by ISO in November of 1994.) The meaning of /STANDARD with no keywords has been changed from /STANDARD=ANSI89 to /STANDARD=(ANSI89, ISOC94), i.e. strict conformance to the full new standard. The default mode of the compiler (/NOSTANDARD) is still RELAXED_ANSI89. The meaning of /STANDARD=ISOC94 is /STANDARD=(RELAXED_ANSI, ISOC94), i.e. requesting just the additional features from the amendment builds on the default mode. The ISOC94 keyword may be used with any of the other keywords to the /STANDARD qualifier except VAXC. 13 o DEC C V5.2 has 64-bit addressing support. This support is controlled by both the new command line qualifier /POINTER_SIZE, and by the new pragmas pointer_size and required_pointer_size. In addition, the DEC C RTL interfaces in the header files are conditionalized to provide 64-bit support only when the /POINTER_SIZE qualifier is used on the command line and when the the __VMS_VER pre-defined macro is greater than or equal to 70000000 (i.e. VMS 7.0). #pragma pointer_size ( operand ) where the operand can be: 32 (or short) 32-bit pointers 64 (or long) 64-bit pointers system_default 32-bit pointers (64 on Digital UNIX) save remember the current pointer size restore restore size to last remembered value #pragma required_pointer_size ( operand ) where the operand is the same as for pointer_size #pragma required_pointer_size and #pragma pointer_size have the same effect except that #pragma pointer_size is enabled ONLY when the command line switch /POINTER_ SIZE is used. When /POINTER_SIZE does not appear on the command line, the pragma is ignored. #pragma required_ pointer_size always takes effect regardless off whether /POINTER_SIZE has been specified. Please note that: 1. the pragmas only affect the meaning of the pointer- declarator ("*") in declarations, casts and the sizeof operator. 2. The size of a pointer is the property of the type, and so it is bound in a typedef declaration, but not in a preprocessor macro definition. 14 3. The size of the pointer produced by the "&" operator, or by an array name or function name in a context where it is converted to an explicit pointer, is 32 bits unless the "&" operator is applied to an object designated by a deref of a pointer whose type is a 64-bit pointer type. /[NO]POINTER_SIZE = {32 | 64 | long | short} This command line qualifier has the following effects: 1. Enable processing of #pragma pointer_size 2. Sets the initial default pointer size before the first pragma is seen 3. Predefines preprocessor macro __INITIAL_POINTER_SIZE to 32 or 64. In the absence of the /pointer_size qualifier, __INITIAL_POINTER_SIZE is 0, allowing "#ifdef __INITIAL_POINTER_SIZE" to be used as a macro to test whether of not the compiler supports 64-bit pointers. 4. For /pointer_size=64 (or long), the RTL name mapping table is changed to select the 64-bit versions of malloc, calloc, and realloc (and other routines sensitive to pointer size) by default. A given call may explicitly name the 32-bit version or 64-bit version of these routines, but calls that use the normal standard names will default to calling the 64-bit version when the command line selects 64-bit pointers initially. o /[NO]CHECK qualifier A new qualifier to control generation of code to perform runtime checking to help find for uninitialized variables and mixed pointer-size porblems. /[NO]CHECK=([NO]UNINITIALIZED_VARIABLES, [NO]POINTER_SIZE=(option,...)) 15 Valid values of option are: [NO]ASSIGNMENT [NO]CAST [NO]PARAMETER ALL NONE This qualifier causes the compiler to emit code which will assist in identifying potentially incorrect code. This is a debugging aid. When /CHECK=UNINITIALIZED_VARIABLES is specified the compiler will emit code which initializes all automatic variables the value 0xfffa5a5afffa5a5a. This value is a floating NaN so it will cause a floating point trap if used in IEEE mode. If used as a pointer, it will likely causes an ACCVIO. When /CHECK=POINTER_SIZE=(option,...) is specified the compiler will emit code to check 32-bit pointer values to ensure that the values will fit in a 32-bit pointer. If the value can not be represented by a 32-bit pointer, the runtime code will signal SS$_RANGEERR (range error). The option keywords which follow /POINTER_SIZE determine exactly which checks should be generated: [NO]ASSIGNMENT - Emit a check whenever a 64-bit pointer is assigned to a 32-bit pointer (including use as an actual argument). [NO]CAST - Emit a check whenever a 64-bit pointer is cast to a 32-bit pointer. [NO]PARAMETER - Emit code that checks all formal parameters at function start-up to make sure that all formal parameters which are declared to be 32-bit pointers have 32-bit values. ALL - Emit all checks. NONE - Emit no checks. If /CHECK=POINTER_SIZE is specified, the defaults are ASSIGNMENT,PARAMETER. 16 If /CHECK is specified, it will be the same as /CHECK=(UNINITIALIZED_VARIABLES,POINTER_SIZE) which is the same as /CHECK=(UNINITIALIZED_VARIABLES, POINTER_SIZE=(ASSIGNMENT,PARAMETER)) IF /CHECK=pointer_size=ALL is specified, it's the same as /CHECK=(POINTER_SIZE=(ASSIGNMENT,PARAMETER,CAST)) The following contrived program contains a number of pointer assignments. The comment field after each line describes how to enable checking for each assignment. #pragma required_pointer_size long int *a; char *b; typedef char * l_char_ptr; #pragma required_pointer_size short char *c; int *d; foo(int * e) // Check e if PARAMETER { d = a; // Check a if ASSIGNMENT c = (char *) a; // Check a if CAST c = (char *) d; // No checking ever foo( a ); // Check a if ASSIGNMENT bar( a ); // No checking ever - no prototype b = (l_char_ptr) a; // No checking ever c = (l_char_ptr) a; // Check a if ASSIGNMENT b = (char *) a; // Check if CAST } o Implicit processing of prologue/epilogue files before and after each #include. When the compiler encounters a #include preprocessing directive, it first determines the location of the file or text library module to be included. It then checks to see if one or both of the two following specially named files or modules exist in the same location: __DECC_INCLUDE_PROLOGUE.H, __DECC_INCLUDE_EPILOGUE.H (in the case of a text library, the .H is stripped off). If they do, then the content of each is read into memory. The text of the prologue file (if it exists) 17 is processed JUST BEFORE the text of the file specified by the #include, and the text of the epilogue file (if it exists) is processed JUST AFTER the text of the file specified by the #include. Subsequent #includes that refer to files from the same location use the saved text from any prologue/epilogue file found there. The prologue/epilogue files are otherwise treated as if they had been #included explicitly, and #line directives are generated for them if /prepoc output is produced, and they appear as dependencies if /mms_dependency output is produced. The "location" is the VMS directory containing the #included file or the text library file containing the #included module. For this purpose, "directory" means the result of using the $PARSE/$SEARCH system services with concealed device name logicals translated. So if a #included file is found through a concealed device logical that hides a search list, the check for prologue /epilogue files is still specific to the individual directories making up the search list. The intended purpose of this feature is largely to aid in using header files that are 64-bit "unaware" within an application being built to exploit 64-bit addressing. Current header files typically contain a section at the top that uses pragmas to save the current state of things like member_alignment and extern_model and then set them to the default values for the system, and then at the end they restore the pragmas to their previously- saved state. Mixed pointer sizes introduce another kind of state that typically needs to be saved/set/restored in headers that define fixed 32-bit interfaces to libraries and data structures. DEC C V5.0 introduced #pragma environment to allow headers to control all of the compiler's state (message suppression, extern_ model, and member_alignment) with one directive. The environment pragma now includes pointer_size as part of the state it manipulates. But for header files that have not yet been upgraded to use #pragma environment, the /pointer_size=64 qualifier can be very difficult to use effectively. The automatic #include prologue/epilogue mechanism allows users to protect all of the header files within 18 a single directory (or modules within a single text library) just by copying two short files into each directory or library that needs it, without having to edit each header file or library module separately. Over time, headers should be modified either to exploit 64-bit addressing (like the DEC C RTL), or to protect themselves with #pragma environment. But to ease the transition (header files come from many different places), this mechanism can be very effective. A suggested content for those files is as follows: __DECC_INCLUDE_PROLOGUE.H: #ifdef __PRAGMA_ENVIRONMENT #pragma environment save #pragma environment header_defaults #else #error "__DECC_INCLUDE_PROLOGUE.H: \ This compiler does not support pragma environment" #endif __DECC_INCLUDE_EPILOGUE.H: #ifdef __PRAGMA_ENVIRONMENT #pragma __environment restore #else #error "__DECC_INCLUDE_EPILOGUE.H: \ This compiler does not support pragma environment" #endif o #pragma extern_prefix {SAVE | RESTORE | __save | __restore | "prefix_to_use"} This feature is for use by RTL header file developers only to prefix function entry points with "prefix_to_ use". Please note that the generated symbol name is all uppercase. The functionality should match that of the extern_prefix pragma in DEC C++ Note there is one known limitation with this feature: If the function is implicitly declared (ie, no prototype) then it does not get prefixed. o Atomic/Interlocked builtin functions 19 Several of the builtins provided in previous versions of the compiler had some troublesome usability limitations. E.g. the __xxx_ATOMIC_yyy family of builtins generate a memory barrier both before and after the atomic update sequence, they always return a status value even though the status is only useful for the variant forms that specify a retry count, and they do not provide a mechanism for determining the old value (the value that was in the location when the atomic update succeeded). Despite these problems, they have been found useful in certain circumstances. Instead of "improving" the previous builtins, they have all been retained as-is for compatibility, and a new set of builtins has been added to address the problems with the original set. For each builtin in the __xxx_ATOMIC_yyy family, DEC C V5.2 provides a new pair of builtins named __ATOMIC_xxx_yyy[_RETRY]. E.g. the original __ADD_ATOMIC_LONG is retained, and two new builtins __ATOMIC_ADD_LONG and __ATOMIC_ADD_LONG_ RETRY have been added. Besides builtins corresponding to the previous __xxx_ATOMIC* names, there are new builtins corresponding to the old __TESTBIT* builtins and new __ATOMIC_EXCH_* (atomic exchange) that had no counterpart in previous versions. All of these new builtins have the following characteristics: o No memory barriers are generated. If the application requires memory barriers before and/or after the atomic update, they must be explicitly coded (using inline assembly code or the __MB() builtin function). o The return value from each function is the old value of the location that was updated. o The functions that do not end in _RETRY continue to try until they succeed, so no status is returned. o Those that end in _RETRY take two additional parameters specifying the number of times to attempt the update, and the address of an integer status variable to contain the completion status. Note that while this specification makes for source code that suggests accesses to the status variable would always involve a memory access (since its address 20 is passed to something that looks like a function), these builtins are processed in a way that allows the status variable to remain in a register. There are also new builtins to implement efficient binary spinlocks: __LOCK_LONG, __LOCK_LONG_RETRY, __UNLOCK_LONG. And builtins to implement counted semaphores: __ACQUIRE_SEM_LONG, __ACQUIRE_SEM_ LONG_RETRY, __RELEASE_SEM_LONG. See the header file builtins.h and the User's Guide for more information. 6.5 Changes in DEC C RTL Header Files for V5.2 of DEC C/C++ The release notes in this section describe changes to the header files shipped with DEC C V5.2 for OpenVMS Systems. These header files contain enhancements and changes made to the DEC C Run-Time Library for OpenVMS Systems. New function prototypes and structure definitions which define new functionality in the DEC C Run-Time Library correspond to new functionality added to the DEC C Run-Time Library which is shipped with OpenVMS V7.0. o New Header Files Added A total of 20 new header files were added to the DEC C RTL suite of header files. Header files were added for implementation of Amendment 1 of the ISO C standard, compatibility with UNIX systems, and for introduction of new functions. Table 1 lists those headers added for DEC C V5.2. Table_1_New_DEC_C_V5.2_Header_Files________________________ Header File________Description____________________________________ Directory Manipulation Functions File Tree Walking Socket Packet Transport Mechanism (continued on next page) 21 Table_1_(Cont.)_New_DEC_C_V5.2_Header_Files________________ Header File________Description____________________________________ Socket Address Resolution Protocol I/O Controls for Special Files Alternative Spelling for Language Tokens Filename Manipulation String Handling Mapping Pages of Memory Maximum Domain Name Size Password File Access Functions Resolver Configuration File Declarations for Resource Operations String Handling Clock and Timer Functions File Access and Modifications Times Structure Time Zone Information User Information Declarations for Process Waiting __Wide_Character_Classification_and_Mapping______ o New Functions Defined In Header Files OpenVMS V7.0 introduces many new DEC C RTL functions which have been added to fulfill the request of application developers and to implement those functions defined by ISO C Amendment 1. These functions have been implemented on both OpenVMS Alpha V7.0 and OpenVMS VAX V7.0. These functions are documented in the DEC C Run- time Library Reference Manual for OpenVMS Systems. 22 basename() herror() seed48() sysconf() bcmp() hostalias() seekdir() telldir() bcopy() hstrerror() setenv() tempnam() btowc() index() sethostent() towctrans() bzero() initstate() setitimer() truncate() closedir() ioctl() setnetent() tzset() confstr() jrand48() setprotoent() ualarm() dirname() lcong48() setservent() uname() drand48() lrand48() setstate() unlink() endhostent() mbrlen() sigaction() unsetenv() endnetent() mbrtowc() sigaddset() usleep() endprotoent() mbsinit() sigdelset() vfwprintf() endservent() mbsrtowcs() sigemptyset() vswprintf() erand48() memccpy() sigfillset() vwprintf() ffs() mkstemp() sigismember() wait3() fpathconf() mmap() siglongjmp() wait4() ftruncate() mprotect() sigmask() waitpid() ftw() mrand48() sigpending() wcrtomb() fwide() msync() sigprocmask() wcsrtombs() fwprintf() munmap() sigsetjmp() wcsstr() fwscanf() nrand48() sigsuspend() wctob() getclock() opendir() socket_fd() wctrans() getdtablesize() pathconf() srand48() wmemchr() gethostent() pclose() srandom() wmemcmp() getitimer() popen() strcasecmp() wmemcpy() getlogin() putenv() strdup() wmemmove() getpagesize() random() strncasecmp() wmemset() getpwnam() readdir() strsep() wprintf() getpwuid() rewinddir() swab() wscanf() getservent() rindex() swprintf() gettimeofday() rmdir() swscanf() The following functions are specific to OpenVMS Alpha V7.0. These functions are the implementations specific to 64-bit pointers. (Alpha only.) 23 _basename64() _mbsrtowcs64() _strpbrk64() _wcsncat64() _bsearch64() _memccpy64() _strptime64() _wcsncpy64() _calloc64() _memchr64() _strrchr64() _wcspbrk64() _catgets64() _memcpy64() _strsep64() _wcsrchr64() _ctermid64() _memmove64() _strstr64() _wcsrtombs64() _cuserid64() _memset64() _strtod64() _wcsstr64() _dirname64() _mktemp64() _strtok64() _wcstok64() _fgetname64() _mmap64() _strtol64() _wcstol64() _fgets64() _qsort64() _strtoll64() _wcstoul64() _fgetws64() _realloc64() _strtoq64() _wcswcs64() _gcvt64() _rindex64() _strtoul64() _wmemchr64() _getcwd64() _strcat64() _strtoull64() _wmemcpy64() _getname64() _strchr64() _strtouq64() _wmemmove64() _gets64() _strcpy64() _tmpnam64() _wmemset64() _index64() _strdup64() _wcscat64() _longname64() _strncat64() _wcschr64() _malloc64() _strncpy64() _wcscpy64() While each of these functions are defined in the DEC C V5.2 header files, those definitions are protected by using if __VMS_VER >= 70000000 conditional compilation. o Usage of Feature-Test Macros The header files shipped with DEC C V5.2 have been enhanced to support feature test macros for selecting standards for APIs, multiple version support and for compatibility with old versions of DEC C or OpenVMS. Please see the DEC C Run-time Library Reference Manual, section 1.5 "Feature-Test Macros for Header-File Control", for a complete description of the feature test macros that are available. o Different Default Behavior After OpenVMS V7.0 The functions wait(), kill(), exit(), geteuid(), and getuid() have new default behavior for programs which are recompiled under OpenVMS V7.0 or later. To the retain the old behavior, use the _VMS_V6_SOURCE feature- test macro, as described in the reference manual. o Upgrade to Support 4.4BSD Sockets 24 As of OpenVMS V7.0, the socket definitions in the socket family of header files has added support for 4.4BSD sockets. To instruct the header files to use this support, define either _SOCKADDR_LEN or _XOPEN_SOURCE_ EXTENDED during the compilation. The functions gethostbyaddr(), gethostbyname(), recvmsg(), sendmsg(), accept(), bind(), connect(), getpeername(), getsockname(), recvfrom(), and sendto() have a second implementation which uses a new sockaddr structure defined in . o Integration of Timezone Support The DEC C RTL on OpenVMS V7.0 has added full support for Universal Coordinated Time using a public domain timezone package. When compiling on OpenVMS V7.0, the functions gmtime() and localtime() have a second implementation which use extensions to the tm structure defined in . To retain the ANSI C definition of this structure, define either _ANSI_C_SOURCE or _DECC_ V4_SOURCE. Note that compiling with the /standard=ansi qualifier implies _ANSI_C_SOURCE. o Integration of ISO C Amendment 1 Behavior The DEC C RTL on OpenVMS V7.0 has added full support for Amendment 1 of the ISO C Standard. When compiling on OpenVMS V7.0, the functions wcfstime() and wcstok() have a second implementation which implement the semantic changes required by this amendment. To retain the XPG4 semantics of these functions, define either _XOPEN_SOURCE or _DECC_V4_SOURCE. o Upgrade to Support 4.4BSD Curses Document changes to curses.h... ________________________ Note ________________________ The default definitions used during compilation for OpenVMS Alpha have been changed to __VMS_CURSES which is the same as OpenVMS VAX. To restore the original default curses package, the user must define __BSD44_ CURSES. ______________________________________________________ o FILE Structure Changed to Increase Open File Limit 25 Changes were made to the FILE type definition in to support an extended open file limit in the DEC C RTL. As of OpenVMS V7.0, the number of files which can be open simultaneously will be raised from 256 to 65535 on OpenVMS AXP and 2047 on OpenVMS VAX. This number is based on the OpenVMS sysgen CHANNELCNT parameter which specifies the number of permanent I/O channels available to the system. The maximum CHANNELCNT on OpenVMS AXP is 65535. On OpenVMS VAX it is 2047. In order to support more than 256 open files, the field in the FILE type containing the file descriptor "_file" had to be changed from a char type to an int type. The definition of the FILE type in stdio.h changed from: typedef struct _iobuf { int _cnt; // bytes remaining in buffer char *_ptr; // I/O buffer ptr char *_base; // buffer address unsigned char _flag; // flags unsigned char _file; // file descriptor number unsigned char _pad1; // modifiable buffer flags unsigned char _pad2; // pad for longword alignment } *FILE; to: typedef struct _iobuf { int _cnt; // bytes remaining in buffer char *_ptr; // I/O buffer ptr char *_base; // buffer address unsigned char _flag; // flags unsigned char _padfile; // old file descriptor numbe unsigned char _pad1; // modifiable buffer flags unsigned char _pad2; // pad for longword alignment int _file; // file descriptor number } *FILE; This change was coded using the __VMS_VER macro. As such programs compiled with a version of stdio.h containing support for an increased open file limit can be linked with a version of the DEC C RTL which either does or does not contain this support. Programs compiled with a version of stdio.h providing the new 26 FILE type definition which link on earlier OpenVMS versions obviously not be able to make use of this new functionality. o Header No Longer Includes As part of feature test macro work, no longer includes . This will affect some DEC C V5.0 programs that included stdlib.h and expected a type such as pid_t to be defined. The user must change their source to explicitly include . 6.6 Enhancements in V5.0 DEC C V5.0 contains the following enhancements: o Change to the meaning of /standard=portable The meaning of /standard=portable was previously documented as putting the compiler in VAX C mode and enabling the portability group of messages. The DEC C compiler for OpenVMS Alpha prior to V5.0 implemented this behavior, while the DEC C compiler for OpenVMS VAX implemented this qualifier by putting the compiler in relaxed ANSI mode and enabling the portability group. Feedback from users overwhelmingly indicated a preference for the behavior of the VAX compiler. Therefore the V5.0 compiler for OpenVMS Alpha has been changed to behave the same as the VAX compiler, and the documentation for both platforms is being updated to reflect this. o Major upgrade to the preprocessor The part of the compiler that implements preprocessing constructs has undergone a major upgrade. In most ways, the effect of this change should be invisible. Unless you have encountered problems with the preprocessor in previous releases that are now fixed, you should not expect to see much change except perhaps some additional compile-time improvement if you use heavily redundant #includes, or if you use #pragma message to control message reporting for preprocessor constructs. Because of the nature of the changes made, errors and warnings that are detected during preprocessing will typically be reported with different message text and different 27 message identifiers from previous releases (including the previous field test compiler). If your code relies on the identifiers or text for messages issued by the preprocessor, you will have to assess the new messages and their identifiers to get equivalent behavior. The general nature of the changes to the preprocessor are to improve its reliability and its compatibility with traditional Unix C compilers, without compromising its ANSI C adherence. In particular: o Explicit .I file ouput Much more attention has been given to the content of .I files produced by the /preprocess_only qualifier, such that compiling a .I file should more closely mimic the effect of compiling the original source. This includes issues such as the following: o Generation of whitespace to separate tokens only where necessary to prevent accidental token pasting when the .I file is compiled. o Generation of # num directives and blank lines to keep a better correspondence to the original source. o Processing of pragmas and directives (including builtins and dictionary) such that compiling the .I file in the absence of the original header files and/or CDD repository will produce the same effect as compiling the original source in its own environment of header files and repositories. o #pragma message, standard, and nostandard are now also respected under /preprocess_only, so that spurious diagnostics are not produced when making a .I file. o Token pasting More natural treatment of token-pasting operators that do not produce valid tokens: the pasting is simply ignored. 28 o Conditional preprocessing directives within macro argument lists More flexible treatment of the appearance of #if, #ifdef, #ifndef, #else, #elif, and #endif directives within the actual parameter list of a function-like macro invocation that spans multiple lines: the directives take effect. There is no ANSI-required behavior for such constructs, and they can easily appear when a function is changed to a function-like macro. Formerly an E-level diagnostic complaining about the syntax of the directive was issued. o Missing macro parameters More natural treatment of function-like macro invocations with missing actual parameters: each missing parameter is treated like an object-like macro with an empty replacement list. o Macro expansions in #include and #line More complete treatment of preprocessing directives like #include and #line, in the cases where a sequence of tokens requiring macro expansion occurs, and the result of the macro expansion is to be matched against one of the "fixed" forms. o Error recovery Better error recovery for preprocessor-generated diagnostics. In some cases the severity of a similar condition diagnosed by the previous version of the preprocessor has been reduced from an error to a warning or informational because the repair is what would be expected at that level. In particular, C preprocessors are sometimes applied to source code that is not really C code - the expectation is that the preprocessor would give at most a warning or informational, and the detection of an error condition resulting from the fixup made by the preprocessor can safely be left to the compiler's syntactic and semantic analysis phases. o Macro expansions in #pragma 29 More usual treatment of #pragma directives: the tokens are not subject to macro expansion. For pragmas that already have a well-established and documented behavior under DEC C, macro expansion is still performed. But for new DEC C pragmas and pragmas offering compatibility with other C compilers, macro expansion is not performed (since most other C compilers do not perform it). If an identifier used as the name of a pragma matches the name of a pragma that is defined not to have macro expansion performed, then no expansion will be performed. But unless /standard=common is specified, if the identifier is not the name of such a pragma, and it is the name of a currently-defined macro, then that macro gets expanded and the resulting token is compared to the following list of pragma names to determine if the rest of the pragma tokens should be macro expanded. This gives maximum compatibility with existing code, but allows the general behavior to be brought more in line with common practice. The pragmas that will continue to be subject to macro expansion are listed below. o _KAP o standard o nostandard o member_alignment o nomember_alignment o dictionary o inline o noinline o module o message o extern_model o builtins o linkage 30 o use_linkage o define_template (C++ only) o #pragma environment New #pragma environment. This new pragma allows saving and restoring the state of all pragmas for which the compiler supports a save/restore stack. It has two additional keywords to specify a state that is consistent with the needs of system header files, or to specify a state that is the same as what was established by command line switches at the start of compilation. The primary purpose is to allow the authors of header files describing data structures that will be accessible to library code to establish a consistent compilation environment in which their headers will be compiled, without interfering with the compilation environment of the user. The syntax is: #pragma environment save #pragma environment restore #pragma environment header_defaults #pragma environment command_line The save and restore keywords cause every other pragma that accepts save and restore keywords to perform a save or restore operation. The header_defaults keyword sets the state of all those pragmas to what is generally desirable in system header files. This corresponds to the state the compiler would be in with no command line options specified and no pragmas processed - except that #pragma nostandard is enabled. The command_line keyword sets the state of all such pragmas to what was specified by the command line options. See the Users's Guide and help files for a description of pragmas that accept save and restore keywords, and for command line options that control behaviors that are also controllable by pragmas. o __unaligned type qualifier: A new type qualifier called "__unaligned" has been introduced which can be used in exactly the same contexts as the ANSI C "volatile" and "const" type qualifiers. It can be used either on a declaration or in a cast to tell the compiler specific places where it should not assume natural alignment on a pointer 31 dereference, without making it apply to all dereferences the way the command line switch, /ASSUME=noaligned_ objects would. o DEC C V5.0 introduces support for in-line assembly code, commonly called ASMs on UNIX platforms. The use of ASMs in DEC C on OpenVMS Alpha is compatible with their use on the Digital UNIX platform. The opcodes and register names/numbers are accepted in either upper or lower case by DEC C on both platforms since conventions have traditionally differed between them. Both platforms also accept both the R-number register macro names common to VMS documentation and the so-called "software" names common to the UNIX documentation. Since ASMs are implemented with a function call syntax, you must include a new header file, c_asm.h, containing prototypes for the three types of ASMs, and a special pragma in order to use them. The syntax (in the header file) looks like this: __int64 asm(const char *, ...); /* integer ops */ float fasm(const char *, ...); /* float ops */ double dasm(const char *, ...); /* double ops */ #pragma intrinsic (asm) #pragma intrinsic (fasm) #pragma intrinsic (dasm) where: const char * the first argument to the asm, fasm or dasm contains the instruction(s) which are to be generated in-line and the metalanguage which describes the interpretation of the arguments. This must be a literal (compile-time) string or a preprocessor macro expanding to a literal string. 32 .... subsequent arguments are made available to the instructions specified in the first argument according to the calling standard conventions, with the first of these arguments corresponding to the first actual argument in the calling standard. I.e. the character string specifying the instructions to execute does not in itself count as an actual argument. The #pragma intrinsic directives notify the compiler that the named functions (asm, dasm, and fasm) are not normal user defined functions, and that the special asm processing should be applied. As a result, a compilation that includes c_asm.h cannot declare ordinary user functions with these names. Other modules in the same program that do not include the header file may declare functions with these names, however, since asm processing generates inline code within the calling module and never creates object module references to these names. There is a simple metalanguage for naming registers: : | ; : "$" number ; : "%" ; : number | | "f" number | "F" number | "r" number | "R" number ; 33 : "v0" /* R0, F0 return value */ /* scratch registers */ | "t0" | "t1" | "t2" | "t3" | "t4" /* save registers */ | "s0" | "s1" | "s2" | "s3 | "s4" | "s5" | "s6" | "s7" | "s8" | "s9" | "s10" | "s11" | "s12" | "s13" /* arg registers, R16-R21 */ | "a0" | "a1" | "a2" | "a3" | "a4" | "a5" /* R26 is return addr */ | "RA" | "ra" /* R27 is procedure value */ | "PV" | "pv" /* R25 is arg info */ | "AI" | "ai" /* R29 is frame pointer */ | "FP" | "fp" /* R31 contains zero */ | "RZ" | "rz" | "zero" /* R30 is stack pointer */ | "sp" | "SP" | "$sp" | "$SP" ; The literal string which contains instructions, operands, and metalanguage must follow the general form: : | ";" ; : instruction_operand | directive ; Where an instruction_operand is generally recognized as an assembly language instruction, separated by whitespace from a sequence of comma-separated operands. Note that it is possible to code multiple instruction sequences into one literal string. 34 Please note that there are semantic rules associated with ASMs, as well as syntax rules. The first argument to the asm call is interpreted as the instructions to be assembled in the metalanguage, and must be fully understood by the compiler at compile- time. That is indirections, table lookups, structure dereferences etc are NOT allowed. The remaining arguments are treated like normal function arguments, that is they are loaded into the argument registers according to the calling standard, with the first argument following the string treated as the first argument for calling standard purposes. For example: In the following test, the 6 arguments are loaded into arg registers %R16 through %R21 (equivalently %a0 through %a5 or just %0 through %5), and the result of each sub expression is stored in the value return register, %R0 (equivalently %v0). if (asm("addq %R16, %R17, %R0;" "addq %R18, %R0, %R0;" "addq %R19, %R0, %R0;" "addq %R20, %R0, %R0;" "addq %R21, %R0, %R0;", 1,2,3,4,5,6) != 21){ error_cnt++; printf ("Test failed\n"); } With double precision operands the same testcase would be written: if (dasm("addt %F16, %F17, %F0;" "addt %F18, %F0, %F0;" "addt %F19, %F0, %F0;" "addt %F20, %F0, %F0;" "addt %F21, %F0, %F0;", 1.0,2.0,3.0,4.0,5.0,6.0) != 21.0){ error_cnt++; printf ("Test failed\n"); } 35 Note that the following does not work, and produces a compile-time warning stating that r2 is used before it is set, because the arguments are loaded into the arg registers (r16-r21), not r2. Similarly, the result of the addq instruction would not be assigned to z because the destination of the addq instruction is not the return value register (%v0 or %R0). z = asm("addq %r2, %a1 %r5",x=10,y=5); The correct way of doing this is to specify an argument register number in place of r2, and make sure the code puts any result in the result register appropriate to the type of the asm (%v0 for integer, %f0 for float and double). One exception to the above rule is that the return address register (%ra or %r26) may be used in an asm without being set. This is handled specially; it tells the compiler to get the return address that was in %R26 at the time the function containing the asm was invoked. Thus z = asm("mov %ra, %v0") puts the address to which the containing function will return into z, regardless of whether or not register R26 still holds that address at this point in the code. As noted, a result register must be specified in the metalanguage for the result to appear in the expected place if the ASM is used as a value-producing function. For instructions which do not take any argument and which do not have a return type, simply leave out the arguments. For example: asm("MB"); o /NESTED_INCLUDE_DIRECTORY= (PRIMARY_FILE, INCLUDE_FILE, NONE) has been enhanced. Extended to accept the NONE keyword. This specifies that the compiler skips the first step of processing #include "file.h" directives. It starts looking for the included file in the /INCLUDE_DIRECTORY directories. It does not start by looking in the directory containing the 36 including file nor in the directory containing the top level source file. Default: /NESTED_INCLUDE_DIRECTORY=INCLUDE_FILE (current behavior) UNIX equivalent: -nocurrent_include /NESTED_INCLUDE_DIRECTORY=NONE o /MMS_DEPENDENCY[=(FILE[=filespec] | [NO]SYSTEM_INCLUDE_ FILES ,... )] /NOMMS_DEPENDENCY has been added. The qualifier /MMS_DEPENDENCY corresponds tells the compiler to produce a dependency file. The format of the dependency file is similar to that on Digital UNIX. object_file_name : object_file_name : object_file_name : The FILE subqualifier specifies where to save the dependency file. The default file extension for a dependency file is .mms. Other than using the different default extension, this qualifier uses the same procedure as /OBJECT and /LIST for determining the name of the output file. The SYSTEM_INCLUDE_FILES subqualifier specifies whether or not to include dependency information about system include files. That is, those included with #include . The default is to include dependency information about system include files. Default: /NOMMS_DEPENDENCY UNIX equivalents: -MD /MMS_DEPENDENCY -M /MMS_DEPENDENCY=(FILE=SYS$OUTPUT) -MM /MMS_DEPENDENCY=(FILE=SYS$OUTPUT,- NOSYSTEM_INCLUDE_FILES) default /NOMMS_DEPENDENCY o /[NO]LINE_DIRECTIVES has been added 37 This qualifier governs whether or not # ddd directives appear in preprocess output files. Currently, there is no way to specify the form of the line directives. DEC C always generates the "old-style" # ddd form, even in ANSI modes. Default: /LINE_DIRECTIVES UNIX equivalents: -P /NOLINE_DIRECTIVES -E /LINE_DIRECTIVES o /COMMENTS=(AS_IS,SPACE)/NOCOMMENTS has been added. This qualifier governs whether or not comments appear in preprocess output files. If they do not appear, it specifies what replaces them. AS_IS specifies that the comment appears in the output file. SPACE specifies that a single space replaces the comment in the output file. /NOCOMMENTS specifies that nothing replaces the comment in the output file. This may result in inadvertent token pasting. The C and C++ preprocessor may replace a comment at the end of a line or a line by itself with nothing, even if /COMMENTS=SPACE is specified. Doing so cannot change the meaning of the program. Default: /NOCOMMENTS in the VAXC and COMMON modes of the C compiler /COMMENTS=SPACE for C++ and the ANSI modes of the C compiler. An explicit /COMMENTS on the command line defaults to /COMMENTS=AS_IS. UNIX equivalents: -oldcomment /NOCOMMENTS -C /COMMENTS=AS_IS default /COMMENTS=SPACE o /[NO]VERSION has been added. This is a completely new qualifier intended to make it easier for users to report which compiler they are using. 38 This qualifier causes the compiler to print out via printf the compiler version and platform. The compiler version is the same as in the listing file. Defaults: /NOVERSION UNIX equivalents -V /VERSION default /NOVERSION o /CHECK=UNINITIALIZED_VARIABLES has been added. This qualifier determines whether or not unitialized automatic variables are initialized to the value 0xfffa5a5afffa5a5a. This value is a floating NaN so will cause a floating point trap if used. If used as a pointer, it will likely causes an ACCVIO. This is a debugging aid. Defaults: /NOCHECK UNIX equivalents: -trapuv /CHECK=UNINITIALIZED_VARIABLES o New Predefined Macros There are new predefined macros __DECC_VER and __VMS_ VER, which map compiler version numbers and VMS version numbers respectively into an unsigned long int. The compiler version number is extracted from the compiler ident and the VMS version macro is obtained by calling sys$getsyiw(SYI$_VERSION). These string values are then changed into an integer in an implementation defined manner. It is intended that newer versions of the compiler and VMS will always have larger values for these macros. If for any reason the version string returned by sys$getsyiw(SYI$_VERSION) or even the compiler's own ident string cannot be analyzed, then the corresponding predefined macro will be defined, but it will have a value of 0. Please note that pre-5.0 compilers do not define these macros, so it is possible to distinguish a pre-5.0 compiler from a compiler that is given a bad version string by using #ifdefs or the defined operator. 39 /*__DECC_VER is not defined before V5.0 test for a compiler V5.1 or higher */ #ifdef __DECC_VER #if (__DECC_VER >= 50100000) / * code */ #endif #endif /* test for VMS 6.2 or higher */ #ifdef __VMS_VER #if __VMS_VER >= 60200000 /* code */ #endif #endif o Compile Time Performance Improvements Some compile-time improvements have been made for V5.0. The most notable improvement is that the preprocessor now is usually able to determine if a particular #include file that has already been processed once was guarded by the conventional "#ifndef FILE_SEEN, #define FILE_SEEN, #endif" sequence. When the compiler detects this pattern of use the first time a particular file is included, it remembers that fact as well as the name of the macro. The next time the same file is included, the compiler checks to see if the "FILE_SEEN" macro is still defined, and if so it does not reopen and reread the file. Note that if the initial test is in the form "#if !defined" instead of "#ifndef", then the pattern is not recognized. In a listing file, #include directives that are skipped because of this processing are marked with an "X" just as if the #include line itself were excluded. o Run Time Performance Improvements The compiler backend has been upgraded with general improvements to the optimizer and with specific improvements to the inliner, listed below. 40 o Enhancements to inline optimization: The heuristics for automatic inlining ( /inline=automatic) have been improved somewhat to select inlining opportunities that are more likely to produce improved execution speed without increasing code size too much. The keywords "size" and "speed" have been added to the command line qualifier /OPTIMIZE=INLINE. The keyword "size" gives behavior similar to the intent of the keyword "automatic" in previous compilers, although it is somewhat more conservative in most cases ("automatic" is now treated as a synonym for "size"). "size" inlines functions when the compiler determines this it would improve run-time performance without significantly increasing the size of the program. The keyword "speed" performs more aggressive inlining for run-time performance, even when it may significantly increase the size of the program. /[NO]OPTIMIZE=INLINE={size | speed | automatic | manual | none | all} #pragma noinline may be used to prevent inlining of any particular functions under the 3 compiler-selected forms of inlining. And #pragma inline (or the __inline qualifier as used in C++) may be used to request inlining of specific functions under the automatic or manual forms of inlining. The "all" keyword is not generally recommended as it may often increase both compilation resources and runtime size unacceptably. o XPG4 Support DEC C V5.0 supports the worldwide portability interfaces described in the X/Open CAE Specifications: System Interfaces and Headers, Issue 4; System Interfaces Definitions, Issue 4; and Commands and Utilities, Issue 4. These interfaces allow an application to be written for international markets from common source code. This model of internationalization is the same as found on many UNIX systems, including Digital UNIX. 41 Note: The new support for internationalization requires OpenVMS V6.2-FT2 or later. DEC C V4.1 contained the following new features: o #dictionary support DEC C V4.1 introduces support for inclusion of CDD records. The syntax and features are the same as for DEC C V4.0 on OpenVMS/VAX, except that V4.1 will also accept two new keywords, text1_to_array and text1_to_ char. #[pragma] dictionary "pathname" [null_terminate] [name(struct_name)] [text1_to_array | text1_to_char] pathname: a quoted pathname for a CDD record to be extracted. null_terminate: an optional keyword which adds an additional byte for the null character when a data type of text is extracted. name(): an optional keyword to supply an alternate tag name or declarator, struct_name, for the outer level of a CDD structure. text1_to_char: an optional keyword which forces the CDD type text to be translated to char, rather than array of char if the sizen is 1. This is the default, unless null_terminate was specified. text1_to_array: an optional keyword which forces the CDD type text to be translated to type array of char, even when the size is 1. This is the default when null_terminate is specified. 42 6.7 Enhancements since V1.3A o Expanded IEEE support DEC C V4.1 introduces the /IEEE_MODE switch to allow users to control the way IEEE exceptional values are generated and handled. /IEEE_MODE= FAST (default) UNDERFLOW_TO_ZERO DENORM_RESULTS INEXACT FAST During program execution, only finite values (no infinities, NaNs, or denorms) are created. Exceptional conditions, such as floating point overflow and divide by zero, are fatal. UNDERFLOW_TO_ZERO Generate infinities and NaNs. Flush denorms and underflow to zero without exceptions. Only modules containing main() are affected by this switch. Modules not containing main() compiled with this switch default to DENORM_RESULTS. DENORM_RESULTS Generate infinities, NaNs and denorms. Do not trap on inexact. INEXACT Generate infinities, NaNs and denorms. Do trap on inexact. This is the slowest mode of IEEE support, and should only by used if inexact trapping is absolutely required. 43 o Enhanced floating point rounding support DEC C V4.1 introduces the /ROUNDING_MODE switch to allow users to specify how IEEE floating point values should be rounded. /ROUNDING_MODE=NEAREST (default) DYNAMIC MINUS_INFINITY CHOPPED /ROUNDING_MODE lets the user specify which of the above four rounding modes will be employed (if /FLOAT=IEEE_FLOAT has also been specified). Note that when either /FLOAT=G_FLOAT (the default) or D_FLOAT have been specified, the only allowable rounding mode is NEAREST. o 128 bit floating point support /L_DOUBLE_SIZE=128 (default) 64 DEC C V4.1 supports "long double" as a 128 bit software emulated type, x_float. With previous compilers, "long double" was synonymous with "double" . This is no longer the case. Please note that default behavior of "long double" is now x_float, and must be explicitly overridden to g_ float, d_float, or t_float by specifying /L_DOUBLE_ SIZE=64. Please see the preceding section on Targeting to Pre-6.1 Systems for a discussion on implications of this switch. The /FLOAT= switch continues to specify which of g_ float, d_float, or t_float should be generated for "double" variables. o /PSECT_MODEL=[NO]MULTILANGUAGE /PSECT_MODEL=MULTILANGUAGE instructs the compiler to employ a psect allocation scheme for shared, overlaid psects which is compatible with psects generated by other Alpha VMS compilers. 44 Since C structs to be shared with a FORTRAN application are padded (and FORTRAN COMMON blocks are not), usage of this switch prevents a possible linker error when multiple images created by two language translators share a common psect. The default is /PSECT_MODEL=NOMULTILANGUAGE, which is the old behavior. o Enhanced compiler diagnostics The check group, under /WARNING=ENABLE=CHECK has been embellished to detect a number of new questionable user coding practices. o PRAGMA NOMEMBER_ALIGNMENT value The #pragma nomember_alignment pragma has been augmented to accept as an argument any one of the following case- insensitive values: byte (the default), word, longword, quadword, octaword This value directs the compiler to align the structure at the specified boundary. The compiler will, however, continue to byte align the members of the structure, as per nomember_alignment. With this behavior it is now possible to specify structures whose size is not a multiple of their alignment. This is problematic in the case of arrays of such structs. Consequently, the compiler will generate an -E- level diagnostic, along with a suggestion for the amount of required padding the user should specify in the struct to ensure size compatibility. When using this new alignment option, it is also suggested that the /WARNING=ENABLE=CHECK commandline switch be used to allow the compiler to check for poorly aligned structure members. o Support for C++ style comments 45 DEC C for OpenVMS Alpha supports C++ style comments in all modes except /STANDARD=ANSI89, because they are not allowed by the C standard. o Suppress object module references to unused extern declarations DEC C no longer requires definitions for unreferenced declared objects. The following program no longer produces the linker diagnostic %LINK-W-UNDFSYMS: extern int x; #include int main(void) { printf ("Hello, world\n"); } o In addition to #pragma inline function_name, the user can now suggest inlining of a function with __inline. Below, both func1 and func2 are candidates for inlining: p __inline void func1(void) {} void func2 (void) {} #pragma inline func2 o The redundant use of a type qualifier of a pointer (e.g., int * const const p;) produces a warning diagnostic. o Redundant type specifiers (e.g. int int x;) now produces warning, not error, diagnostics. Warning diagnostics are suppressible via /WARNING=DISABLE, whereas error diagnostics are not. o Functions declared volatile or const via a typedef: typedef int (F) (); const volatile F abs; now produce a CONSTFUNC or VOLATILEFUNC diagnostic. 46 o A new level of optimization, /OPT=LEVEL=5 . When selected, this includes all optimizations through level 4, plus software pipelining. See the User's Guide, table 1-9 for more information. o Numerous other compiler optimizations, including: o small integer operations (char and short) o numerous code improvements accessing struct members o improved peephole optimizations o builtins.h no longer includes ints.h . 6.8 Problems fixed since V5.3 o In V5.3-006, if a source file to be compiled resided on a remote filesystem that was mounted by NFS client services (either from Digital's UCX product or from other products providing NFS client services on OpenVMS Alpha), or in some cases if the file was remote-mounted using DFS, it was possible to receive the following fatal error message from the compiler: %CC-F-OPENIN, error opening 'input-file' as input -RMS-F-COD, invalid or unsupported type field in XAB at 'addr' The only workaround was to move the source(s) to a local disk. o Under /optimize=level=5, the V5.3-006 compiler could encounter an assertion failure attempting to compile certain kinds of loops with conditional exits. An example is: $ type foo.c main() { int len; char *cp; 47 while ((len > 1) && (*cp == '0')) ++cp, --len; } $ cc/optimize=level=5 foo.c Assertion failure: Compiler internal error - please submit... %GEM-F-ASSERTION, Compiler internal error - please submit... %GEM-F-ASSERTION, Compiler internal error - please submit... %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine line DECC$COMPILER GEM_DB GEM__DB_ASSERT_END 720 DECC$COMPILER GEM_DB GEM_DB_ABORT 587 DECC$COMPILER GEM_DB GEM_DB_ABORT_FAST 610 DECC$COMPILER GEM_LU VECTORIZE_LOOP 7606 DECC$COMPILER GEM_LU GEM_LU_MAIN 2126 DECC$COMPILER GEM_CO GEM_CO_COMPILE_ROUTINE 2078 DECC$COMPILER GEM_CO GEM_CO_COMPILE_MODULE 1432 DECC$COMPILER 0 DECC$COMPILER 0 DECC$COMPILER GEM_CP_VMS GEM_CP_MAIN 2509 o The globalvalue extern_model could produce a compiler traceback when an external variable of a struct or other type not supported by globalvalue was encountered. The compiler now produces an appropriate warning message and uses the strict_refdef model for such declarations. o SCA typing information for incomplete arrays declared with a typedef declaration were sometimes incorrect and complex declarations caused compile time access violations. Known instances of these problems have been corrected. o Placement of certain kinds of pragmas within declarations could cause compiler failures or erroneous .ANA files to be produced uner /ANALYSIS_DATA. o Forward declarations involving structure members no longer cause invalid .ANA files to be produced when compiling with /ANALYSIS_DATA 48 o Invalid .ANA files are no longer produced when compiling with /ANALYSIS_DATA for source files with code beyond column 256. o Better SCA reference information is output for struct declarations and references. o Functions with an excessive number of parameters (around 100) will no longer cause the compiler to crash when outputting SCA information. Instead, a warning message is emitted and further parameters will not generate SCA information. o Debugger support for pointers to functions has been improved. o Improved initialization for redeclared variables. Previously the compiler would not initialize a in the following code int a; static int a = 1; o Delete the object file for certain backend-detected errors. o Issue a warning for a cast expression used as an lvalue in strict ANSI mode. o Warning messages issued by the compiler backend are now subject to message control qualifiers and pragmas. Previously, message idents such as ASMRAWREG (issued by the backend for inline assembly code that uses a hardware register that was not initialized by anything visible to the compiler) were not known to the message control facility. An attempt to suppress the ident would 49 produce the message '%CC-W-UNKMSGID, Unknown message id or group "ASMRAWREG" is ignored.' o A #undef or #define preprocessing directive appearing within the arguments to a function-like macro invocation could cause the compiler to crash (e.g. if it undefined or redefined the function-like macro being invoked). This now produces a warning message. o Source files containing very large numbers of #line preprocessing directives could cause a seemingly infinite loop in the compiler due to an n**2 algorithm. The algorithm is now linear. o A number of changes have been made to improve compatibility with VAX C, Microsoft C, and UNIX compilers. New messages have been introduced and old ones altered to mimic more accurately the behavior of these other compilers when using the /STANDARD switch. Some of the these compatibility changes are: o Do not accept an array of incomplete types. o Do not allow constructs like "(z ? x : y).a = 1;" o Issue warning for pointer to int assignment. o Do not allow pointer types as case constants. o Disable processing of type qualifiers after a comma. o Handle redeclaration of items with different storage classes. 50 o Implement VAX C style unnamed struct/union members in VAXC mode, where the struct/union type of the unnamed member is treated as if it occurred outside of any containing struct/union. In MS mode, the same construct is treated like a C++ unnamed member of union type in C++: the members of the nested struct /union are promoted to the containing struct/union, similar to the behavior of VAXC variant_struct and variant_union constructs. o Allow "x->y" under /STAND=VAXC where x is an integer constant or variable. o Under /STAND=VAXC, "sizeof(&array)" now returns "sizeof(array)" (i.e. the size of the array object) instead of the size of a pointer (which is what ANSI C requires in this case). o Emit meaningful error message for a[b] when both a and b are pointers. o Emit informational in VAXC mode for declarations with an explicit "extern" storage class which are also initialized. o Issue a warning message for cases like a->b where a is a pointer to an incomplete struct/union. o In MS mode, allow an incomplete array type only as the last member in a struct or union. Previously, other incomplete types were accepted, and they were not restricted to the last member. o Allow globalvalues to be used in initializers Alpha as they are on VAX. 51 o Allow ellipsis in old-style function definitions under /STAND=VAXC. o Emit language extension messages for __restrict and __unaligned in /STAND=PORT o Improve handling of VAX C storage class modifiers (noshare, readonly, _align) to more closely match the VAX C compiler's behavior. o In modes other than VAXC, emit additional diagnostics when a function is redeclared with a different type. 6.9 Problems fixed since V5.2 o V5.2 introduced a bug which caused logical name translation to be applied to the names of text library modules. o V5.2 changed the behavior of /NESTED_INCLUDE=PRIMARY_ FILE on Alpha to match that of DEC C on VAX, which was unintentionally incompatible with the original VAX C behavior. In V5.3, both VAX and Alpha interpret this qualifier to produce behavior that is compatible with VAX C. o Use of the /CHECK=POINTER_SIZE qualifier could cause a compiler failure if a cast of a constant to a long pointer type was assigned to a short pointer variable. o Calling LIB$SIGNAL from within a signal handler failed to produce a traceback. 52 o Problems involving the use of variable argument lists ( or ) were fixed. These involved old-style function parameters of types requiring default argument promotion (now get an E-level diagnostic), and the use of a va_list variable that was not a simple locally-declared variable (now handled correctly). o Diagnostic messages containing character constants using a hex escape sequence were being printed with the "x" character omitted. o The preprocessor now allows the "defined" operator to be produced as a result of macro expansion. ANSI C does not specify whether or not this should be allowed. Under /standard=ansi89, a warning message is produced when the preprocessor encounters such a construct. In relaxed ANSI an informational is issued instead. o Under /STAND=VAXC, the type of the sizeof operator is now signed int (matching the behavior of VAX C) rather than unsigned int (which is required by ANSI C). o A block-scope extern declaration with incomplete type, with linkage to a file-scope declaration with complete type, "hid" the completed type information from being available within the scope of that block. This could produce an E-level diagnostic for a correct program such as the following: int i[] = {1, 2, 3}; unsigned int f() { extern int i[]; return sizeof(i); } o An initialized globalvalue may now be used as a compile- time constant, just as an enumeration value can be. 53 o For a compilation with multiple source files in a comma- list, the module names in the .ana files produced under the /ana qualifier were incorrect for all but the first compilation. o Under /standard=vaxc, match the VAX C behavior and accept a sequence of conflicting type specifiers with a warning and use the last one, instead of issuing an E-level diagnostic. o SPR HPAQA9E70: Statically initialized data declared with the "const" qualifier was being placed in the $READONLY$ psect, even if it contained address constants requiring fixups. This rendered the entire psect non-sharable. Constant addresses requiring fixups are now placed in a different psect ($READONLY_ADDR$), allowing the $READONLY$ psect to remain sharable. o SPR HPAQ628CF: Static initialization using a globalvalue as an initializer produced incorrect initialization if the type of object being initialized was not int (e.g. if it was a char or short type). o The compiler now allows an actual argument to a function call to pass the address of a globalvalue; formerly this produced an E-level diagnostic even in VAX C mode. Also changed the mechanism for passing the address of a constant such that if the callee modifies the value it will not affect subsequent calls. This makes the behavior compatible with VAX C. o The compiler failed to diagnose an ANSI constraint violation for an old-style function definition with a parameter identifier list, where one of the parameter names matches a visible typedef name. 54 o The compiler failed to diagnose use of the name of a variant_struct or variant_union member when constructing the name of a contained member. This is a VAX C feature, and VAX C compiler produces an E-level diagnostic if the name is used in this way. o The compiler was incorrectly producing an E-level "invalid declarator" diagnostic when a label was defined with the same name as a typedef. Labels have a separate namespace and should not conflict with other declarations. o The compiler would fail if it attempted to output a diagnostic message referring to an unnamed bit field in a struct or union declaration. o Under /stand=common, hexadecimal escape sequences (\xnnnn) were being recognized within string literals and character constants. This feature was part of VAX C and ANSI C, but it was not present in "pcc" compilers, and recognizing it under /stand=common produced results that differed from pcc compilers. o SPR HPXQ11CEF: Compiler failure when globaldef storage class is applied to a function. The compiler now gives an appropriate E-level diagnostic when globaldef, globalref, or globalvalue storage class is applied to a function. o Compiling a function definition that attempts to use a typedef for its function header could either cause a compiler failure or produce an inappropriate diagnostic, e.g.: typedef void VFV(); VFV f; VFV f {} 55 This now produces the correct diagnostic: %CC-E- TYPEDEFFUNC, In this function definition, "f" acquires its type from a typedef. o If a globaldef declaration specified a psect name, the psect specification would be ignored if the same variable was previously declared in a globalref declaration. o A block-scope declaration with the extern storage class would cause a compiler failure if the identifier being declared matched a visible typedef name declared at file scope. o Compiler failure when attempting to output a fatal error message. The following example produced a compiler failure trying to output the fatal error message for include file not found. The root cause involved the specific placement of the pragmas in relation to the declaration: struct my_s { #pragma message save #pragma message disable portable int one; int two; #pragma message restore }; #include o When the VAX C "main_program" keyword was used to identify a main program procedure with a name other than "main", the compiler still generated a global procedure named "__MAIN". This made it difficult to put more than one such object module into a single object library. The compiler now makes the "__MAIN" symbol it generates in this case a local symbol. 56 o Under /stand=vaxc, an incompatibility between a function prototype and the corresponding function definition produced only a W-level diagnostic, but calls to such a function were silently ignored by the compiler, causing incorrect behavior at runtime. The diagnostic remains at W-level, but now the generated code is correct. o Compiler failure when processing a long comma-list of source files (more than 20 sources). o SPR UVO104030: Compiler failure under /preprocess_only when processing a pragma with incorrect syntax. 6.10 Problems fixed since V5.0 o DEC C will now Skip parameter checks if we are evaluating an operand to sizeof in common mode as in the example below: j(int a) { p(sizeof(j())); } The severity of the messages concerning too many and too few parameters is now a warning in VAXC mode ( /STAND=VAXC) rather than an error. This behavior is compatible with VAX C. o Error messages have been relaxed for conflicting extern defs as follows: For /STAND=COMMON there is no change in behavior. All extern declarations are promoted to file scope. When the compiler encounters a conflicting declaration, it will issue a error as it has always done. For /STAND=VAXC the severity of the error message has been reduced to a warning. VAX C issues a warning whenever it finds a conflicting extern declaration. It does not matter if the declarations are in the same name scopes or not. In 57 addition to issuing a warning, VAX C replaces the prior declaration with the new declaration from the point of the new declaration onward. DEC C now matches this behavior in VAXC mode. For /STAND=ANSI, /STAND=RELAXED Errors will be generated, (as they always were) if there is a conflict between declarations that are in the same or inner name scopes. DEC C will issue a warning if there is a conflict between names that are in disjoint scopes. This will no longer be an E-level message. The standard says that such a case is in error, but that a diagnostic does not have to be issued. We felt that it was better to issue a diagnostic than to silently accept the program. For example, in the program shown below: /STANDARD=COMMON will result in no diagnostic messages. /STANDARD=VAXC will result in a warning message about incompatibile declarations for the second and third declaration of init_color /STANDARD=RELAXED, /STANDARD=ANSI will result in an informational diagnostic on the second declaration of init_color because it is implicitly declared and will result in a warning on the third declaration because it is incompatible with the declaration on line 3, even though it is in a different scope. main() { extern void init_color(); } Raise_Maps() { init_color(); } Title_Page() { extern void init_color(); } 58 o A problem has been corrected which could cause an ACCVIO at compile time when compiling with the qualifier /ANALYSIS_DATA. o In all modes, functions declared at block scope will now have their storage class set to extern. A warning is issued if the storage class is register. A warning is also issued if the storage class is auto (except in VAXC mode). If the storage is static, in common and vaxc mode then no warning is issued for the declaration. But a warning will issued later if the function is referrenced and not defined anywhere in the module. o SPR EVT101335 Whenever a call causes more than 255 items (longwords on VAX/quadwords on Alpha) to be used in constructing the arg list a warning will be issued. On Both VAX and Alpha an informational will be output warning that the argument list length exceeds maximum specified by the calling standard. /* This program used to ACCVIO on VAX/VMS, now it gets a compile-time diagnostic */ struct { int i; char longer_than_1020[1021]; } public_domain_sloppy_programmer; void nothing(); main () { nothing (public_domain_sloppy_programmer); } o SPR UVO102632 Formerly the compiler sometimes failed to issue a diagnostic when an assignment was made to a constant array as in the example below: 59 void fred (void) { typedef int A[2][3]; const A a = {{4, 5, 6}, {7, 8, 9}}; a[0][0] = 42; } o The compiler will now accept unnamed structures as members of a struct in VAXC mode. o The compiler will now issue a warning instead of an error when pointers and ints are compared in common mode. o The compiler will now issue a warning when preprocessing directives are used in the argument list for a macro o The compiler will now Allow more than just integers in switch and case expressions in vaxc and common modes. We now issue a new warning when a float or pointer is used in a switch or case expression. o A problem has been corrected involving the #dictionary directive when it was nested within a structure declaration. The compiler now correctly generates a member name for the extracted CDD record nested within a struct, not a tag name. o The Alpha VMS V5.0 Help (and the User's Guide) are incorrect in their description of /IEEE_MODE=FAST. The V5.0 documentation reads: /IEEE_MODE /IEEE_MODE=option /IEEE_MODE=FAST (D) 60 Selects the IEEE floating-point mode to be used if /FLOAT=IEEE_FLOAT is specified. Options: FAST During program execution, no exceptions are raised and only finite values (no infinities, NaNs, or denorms) are created. Your program must examine errno for any error indication. It should, however, read: Options: FAST During program execution, only finite values (no infinities, NaNs, or denorms) are created. Exceptional conditions, such as floating point overflow and divide by zero, are fatal. o The compiler will no longer remove code that accesses a location under the "volatile" qualifier, even if the value is unused. E.g. the statement "x;" will now generate code to fetch x if x was declared volatile. o The macro definitions within a /define=(name[=value],...) list are now processed left to right. Thus /DEFINE=(A=1,A=2) now leaves A defined as 2 instead of 1. o Some cases of right-shifting the result of an int left- shift operation could produce incorrect code, e.g. ((i32 << 24) >> 16) and ((i64 << 32) >> 48) produced incorrect results. o Problems with the /NESTED= qualifier have been fixed. o The severity of the NONMULTALIGN message has been reduced to a warning. o o Several problems in computing the value of an integer constant constructed through token-pasting in the preprocessor have been fixed. E.g. the following code formerly resulted in an incorrect message "%CC-W- INVALTOKEN, Invalid token discarded". 61 #define concat(a,b) a ## b return concat(0x0,1AL) ; It now is handled correctly. 6.11 Problems fixed since V4.1 o DEC C used to issue messages for lexical "errors" appearing within the bodies of macro definitions for macros that were never used. In some cases these should not have been issued according to ANSI C (e.g. warnings for octal constant containing digits 8 or 9), and generally such potential problems do not require an ANSI diagnostic. Common practice is to defer such reports until a macro is used, which is what DEC C now does. o The result of compiling the output of the /PREPROCESS_ ONLY qualifier was not always the same as the result of compiling the original program. Consider the program below. #define A(x) -x main() { int i = 1; printf("%d\n", -A(i)); } The output from /PREPROCESS_ONLY used to place the '-' of the body of macro A next to the '-' before the macro invocation, producing: printf("%d\n", --i); Now the output has a space to separate the two '-' characters to prevent this accidental token-pasting unless the compiler is in common or vaxc modes, where this kind of token-pasting is done when compiling the original source directly. 62 o When doing macro substitution inside string constants in VAX C mode, DEC C did not always substitute when VAX C would. Given the macros: #define str1(arg) "arg" #define str2(arg) "arg-ber" #define str3(arg) "go to the arg" Formerly DEC C did not do a replacement in str2 where VAX C does. Now this replacement is done. o ICA-48945: mixing of old-style and new style function prototypes: The compiler now allows mixing of new-style function prototypes and old style function definitions where the prototype parameters are not fully promoted integer types (according to default argument promotion rules). With this modification, all integer type combinations are allowed (including signed/unsigned mixing). A warning is issued where we were issuing an E level error in the past (no message is issued if in VAXC mode and the integer types in the old style parameter definition match those in the prototype, as in the code fragment provided in the SPR). void f (char); void f (p1) char p1; {} $ cc/stand=vaxc foo.c $ cc foo.c char p1; .....^ %CC-W-PROMOTMATCHW, In the definition of the function "f", the promoted type of p1 is incompatible with the type of the corresponding parameter in a prior declaration. at line number 3 in file DISK:[dir]FOO.C;1 63 In addition, the following will now correctly compile: extern in (*f1())(int (*f2)()); int (*f1(f2))() int (*f2)(); { return 0;} o HPXQ7084C, CDD datatype text size 1, can now be converted be converted to an array of char or to a char using the new #dictionary keywords, text1_to_array, text1_to_char. o HPXQ74784 DEC C will no longer ACCVIO when an include file can not be found. o UVO101931 The will now generate correct code for the following program /NOOPT: #include typedef unsigned __int32 uns32 ; main () { uns32 y1, y2 ; char str1[255] ; y1 = 23 ; y2 = 1 ; str1[24 - y1 + y2] = '\0' ; // <- Used to Crash here } o DEC C no longer gives an erroneous INCOMPNOLINK diagnostic for the following code: static int a[] = {0, -1, 2, -3, 4, -5, 6, -7, 8, -9}; int main() { extern int a[]; } This used to occur only if the extern declaration for a appeared inside a block. 64 o The compiler will now correctly give a diagnostic if C++ style comments are used with /STANDARD=PORT or /STANDARD=ANSI89. o Full support for 64bit integer constants is now available, e.g. /* Value of constant cannot be represented as * unsigned long, so it is unsigned __int64. */ unsigned __int64 foo = 0x7fffffffffffffffu; 6.12 Problems fixed since V4.0 o HPXQ97CFE: The maximum length of a source line has now been relaxed to the maximum allowed by RMS. o Fixed a problem which caused V4.0 to miss breakpoints on an if statement when the OpenVMS/Alpha V6.1 was being used. o Fixed a DST nesting error when a sequence of two or more typedefs occurred in a recursive type declaration. o HPAQ92A0F: Formally, the debugger referenced bitfields as longwords, which caused problems when depositing values into those bitfields. This problem has been fixed. o An ECO kit is available to fix problems with printf and fcvt IEEE floating point. o Fixed a compile-time ACCVIO when compiling volatile structs with /NOMEMBER_ALIGN o builtins.h 65 The storage for __xxxQUE_MAP_ALPHA_TO_VAX and __REMQxI_ MAP_ALPHA_TO_VAX has been moved from builtins.h to the DEC C RTL in order to reduce the number of bytes of storage required by the header file. o curses.h Changes have been made to improve the functionality of the default curses package. o float.h On OpenVMS Alpha the D_FLOAT definitions of DBL_MAX and LDBL_MAX were corrected. o fp.h The new header file implements some of the features defined by the Numerical C Extensions Group of the ANSI X3J11 committee. Applications making extensive use of floating point functions may find this useful. Some of the double precision DEC C RTL functions return the value HUGE_VAL (defined in either math.h or ) if the result is out of range. The float versions of those functions return the value HUGE_VALF (defined only in ) for the same conditions. The long double versions return the value HUGE_VALL (also defined in ). Note that for programs compiled to enable IEEE infinity and NaN values, the values HUGE_VAL, HUGE_ VALF and HUGE_VALL are expressions, not compile-time constants. Initializations such as the following cause a compile-time error: $ CREATE IEEE_INFINITY.C #include

double my_huge_val = HUGE_VAL ^Z $ CC /FLOAT=IEEE/IEEE=DENORM IEEE_INFINITY double my_huge_val = HUGE_VAL; .....................^ %CC-E-NEEDCONSTEXPR, In the initializer for my_huge_val, "decc$gt_dbl_infinity" is not constant, but occurs in a context that requires a constant expression. at line number 3 in file WKD$:[LCRTL]IEEE_INFINITY.C;1 $ 66 When using both math.h and be aware that math.h defines a function isnan() and defines a macro by the same name. Whichever header is included first in the application will resolve a reference to isnan(). To force references to use the function instead of the macro, enclose the name of the function in parentheses, e.g. (isnan)(arg) instead of isnan(arg). o math.h The D_FLOAT definition of HUGE_VAL was corrected on both OpenVMS VAX and OpenVMS Alpha. o ints.h Definitions for (u)int16 and (u)int32 were added for use by DEC C++ programs on OpenVMS VAX. This will allow DEC C programs using (u)int16 or (u)int32 to be portable to DEC C++ on OpenVMS VAX. o perror.h Definitions for decc$ga_sys_errlist and decc$gl_sys_nerr were added for use by DEC C and DEC C++ programs. These are provided for compatibility with VAX C programs that made use of sys_errlist and sys_nerr. o setjmp.h A prototype for decc$setjmp was added. o stat.h Macros defining constants for group and other protection masks were added to match the ones for 'owner'. o stdarg.h A definition for va_count was added. o stdio.h Modifications were made to the definitions of clearerr, feof, ferror such that proper usage of these macros does not give warnings when compiling /WARNING=ENABLE=CHECK. o unixlib.h Prototypes were provided for the following routines on OpenVMS VAX: decc$to_vms, decc$from_vms, decc$match_ wild, decc$fix_time, decc$translate_vms. 67 6.13 Problems fixed since V1.3A o Fixed several problems with SCA support. o Fixed a problem in include file lookup behavior whereby the compiler would search the wrong directory under /NESTED_INCLUDE=INCLUDE. o Fixed compiler assertions generated by certain references to the PAL_REMQxxx functions. o Fixed a problem in the static initialization of bitfield structs of greater than 32 bits. o Fixed a compile-time ACCVIO when compiling a structure containing an array of incomplete structures. o The compiler now correctly detects attempts to pass a pointer to an array of pointers to const chars to a function expecting a pointer to a pointer to an array of pointers to non-const chars: static void f(char *argv[]) {} static void g(const char *argv[]) { f(argv); } > cc foo.c f(argv); ..^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "argv" is "Pointer to const char", which is not compatible with "Pointer to char". o A problem in which carriage returns immediately following comments caused the compiler to crash, has been fixed. 68 o All known restrictions regarding initialization of variant_unions have been lifted. o A problem in which _align() did not result in correct alignment has been fixed. o In any of the /STANDARD={VAXC,RELAXED_ANSI89,COMMON} modes, a redeclaration of a function with an empty argument list is now compatible with previous declarations containing ellipses. The following declarations are now compatible: #include fopen(); o Problems with implicit conversions from unsigned base integer types to their same sized signed counterparts have been fixed. o A problem with bad code generated for uint64 switch statement values has been fixed. Using int64 switch statement values is still problematic. See the restrictions section below. o An optimizer error involving left shifts in doubly nested loops has been fixed. o An internal compiler assertion involving conversions from int to address has been fixed. o A problem in which #pragma [no]standard could at times cause subsequent code to be ignored has been fixed. o A problem with /NESTED_INCLUDE causing an infinite loop has been fixed. 69 o A problem involving incorrect assignment of psect RD/WRT attributes has been fixed. o A problem with aliasing of extern variables has been fixed. o An /OPT=LEVEL=5 problem involving comma-listed post- increment operators as the increment expression of a for loop has been fixed. 7 Support for STDARG.H and VARARGS.H The standard header files STDARG.H and VARARGS.H which are provided with the DEC C for OpenVMS Alpha have special builtin support to walk the argument list. To walk the argument list of a routine, you must use the standard macros in one of the above header files. Programs that take the address of a parameter and, through pointer arithmetic, independently walk the argument list to obtain the value of other parameters, make the assumption that all arguments reside on the stack and that arguments appear in increasing order. These assumptions are not valid when using the DEC C for OpenVMS Alpha. To ensure correct results the macros provided in the header files must be used. 8 Debugger support OPTIMIZATION LEVEL: For satisfactory use during debugging, modules should be compiled using /NOOPTIMIZE. Compilation with normal (full) optimization will have these noticeable effects: 1. Stepping by line will generally seem to bounce forward and back, forward and back, etc, due to the effects of code scheduling. The general drift will definitely be forward, but initial experience indicates that the effect will be very close to stepping by instruction! 70 2. Variables that are "split" so that they are allocated in more than one location during different parts of their life times are not described at all. FORMAL PARAMETERS: Formal parameters that are passed in registers, while not handled quite like normal split variables, do share many of the same problems as split variables. Even with /NOOPTIMIZE, such a parameter will often be immediately copied to a "permanent home" (either on the stack or in some other register) during the routine prolog. The DST description of such parameters encodes this permanent home location and NOT the physical register in which the parameter is passed. The end-of-prolog location is recorded in the DSTs and will be used as the preferred breakpoint location when a breakpoint is set in the context of an appropriately set module (so that DST information is available to the debugger). PLUS_LIST_OPTIMIZE: /PLUS_LIST_OPTIMIZE executables are fully debuggable. If two or more variables in different files share the same name and are statically declared, however, the debugger cannot discriminate between them. Users should in this case do an "EVAL/ADDR FOO" for variable FOO, and subsequently reference the address of the variable. 9 64 bit support The compiler has builtin types for signed and unsigned 16, 32, and 64 bit integer data types. They are intended for applications that must have integer data types of a specific size across platforms that can provide the data type. Note that some data types, for example 64 bit integer types, are available on OpenVMS Alpha but not available on OpenVMS VAX. The header file ints.h contains typedefs for the integer data types. For sake of portability, we encourage the use of ints.h typedefs and highly discourage the use of the builtin data types directly. 71 The content of ints.h is included below: /* * - Definitions for platform specific integer types * * * Copyright (c) 1993 by Digital Equipment Corporation. * All rights reserved. * * DEC C for OpenVMS VAX and OpenVMS Alpha * DEC C++ for OpenVMS VAX and OpenVMS Alpha */ #if defined(__DECC) || defined(__DECCXX) /* This file uses non-ANSI-Standard features */ #pragma __nostandard #else #pragma nostandard #endif #ifdef __cplusplus extern "C" { #endif typedef signed char int8; typedef unsigned char uint8; #if defined(__DECC) || (defined(__DECCXX) && defined(__ALPHA)) typedef signed __int16 int16; typedef unsigned __int16 uint16; typedef signed __int32 int32; typedef unsigned __int32 uint32; #if defined(__ALPHA) typedef signed __int64 int64; typedef unsigned __int64 uint64; #endif #endif #ifdef __cplusplus } #endif 72 #if defined(__DECC) || defined(__DECCXX) /* This file uses non-ANSI-Standard features */ #pragma __standard #else #pragma standard #endif 64bit integer constants are now supported. 10 Restrictions and known bugs This is a list of some known compiler restrictions and bugs. o Under /NESTED_INCLUDE_DIRECTORY=PRIMARY_FILE, the sticky-default processing for included files ignores filespec information from top-level source files that are empty. o There is a permanent restriction that header file searches involving DECnet file specifications may not correctly interpret an access string with password. This is because an expanded filespec is actually used to open the files, and expanded filespecs are stored without the password information for security reasons. Thus an attempt to open the file using the expanded name will generally fail. The DECnet access should be made without the need for a password (e.g. through the default account or through a proxy). o Currently, the compiler allows you to take the address of any predefined built-in function. This should be illegal and a compile time error should be generated. o Function argument lists longer than 255 longwords are not consistently diagnosed. o The globaldef keyword when used with an enum type definition does not make all of the enumeration constants globalvalues in VAX C mode. If you wish to make the values of enum constants available to another 73 module, put the enum type definition in a header file and include it. o When data is placed into the LIB$INITIALIZE psect using the extern_model psect naming controls, by default DEC C creates the psect with quadword alignment like any other data psect, rather than the longword alignment required for this special VMS psect. This is easily addressed by specifying the alignment explicitly on the extern_model pragma. This is a permanent restriction. o The following VAX C pragmas are not supported. This is a permanent restriction. o #pragma ignore_dependency o #pragma safe_call o #pragma sequential_loop o There is currently no support for the PDF (/DESIGN) and DWCI tools. o The functions LIB$ESTABLISH, LIB$REVERT, and VAXC$ESTABLISH are recognized by the compiler as builtin functions. There is currently a restriction that the builtins do not return the previous condition handler as their function result. o DEC C does not correctly handle array data members of function return results (for functions returning struct or union values): typedef struct { struct { int field4; int field5[10]; } field3; } struct_t; struct_t return_struct(void); 74 void foo (struct_t y) { int x, z; z = y.field3.field5[0]; /* generate NEEDPOINTER diagnostic below */ x = return_struct().field3.field5[0]; } x = return_struct().field3.field5[0]; ..........^ %CC-E-NEEDPOINTER, In this statement, "return_struct(...).field3.field5" has an array type, but occurs in a context that requires a pointer. at line number 14 in file disk:[dir]FOO3.C;1 o If your code includes assert.h multiple times and uses the text library form of inclusion, #include assert, the first include will work correctly. But, the second include causes the compiler to issue an error message about an invalid include file name. This is because assert have been defined as a macro within assert.h, so the compiler is looking at the macro expanded file name, which does not exist. The assert macro may be used elsewhere without any problems. Digital recommends that you avoid the text library form of inclusion for assert.h. Use #include instead. o DEC C gives an erroneous PTRMISMATCH diagnostic for certain array pointers: static void func1(const double dbl[][3]) {} 75 static void func2(void) { double adPnts[8][3]; func1 (adPnts); } $cc test.c func1 (adPnts); ...^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "adPnts" is "array [3] of double", which is not compatible with "const array [3] of const double". You may suppress this diagnostic with /WARNINGS=DISABLE=PTRMISMATCH or with #pragma message disable ptrmismatch. o DEC C may give redundant diagnostics for FLOATOVERFL, FUNCREDECL, and PROTOSCOPE3. Two diagnostics will point to the same location. Fixing the problem makes both diagnostics go away. o The diagnostic for array declarations with more than INT_MAX elements is misleading. It should state that there are too many elements in the array. 76