DEC C/C++ Run-Time Components Version 6.0 for OpenVMS_VAX_Systems_________________________________ Release Notes February 19, 1996 This document contains information about using the DEC C/C++ Run-Time Components kit with C and C++ programs. Digital Equipment Corporation Maynard, Massachusetts ________________________________________________________________ First Printing, October 1993 Revised Printing, May 1994 Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Digital or an authorized sublicensor. © Digital Equipment Corporation 1993. All Rights Reserved. The following are trademarks of Digital Equipment Corporation: Alpha AXP, AXP, Bookreader, CDD, DEC, Digital, DECnet, DECthreads, DECwindows, OpenVMS, POLYCENTER, VAX, VAX C, VAX DOCUMENT, VMS, VMScluster, and the DIGITAL logo. The following are third-party trademarks: AT&T is a registered trademark of American Telephone and Telegraph Company. Motif is a registered trademark of the Open Software Foundation, Inc. POSIX is a registered trademark of the Institute of Electrical and Electronics Engineers, Inc. PostScript is a registered trademark of Adobe Systems Inc. This document was prepared using VAX DOCUMENT Version 2.1. _________________________________________________________________ Contents 1 Introduction.................................. 1 1.1 DEC C/C++ Run-Time Components Release Notes..................................... 1 1.1.1 Run-Time Components..................... 1 1.1.2 Link-Time Components.................... 5 1.1.2.1 Linking Problems with Multiple C RTLs................................... 6 1.1.3 Additional Information.................. 12 1.2 OpenVMS Upgrade Considerations............ 12 1.3 Installation Validations and Checks....... 14 1.4 Impact on Software Development and Distribution.............................. 17 1.5 Interaction of Components with Other Digital Layered Products.................. 20 1.5.1 POLYCENTER Network Manager V1.3......... 20 1.5.2 POSIX for OpenVMS VAX Version 1.2....... 20 2 DEC C RTL Version 6.0 Release Notes........... 20 2.1 Miscellaneous Problems.................... 21 2.2 DEC C RTL Performance Enhancements........ 21 2.3 Behavior Differences Between the VAX and DEC C RTLs................................ 22 2.4 Linking with the DEC C RTL................ 24 2.4.1 Linking with DEC C RTL Shareable Images.................................. 25 2.4.2 Linking with DEC C RTL Object Libraries............................... 25 2.4.3 Linking with DEC C or VAX C RTL Object Libraries/NOSYSSHR...................... 26 2.5 DEC C RTL Obsolete Features............... 26 2.6 DEC C RTL Interoperability Restrictions... 27 2.7 Known Problems............................ 29 3 DEC C++ Class Library Version 1.1 Release Notes......................................... 30 iii 4 DEC C++ Class Library Release Notes........... 31 4.1 Notes on All Packages..................... 31 4.2 Notes on the complex Package.............. 31 4.3 Notes on the iostream Package............. 31 4.4 Notes on the Messages Package............. 32 4.5 Notes on the String Package............... 32 4.6 Notes on the task Package................. 33 5 DEC C/C++ Run-Time Components Version 6.0 for OpenVMS VAX Installation Release Notes........ 36 5.1 Bug Fixes................................. 36 Tables 1 Linking Conflicts......................... 7 2 Changes in printf() Behavior Required by ANSI...................................... 23 iv 1 Introduction This document contains the release notes for the DEC C/C++ Run-Time Components Version 6.0 for OpenVMS VAX kit. For additional information about the DEC C Run-Time Library, see the DEC C Run-Time Library Reference Manual for OpenVMS Systems. 1.1 DEC C/C++ Run-Time Components Release Notes The DEC C/C++ Run-Time Components kit provides a variety of shareable images, message images, and object libraries needed by C and C++ programs compiled with Digital's C and C++ compiler products for OpenVMS VAX systems at link and run time. By installing this kit on an OpenVMS VAX system, Digital and user-written C and C++ programs developed on other OpenVMS VAX systems can be run without the need to install a C or C++ compiler product. These release notes contain a brief summary of the components contained in this kit, a short explanation of the role each plays at link time and run time in the C and C++ environment, and a description of where to find additional information. Not all components of this kit are installed on all versions of OpenVMS VAX systems. More recent versions of OpenVMS VAX already contain most of the components, so this kit will install components only on systems that do not already contain them. In some cases, the versions on this kit supersede existing versions of these files. This allows new capabilities or error corrections to be supported on systems running older versions of OpenVMS VAX. 1.1.1 Run-Time Components This section describes the components needed for proper run-time behavior of C and C++ applications developed using Digital's compilers for OpenVMS VAX systems. The components are: o DECC$SHR.EXE (shareable) is the primary image that implements the DEC C Run-Time Library (RTL). It contains all the run-time functions supported by the DEC C and DEC C++ languages. The kit copies it to the SYS$LIBRARY directory on the target system. It is inserted into SYS$LIBRARY:IMAGELIB.OLB by this kit so that you can 1 link C and C++ programs with this file without the need to specify it explicitly in the LINK command. o VAXCRTL.EXE, VAXCRTLG.EXE (shareable) are the primary images that implement the VAX C RTL. They contain all the run-time functions supported by VAX C Version 3. The kit copies them into the SYS$LIBRARY directory on the target system. They are not inserted into SYS$LIBRARY:IMAGELIB.OLB because they contain unprefixed names in their symbol tables that might conflict with the names of user-written functions in languages other than C or C++. Whereas all versions of OpenVMS VAX to which this kit applies contain some version of these files, the versions described in this document are provided to let certain versions of OpenVMS VAX support improved interoperability of the errno global variable with applications that use VAXCRTL.EXE with DECC$SHR.EXE or with CMA$RTL.EXE. Given the new errno compatibility support in this file and in CMA$TIS_SHR.EXE, the installer must declare CMA$TIS_SHR.EXE as a known image with the INSTALL utility after this kit installation is complete. See the DEC C/C++ Run-Time Components for OpenVMS VAX Reference and Installation Guide for more information on this topic. o VAXCMSG.EXE (message) contains the text of the messages issued by the DECC$SHR and VAXCRTL images. The kit copies it to the SYS$MESSAGE directory on the target system. o CXXL$011_SHR.EXE (shareable) contains the DEC C++ class library. It contains a variety of packages, each of which contains one or more classes used in the C++ language to access some run-time features. Among these packages is the TASK package, which requires the availability of the CMA (DECthreads) shareable images. The kit copies this file to the SYS$LIBRARY directory on the target system. It is inserted into SYS$LIBRARY:IMAGELIB.OLB by this kit so that you can link C++ programs with this file without the need to specify it explicitly in the LINK command. 2 o CXXL$MSG_SHR.EXE (message) contains the text of the messages issued by the CXXL$011_SHR image. The kit copies it to the SYS$MESSAGE directory on the target system. o CMA$RTL.EXE (shareable) contains the core functions of the DECthreads facility. These may be called from any VMS language because they are not specific to DEC C++. However, DEC C++ supports the task package, which uses DECthreads, so this DECthreads support file is needed to fully support DEC C++ at run time. The version of this file included on this kit contains code to coordinate the use of the errno global variable with the DECC$SHR image and the VAXCRTL, which older versions do not support. The kit copies this file to the SYS$LIBRARY directory on the target system. It is inserted into SYS$LIBRARY:IMAGELIB.OLB by this kit so that you can link DEC C++ programs with this file without having to specify it explicitly in the LINK command. o CMA$OPEN_RTL.EXE (shareable) contains the vectors to the documented open entry points of the core functions of the DECthreads facility. It is treated the same as CMA$RTL.EXE except that it is not included in SYS$LIBRARY:IMAGELIB.OLB. o CMA$LIB_SHR.EXE (shareable) contains the DECthreads library functions. These may be called from any VMS language because they are not specific to DEC C++. The version of this file included on this kit contains code to coordinate the use of the errno global variable with the DECC$SHR image and the VAXCRTL, which older versions do not support. The kit copies this file into the SYS$LIBRARY directory on the target system. The image is inserted into SYS$LIBRARY:IMAGELIB.OLB by this kit. o CMA$OPEN_LIB_SHR.EXE (shareable) contains the open entry points of the DECthreads library functions. It is treated the same as CMA$RTL.EXE except that it is not included in SYS$LIBRARY:IMAGELIB.OLB. 3 o CMA$TIS_SHR.EXE (shareable) contains the Thread Independent Services of the DECthreads facility. These services may be called from any VMS language, they are not specific to DEC C++. The image contains a run-time registration facility that allows DECC$SHR, VAXCRTL, and DECthreads to use the errno global variable in a limited, coordinated way. By using the versions of CMA$TIS_SHR, DECC$SHR, VAXCRTL(G), and DECthreads on this kit, modifications to errno in DECC$SHR and DECthreads can be seen by DECC$SHR, DECthreads, VAXCRTL(G), and the calling program compiled with DEC C++. However, VAXCRTL's design prevents modifications to errno by VAXCRTL(G) functions from being seen by DECC$SHR, DECthreads, or calling programs compiled with DEC C++. The kit copies this file to the SYS$LIBRARY directory on the target system. It is inserted into SYS$LIBRARY:IMAGELIB.OLB by this kit so that you can link C and C++ programs with this file without the need to specify it explicitly in the LINK command. Given the new errno compatibility support supplied in this file and by VAXCRTL(G).EXE, this file must be declared as a known image with the INSTALL utility after this kit installation is complete. See the DEC C/C++ Run-Time Components for OpenVMS VAX Reference and Installation Guide for more information on this topic. o SMGSHR.EXE (shareable) contains the Screen Management Package. The kit copies this file into the SYS$LIBRARY directory on the target system. The kit inserts this file into SYS$LIBRARY:IMAGELIB.OLB. While a version of this file exists on all versions of OpenVMS for which this kit applies, the version on this kit contains new capabilities to allow the curses functions of the C language to execute properly. o VAXC2DECC.EXE and VAXCG2DECC.EXE (shareable) contain unprefixed entry points for referencing DECC$SHR.EXE. These images can be used by C programs compiled with VAX C Version 3 or with DEC C++ using the /NOPREFIX qualifier. The kit copies these files to SYS$LIBRARY on the target system. Because they define unprefixed names, they are not inserted into SYS$LIBRARY:IMAGELIB.OLB. 4 You can most conveniently migrate programs currently linked against the VAX C RTL shareable images to the DEC C RTL by linking them with the VAXC2DECC.EXE shareable images. VAXC2DECC.EXE provides the same transfer vectors and global symbols as VAXCRTL.EXE; VAXCG2DECC.EXE corresponds to VAXCRTLG.EXE. The VAXC2DECC images contain very little code; they consist primarily of transfer vectors into DECC$SHR. By referencing these images at link time instead of VAXCRTL(G).EXE, VAX C programs can use the DEC C RTL without the need to modify source code or recompile. This allows them to take advantage of the DEC C RTL functional, performance, or compatibility features not available from the VAXCRTL. To use either of these images, replace the current VAX C RTL shareable image in your linker options file with its corresponding VAXC2DECC image. For example, a program that used to be linked with VAXCRTL.EXE can be migrated to the DEC C RTL by linking as follows: $ link/exec=myprog mymod1,mymod2,sys$input:/option sys$library:vaxc2decc/share ^Z Because the VAXC2DECC images provide the same API as the VAXCRTL images, they suffer the same universal symbol and psect name collision problems as the VAXCRTL images. See Section 1.1.2.1 for more details. 1.1.2 Link-Time Components The shareable images listed in the section above are also needed at link time. If they have been inserted into SYS$LIBRARY:IMAGELIB.OLB, then the LINK command will automatically find them and they need not be mentioned in the LINK command. They also need to exist in the SYS$LIBRARY directory at run time for the referencing application to work properly. In contrast, the files in this section are needed only at link time for the purposes described with each file. The shareable images are: o DECCRTL.OLB, DECCRTLG.OLB, DECCCURSE.OLB (object libraries) are shareable libraries that contain the DEC C RTL functions. The kit copies these files into the SYS$LIBRARY directory on the target system. Both 5 prefixed and unprefixed entry point names are supplied. Thus, programs compiled with either VAX C Version 3 or DEC C++ can link with these libraries if the developer wants to avoid the need for a run-time reference to DECC$SHR. DECCRTL.OLB contains all the non-Curses functions and the D floating forms of the floating point math functions. DECCRTLG.OLB contains the G floating forms of the floating-point math functions. DECCCURSE.OLB contains the Curses functions. o VAXCRTL.OLB, VAXCRTLG.OLB, VAXCCURSE.OLB (object libraries) are shareable libraries that contain the VAX C RTL functions. The kit copies these files into the SYS$LIBRARY directory on the target system. All entries are unprefixed. Thus, only programs compiled with VAX C or with DEC C++ using the /NOPREFIX qualifier can use these libraries. Whereas, all versions of OpenVMS VAX to which this kit applies contain some form of these libraries, the versions described in this document are provided for certain versions of OpenVMS VAX to support improved interoperability for use of the errno global variable with applications that use VAXCRTL.EXE with DECC$SHR.EXE or with CMA$RTL.EXE. 1.1.2.1 Linking Problems with Multiple C RTLs Multiple C RTLs are likely to be required to link an application when using the DEC C RTL, particularly when linking in a shareable image. A second C RTL is not explicitly linked against but brought into the link by way of a shareable image. For example, when developing a Motif program using DEC C++, the application must be linked against the DEC C RTL and against the Motif images. Motif will currently bring the VAX C RTL into the link. Problems often occur when linking with multiple C RTLs because the VMS linker resolves symbol references in the image being linked by searching the transitive closure of shareable images and libraries. That is, when a shareable image is being linked against, the linker searches that shareable image as well as all the shareable images referenced in that shareable image. When linking against VAXCRTL.EXE and against an image linked against VAXCRTLG.EXE, the linker finds two instances of all the C RTL symbols (one in VAXCRTL and one in VAXCRTLG) and reports a conflict. 6 The object libraries do not conflict with routine names, but they do conflict with the global symbols. Because VAX C implemented global symbols as global overlaid program sections (psects), the linker will attempt to connect all the instances of a C-generated psect with the same name. For example, a reference to stdin in the user program is connected with the psect of the same name in VAXCRTL.OLB. However, a shareable image that was linked with VAXCRTL.OLB also has a psect of the same name, and an error occurs because the linker cannot connect those two definitions of the psect stdin. The interoperability tools VAXC$EMPTY.EXE, DECC$EMPTY.EXE, and VAXC$LCL.OPT are used to resolve link-time conflicts. They work by hiding the conflicting symbols from one of the C RTLs being linked against. Which tool is required depends on which C RTLs are being used by the main application and the shareable image. Table 1 shows the typical C RTL conflicts and the interoperability tool required to resolve the conflict. In the table, VAXCRTL.EXE typically refers to either VAXCRTL.EXE or VAXCRTLG.EXE. Table_1_Linking_Conflicts__________________________________ Linker_Message______Type_of_conflict__________Tool_Used____ LINK-E-MULSHRPSC VAXCRTL.OLB/VAXCRTL.EXE VAXC$LCL.OPT LINK-E-SHRPSCLNG VAXCRTL.OLB/DECCRTL.OLB VAXC$LCL.OPT LINK-W-MULDEF VAXCRTL.EXE/VAXCRTLG.EXE VAXC$EMPTY LINK-W-MULDEF VAXC2DECC.EXE VAXC$EMPTY /VAXCRTL.EXE LINK-E-MULSHRPSC, DECCRTL.OLB/VAXCRTL.EXE VAXC$LCL.OPT LINK-E-SHRPSCLNG (none)______________DECCRTL.OLB/DECC$SHR.EXE__DECC$EMPTY___ The interoperability tools are: o VAXC$LCL.OPT (options file) 7 This options file respecifies the GBL attribute on psects that implement the C language global variables (such as stdin) to its opposite value: LCL. The kit copies this file to the SYS$LIBRARY directory on the target system. VAXC$LCL.OPT is required when building any shareable image that is linked with the VAX C RTL object library. If the shareable image is built without using VAXC$LCL.OPT, the C RTL global symbols will be visible in the shareable image and cause linker conflicts when users of the image link against it. For example: %LINK-E-MULSHRPSC, psect C$$TRNS_VALUES defined in shareable image IMAGE1.EXE; is multiply defined in shareable image SYS$LIBRARY:VAXCRTL.EXE;1 -LINK-E-NOIMGFIL, image file not created In this example, the shareable image IMAGE1 uses VAXCRTL.OLB, and the image being linked uses VAXCRTL.EXE. If the shareable image is relinked using VAXC$LCL.OPT, the link will succeed. The following message also indicates a conflict involving the VAX C RTL object library: %LINK-E-SHRPSCLNG, Psect STDIN has length of 8 in module C$EXTERNDATA file SYS$LIBRARY:DECCRTL.OLB;2 which exceeds length of 4 in shareable image IMAGE1.EXE; -LINK-E-NOIMGFIL, image file not created In this example, the shareable image IMAGE1 uses VAXCRTL.OLB, and the image being linked uses DECCRTL.OLB. If the shareable image is relinked using VAXC$LCL.OPT, the link will succeed. If the shareable image cannot be relinked (such as a third-party shareable image), then the interoperability tool may be applied to the main image. If the main image is being linked against DECCRTL.OLB, then VAXC$LCL.OPT can be applied to the link of the main image. If the main image is being linked against VAXCRTL.EXE, then the only solution is to get the shareable image fixed. Applying any of the interoperability tools to the link of the main image will result in an unsuccessful link. 8 o VAXC$EMPTY.EXE (shareable) VAXC$EMPTY.EXE is required to link against a shareable image that was linked against either VAXCRTL.EXE or VAXCRTLG.EXE and the calling program is linking against the object library version of the VAX C RTL, the VAXC2DECC.EXE shareable image, or the other version of the VAXCRTL shareable image. When linking a calling program against such a shareable image, link-time error messages may appear, citing multiple declarations of C RTL global program sections. VAXC$EMPTY.EXE hides all the global symbols in the VAXCRTL.EXE and VAXCRTLG.EXE shareable images. These files are not used at run time. The kit copies VAXC$EMPTY.EXE to the SYS$LIBRARY directory on the target system. When linking against a shareable image that itself was linked against either VAXCRTL.EXE or VAXCRTLG.EXE, VAXC$EMPTY.EXE should be used when: o The application referencing a shareable linked against VAXCRTL.EXE or VAXCRTLG.EXE is linking against the object library version of the VAX C RTL o The application referencing a shareable linked against VAXCRTL.EXE or VAXCRTLG.EXE is linking against either the VAXC2DECC.EXE or VAXCG2DECC.EXE shareable images o The application referencing a shareable linked against VAXCRTL.EXE is linking against the VAXCRTLG.EXE shareable image o The application referencing a shareable linked against VAXCRTLG.EXE is linking against the VAXCRTL.EXE shareable image When a conflict exists between C RTL shareable images, the linker produces large numbers of messages similar to the following: %LINK-W-MULDEF, symbol ACOS multiply defined in module VAXCRTL file SYS$COMMON:[SYSLIB]VAXCRTL.EXE;18 9 In this example, the shareable image is linked with VAXCRTL.EXE, and the main program is linked with VAXC2DECC.EXE. The solution is to define the VAXCRTL logical to point at VAXC$EMPTY.EXE before linking the main program. For example: $ define/user vaxcrtl sys$library:vaxc$empty.exe $ link/exec=main_image main_prog,obj1,obj2,...,sys$input:/option image1/share vaxcrtl/share ^Z Note that your linker options file cannot reference SYS$LIBRARY:VAXCRTL; it must refer to VAXCRTL only. Do not link explicitly against VAXC$EMPTY, because your application will neither link correctly, nor run correctly. Finally, do not leave the VAXCRTL logical defined to point at VAXC$EMPTY.EXE because your application will not run correctly. The example uses, the DEFINE/USER command to ensure that the logical definition will be removed after the execution of the LINK command. However, no additional commands can intervene between the DEFINE/USER command and the LINK command. Follow the same process when linking against VAXCRTLG.EXE; define the VAXCRTLG logical to point at VAXC$EMPTY. o DECC$EMPTY.EXE (shareable) Use DECC$EMPTY.EXE to guarantee that the DEC C RTL object library is used when linking against a shareable image that was linked with DECC$SHR.EXE. If you do not use DECC$EMPTY.EXE during the link, the linker resolves all DEC C RTL references from the main program in DECC$SHR.EXE, not the object library. No linker message indicates this fact. These files are not used at run time. The kit copies DECC$EMPTY.EXE to the SYS$LIBRARY directory on the target system. For example: $ link/exec=main_image main_prog,obj1,...,sys$input:/option image1/share sys$library:deccrtl/library ^Z 10 If IMAGE1 is linked against DECC$SHR.EXE, and the link shown in this example is performed, then the main image will not contain any DEC C RTL object modules. All C RTL references from the main program will be resolved from DECC$SHR. By defining the DECC$SHR logical to point at DECC$EMPTY immediately before the link, all references to C RTL symbols from the main program will be resolved from the DEC C RTL object library. For example: $ define/user decc$shr sys$library:decc$empty.exe $ link/exec=main_image main_prog,obj1,...,sys$input:/option image1/share sys$library:deccrtl/library Do not link explicitly against DECC$EMPTY because your application will neither link correctly nor run correctly. Finally, do not leave the DECC$SHR logical defined to point at DECC$EMPTY.EXE as your application will not run correctly. The previous example uses the DEFINE/USER command to ensure that the logical definition will be removed after the execution of the LINK command. However, no additional commands can intervene between the DEFINE/USER command and the LINK command. o UCX$CRTLIBXFR.OBJ (object) This file contains the entry point definitions for the UCX socket library functions. The kit copies this file to the SYS$LIBRARY directory of the target system. If the UCX product is installed on the target system, the installer of this kit should perform a LIBRARY/REPLACE /GLOBALS command to replace the global symbols in the file SYS$LIBRARY:UCX$IPC.OLB with this object module. This will allow DEC C++ programs to call the socket routines. This does not affect VAX C or VAXCRTL users. 11 1.1.3 Additional Information The individual components are documented in a variety of OpenVMS and layered product manuals. Refer to those manuals for instructions on how to develop and use the interfaces to these components. o For VAXCRTL.EXE, VAXCRTLG.EXE, VAXCRTL.OLB, VAXCRTLG.OLB, VAXCCURSE.OLB, and VAXCMSG.EXE see the VAX C Run-Time Library Reference Manual (Version 3.2) o For DECC$SHR.EXE, DECCRTL.OLB, DECCRTLG.OLB, DECCCURSE.OLB, and VAXCMSG.EXE see the DEC C Run-Time Library Reference Manual for OpenVMS Systems (Version 1.3) o For CMA$RTL.EXE, CMA$OPEN_RTL.EXE, CMA$LIB_SHR.EXE, CMA$OPEN_LIB_SHR.EXE and CMA$TIS_SHR.EXE, see the Guide to DECthreads. o For CXXL$011_SHR.EXE and CXXL$MSG_SHR.EXE, see the DEC C++ Class Library Reference Manual (Version 1.1). o For SMGSHR.EXE, see the VMS RTL Screen Management (SMG$) Manual. 1.2 OpenVMS Upgrade Considerations The file names of some kit components are the same as files included in OpenVMS upgrade procedures. Some Digital layered products also contain one or more of these component files. The versions on this Run-Time Components kit supersede all component versions that predate OpenVMS VAX Version 6.0, such as those contained in earlier OpenVMS VAX upgrades or older layered product kits. Examples are the components VAXCRTL.EXE, VAXCRTLG.EXE, SMGSHR.EXE and VAXCMSG.EXE. Thus, it is possible that, during a OpenVMS upgrade to a lower OpenVMS version than Version 6.0, or when installing an older layered product kit, that some such components from the DEC C/C++ Run-Time Components kit will be unconditionally replaced with older versions of these same files. Any application that depends on such kit component files will stop working when such an upgrade occurs. A variety of failure modes, from wrong answers to program crashes, can occur due to the many different capabilities supported by these components. 12 To prevent this problem on systems with this kit installed, reinstallation is required immediately after any OpenVMS upgrade or layered product installation that supplies any of these files. By doing this, any component deleted or superseded by an older OpenVMS file of the same name can be replaced before application programs can experience a regression. The installation procedure will automatically avoid improperly superseding newer component versions provided by OpenVMS VAX Version 6.0 (and later) upgrades. To guard against such problems, the startup file for this kit, which is copied to the file SYS$STARTUP:CRT$STARTUP.COM during installation, contains a series of image ident verification operations. Specifically, it checks to ensure that system versions of files known to be subject to regressions by OpenVMS upgrades or layered product kits exist, and have a minimum image identity field of at least the value provided by OpenVMS Version 6.0. If one or more of these checks fails during the startup procedure, a message is sent to the SYSTEM account describing the check that failed and what file(s) have regressed. If such a message is received, it is generally only necessary to reinstall this kit. The installation procedure automatically checks the file dates and image identities and replaces obsolete versions. The CRT$STARTUP.COM file is executed as part of the installation procedure. If no additional warning messages appear, then the C/C++ components have been successfully restored to their proper versions. As a further check, you can verify that the files specified in the original warning MAIL message are contained in the components provided list during the reinstallation procedure. If the reinstallation does not work properly, or if startup verification mail messages continue to be received after reinstallation, then executing the reinstallation procedure has probably not provided one or more necessary components. You can investigate this issue by reading Section 1.3 and taking the appropriate actions. If these efforts do not resolve the messages, contact your Digital representative for further assistance. 13 1.3 Installation Validations and Checks Because this installation procedure provides components of OpenVMS to systems that are up and running, it is very careful to avoid disturbing existing, working applications. An extensive variety of validations is performed to ensure that the kit as a whole, and each component individually, can be safely installed without disturbance. The design philosophy of this kit is that it is generally safer to suppress providing a suspect component than to provide it improperly. This is because the remedy for failing to provide a necessary component is usually to supply it to the proper directory. However, a component provided incorrectly and a purge or other system disturbance often requires restoring files from the most recent system backup as the only recovery method. Given the wide variety of OpenVMS system configurations, the aggressive validation checks may fail to provide a needed component. In such a case, corrective action is generally possible by reinstalling this kit to provide the necessary component. To perform such a recovery effectively, you need to know exactly what kinds of checks and validations are performed by this kit, and how to determine when they will succeed and fail. The following list describes, in the order they are performed, each type of validation, what its purpose is, and how to modify the system configuration to allow the desired component to be installed properly on a followup installation attempt. Even if it only provides a subset of the desired components, each installation of this kit prints a list of which components are being provided by the current installation procedure. Examine this list carefully to ensure that the desired components are actually provided. o Minimum OpenVMS version check. The procedure includes a single check at the beginning to ensure that the installing system is running a minimal version of OpenVMS. The current version of the kit checks for OpenVMS Version 5.5. This ensures that the kit is not installed on systems for which Digital service does not support this kit. If this check fails, the installation is abandoned and no components are provided. To 14 continue, you should upgrade your OpenVMS system to the minimum version before attempting reinstallation. o Maximum OpenVMS version check. The procedure includes a single check at the beginning to ensure that the installing system is not running OpenVMS Version 6.1 or higher. This ensures that the kit is not installed on systems for which the components are part of the operating system. If this check fails, the installation is abandoned and no components are provided. o Component-wise, check for the required OpenVMS VAX version. As previously described, installation of different components are required on different OpenVMS versions. The kit saveset AACRT060.A contains a specification file defining which components are needed on which versions of OpenVMS. The installation procedure reads this specification file and checks (for each component) whether to provide that component on the installer's OpenVMS version. If you desire a specific component be installed, you should upgrade your system to a later version of OpenVMS where the component is either provided by the OpenVMS upgrade procedure or by this kit. o Check for components with a higher image identity. A check is made for selected components that are shareable image (.EXE) files. The procedure compares the image identification string on the system and kit versions of the file. If the identification strings are comparable, and the kit version of the file contains a lower version number, then that component file is not provided. In general, this means that the component has been superseded by a later version and the kit version is unnecessary. Unless this causes a problem with the dependent file check, no remedial action is generally required. o Check for newer component version. After a component passes the previous checks, the system is examined to see if a previous version of that component is already available on the system. If so, the installation procedure compares the file creation dates of the highest system version of the file against the kit version of the file. If the kit version is not newer, 15 that component is not provided. This means that, unless files are changed or deleted, subsequent installations of this kit will not provide the same components a second time. o Dependent file check. Some components on this kit reference or are referenced by other components. In such cases, installing a dependent component can be unsafe if a corresponding primary component is inhibited by one of the earlier checks previously described. Although a dependent component may install, it can create a version skew that causes unexpected failures at run time. To be safe, the component specification file (CRT$SPEC.DAT) identifies such dependencies and inhibits installation of dependent files if the corresponding primary file is inhibited for a reason other than OpenVMS version eligibility or file creation date and image identity. If installation of dependent files is inhibited, the installation procedure displays a message specifying which dependent component is being inhibited and which primary component is the cause of the inhibition. Such a message has the following form: %AACRT-W-NOPRV, (dependent-filespec) not provided because related component (primary-filespec) is not being provided. dependent-filespec Is the component file specification of the dependent file. primary-filespec Is the primary component whose noninstallation was the cause of this check failure. To overcome such a dependent file check, examine the primary-filespec given in the message against this list of validations (other than the OpenVMS eligibility validation). Correct the problem with the primary- filespec and reinstall. The dependent file should then be provided as expected. 16 o Block capacity check. As with most OpenVMS kits, the installation procedure checks to ensure that adequate free blocks are available on the target system disk to complete the installation successfully. This kit requests only enough blocks to install the components that pass all the validations previously described. If this check fails, the installation procedure issues an error message and stops; no components are provided. To correct this problem, make space on the system disk by deleting files or moving the system to a larger device and reinstall the kit. o Global Image Section and Global Pages check. As with most OpenVMS kits, the installation procedure assumes that you want to use the INSTALL utility to make the shareable image (.EXE) files into known files for fast image activation at run time. The installation procedure counts the number of image sections and pages required by the components that pass the previously described validations, and checks these numbers against the number of free image sections and pages available to the INSTALL utility. If amounts of either global sections or global pages are insufficient, the installation procedure issues an error message and stops; no components are provided. To correct this problem, see any OpenVMS installation guide for instructions on increasing the number of free global pages or sections; then reinstall the kit. 1.4 Impact on Software Development and Distribution The DEC C/C++ Run-Time Components kit contains shareable image run-time components. When the DEC C/C++ Run-Time Components kit is installed on OpenVMS VAX Version 5.5, 5.5-1, or 5.5-2 systems, some of the shareable image run- time components replace older versions of existing OpenVMS components. This makes the installation of the DEC C/C++ Run-Time Components kit similar to an OpenVMS upgrade for sites that develop or distribute software for OpenVMS VAX Version 5.5, 5.5-1, or 5.5-2 systems. Software linked against any of the run-time images provided by the DEC C /C++ Run-Time Components kit cannot be executed at sites having older versions of the files in their SYS$LIBRARY directories or at sites that do not have the new images available. 17 Specifically, when executing the image resulting from a software build procedure that links an application against any of the new run-time components provided on this kit, CMA$TIS_SHR.EXE, CXXL$O11_SHR.EXE, DECC$SHR.EXE, VAXCRTL.EXE or VAXCRTLG.EXE, a user at the installing site will encounter errors if that user subsequently copies the resulting image file to another site (target site) that is running OpenVMS VAX Version 5.5, 5.5-1, or 5.5-2 and does not have the new versions of the run-time components in their SYS$LIBRARY. For example, consider a software application, VAX APP- XYZ, which has been developed on a cluster named GRAPES::, that is running OpenVMS VAX Version 5.5. As part of the build of VAX APP-XYZ, an executable image named XYZ.EXE is linked against the VAX C Run-Time Library (RTL) (SYS$LIBRARY:VAXCRTL.EXE). VAX APP-XYZ has been built and distributed to other OpenVMS VAX sites that have a version of SYS$SYSTEM:VAXCRTL.EXE at least as recent as the one distributed with OpenVMS Version 5.5 and executes properly. However, if the system manager for the GRAPES:: cluster installs the DEC C/C++ Run-Time Components kit, one component of the kit is a new version of VAXCRTL.EXE (a more recent version than the version that exists in OpenVMS VAX Version 5.5-2). Installing the DEC C/C++ Run-Time Components kit places this newer version in SYS$LIBRARY. Subsequently, if the VAX APP-XYZ software developers execute their build procedure, the resulting version of XYZ.EXE will now depend on the new version of VAXCRTL.EXE rather than the old version. If an offsite client takes delivery of the new version of VAX APP-XYZ, users at the remote site will encounter image activation failure while trying to execute XYZ.EXE. The remote user's system issues the following message indicating that the necessary version of SYS$LIBRARY:VAXCRTL.EXE is absent: $ run xyz %DCL-W-ACTIMAGE, error activating image VAXCRTL -CLI-E-IMGNAME, image file SYS$LIBRARY:VAXCRTL.EXE;1 -SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image 18 This problem can arise when new components such as DECC$SHR.EXE (the DEC C Run-Time Library) or CXXL$011_ SHR.EXE (the DEC C++ Class Library) are linked against. It can also occur when existing components like VAXCRTL.EXE (as in this example) are used that have been replaced by newer versions from the DEC C/C++ Run-Time Components kit. Because the run-time components contained on the DEC C/C++ Run-Time Components kit are in common use, such problems can arise even for programs that do not use the DEC C++ compiler. _______________________ Warning _______________________ Any application that links directly or indirectly against a version of VAXCRTL.EXE, VAXCRTLG.EXE, CMA$RTL.EXE, CMA$OPEN_RTL.EXE, CMA$LIB_SHR.EXE, or CMA$OPEN_LIB_SHR.EXE is affected by this problem. A linkage is indirect if a shareable image that references any of these images is linked into the application. ______________________________________________________ For software developers who want to redistribute software that is developed using systems where the DEC C/C++ Run- Time Components kit is installed, the options are: o Link against older versions of the shareable images o Redistribute the DEC C/C++ Run-Time Components kit o Link with object libraries rather than shareable images These options are elaborated upon in Chapter 1 of the DEC C/C++ Run-Time Components for OpenVMS VAX Reference and Installation Guide. This guide is placed in the SYS$HELP directory as: CRT060_REF_INST.PS - postscript file CRT060_REF_INST.TXT - text file In addition, Chapter 1 has sections on: o Diagnosing if there will be a problem with the distribution of an application that has been linked on a system where the DEC C/C++ Run-Time Components has been installed 19 o Behaviors that will occur when an application has been linked against a component of the DEC C/C++ Run-Time Components kit and moved to a system where the kit has not been installed o The requirements for redistribution of the DEC C/C++ Run-Time Components kit 1.5 Interaction of Components with Other Digital Layered Products The installation of this kit interacts with some other Digital layered products in nonobvious ways. Products whose behavior may be modified are documented here. 1.5.1 POLYCENTER Network Manager V1.3 Once the DEC C/C++ Run-Time component kit has been installed on a system, POLYCENTER Network Manager Version 1.3 has the potential of generating the following warning: %MCC-E-WRONG_CMA, Current version of CMA is incompatible with DECmcc %TRACE-E-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC 000D092B 000D092B MCC_KERNEL_INIT MCC_KERNEL_INITIALIZE 152 00000011 0000598D 0000594A 0000594A Even when this warning is encountered, the resultant image will operate properly with the version of DECthreads that has been installed by the DEC C/C++ Run-Time component kit. 1.5.2 POSIX for OpenVMS VAX Version 1.2 After the DEC C/C++ Run-Time component kit has been installed on an OpenVMS VAX Versions 5.5, 5.5-1 or 5.5- 2 system, the POSIX for OpenVMS VAX Version 1.2 and DECthreads interoperability will be extended to be the same as is available on OpenVMS VAX Version 6.0. 2 DEC C RTL Version 6.0 Release Notes The C RTL shipping with the DEC C/C++ Run-Time Components Version 6.0 kit contains major new features and many bug fixes compared to the C RTL on OpenVMS VAX Version 5.5. The new C RTL is referred to as the DEC C RTL because it contains support for the DEC C and DEC C++ compilers. The DEC C RTL contains all the support for VAX C programs as well, and supersedes the VAX C RTL. 20 New features include ANSI C Standard conformance, DEC C++ support, C RTL reentrancy, DECthreads support, performance improvements, and many bug fixes. The DEC C RTL ships as part of OpenVMS VAX V6.0 and OpenVMS AXP Version 1.5. 2.1 Miscellaneous Problems Because of a bug in the UCX libraries, programs that use the UCX socket library cannot be linked with the DEC C RTL. To solve this problem, a new version of the file UCX$CRTLIBXFR.OBJ is provided by the DEC C/C++ Run-Time Components kit in the directory SYS$LIBRARY:. If you need to develop socket programs using the UCX TCP/IP library, you must execute the following command: $ library/replace/globals sys$library:ucx$ipc sys$library:ucx$crtlibxfr A LIB$INITIALIZE psect has been added to the VAXCRTL object libraries. When debugging programs linked against the DEC C RTL versions of the object libraries, you must enter GO before you can reach the main program; error tracebacks will have an additional call stack listed. In some versions of the DEC C RTL documentation, the memory allocation routines (malloc, calloc, and so forth) are documented as returning memory that is longword aligned. Actually, the memory returned is quadword aligned. The DEC C RTL help information is available as the topic RUN-TIME_FUNCTIONS in the DEC C++ help library. 2.2 DEC C RTL Performance Enhancements The performance of the DEC C RTL stream I/O is significantly better than the VAX C RTL (stream I/O is the default I/O type). The DEC C RTL uses a default block size of 16 compared to the VAX C RTL, which used a block size of 1. Note that programs that have a mbc= clause in their file open call can reduce default performance by specifying a mbc= value of less than 16. Record I/O performance has also been improved, but not to the same degree as stream I/O. 21 2.3 Behavior Differences Between the VAX and DEC C RTLs This section describes differences in behavior between the VAX C RTL and the DEC C RTL. Unless specifically mentioned otherwise, each difference was introduced because of the need to comply with the ANSI C Standard: o Exit handlers established by atexit() are not executed when abort() is called. o Files opened in append mode always have writes forced to End-of-File (EOF). With the VAX C RTL, the behavior of files opened in append mode was no different than for files opened in write mode. o A call to ungetc() clears the EOF flag for the file. o A call to a file position routine (for example, fseek()) clears the EOF flag for the file. o The EOF flag for a file is always cleared when the file is first opened. The VAX C RTL sets the EOF flag to true if the file opened was empty. o A call to a file position routine (for example, fseek()) now causes the character pushed back by a call to ungetc() to be lost. o The ANSI C Standard padding rules for the printf() routines are different than the VAX C RTL behavior. Table 2 shows examples of the new and old behavior. o The ANSI C Standard rules for the output of floating- point numbers is different from the VAX C RTL behavior, so that a digit of precision can be lost. Table 2 shows examples of the old and new behavior. o The ANSI C Standard requires that an empty precision value in a printf() format specifier be treated as a zero precision. The VAX C RTL ignored an empty precision value. Table 2 shows an example of the new behavior. 22 Table_2_Changes_in_printf()_Behavior_Required_by_ANSI______ Example_______________VAX_C_RTL________DEC_C_RTL___________ printf("%04.2d", 77 "0077" " 77" ) printf("%6.4d", 77 ) " 77" " 0077" printf("%.2g", "9.88e+02" "9.9e+02" 9.876e+2 ) printf("%-.s", "hello" "" "hello"_)__________________________________________________ o The C signal SIGABRT is now defined to be equal to the SIGIOT signal rather than to SIGILL as in the VAX C RTL. Programs that look for the exception SS$_OPCDEC in order to prevent an abort() from occurring will now fail (the exception is now SS$_OPCCUS). o Calling setvbuf() with a buffer smaller than 8192 bytes will result in the user's buffer not being used. This change occurred because of DEC C RTL performance improvements. o The gets() and fgets() functions no longer null- terminate the input buffer when EOF is encountered and no characters have been read since the last read operation. o The DEC C RTL I/O functions allow the writing of 0 length records. Passing a length of 0 to write() and fwrite() will now result in an empty record; the old VAX C RTL would do nothing. This change was as requested by users. o The signal() function now returns SIG_ERR on error. This should not affect the behavior of programs that check for -1. o If the parameter to fflush is NULL, then all buffers associated with all currently open files are flushed. o File positioning (for example, fseek()) is now allowed on files opened in append mode. o ftell() now reports a file position that takes into account the character pushed back by a call to ungetc(). 23 o The DEC C RTL will not accept uppercased versions of printf() and scanf() format specifiers. That is, the DEC C RTL will not accept %D as a format specifier but the VAX C RTL accepts %D as a synonym of %d. o The DEC C RTL allows file positioning calls to seek to an arbitrary byte with fixed-length record files. The VAX C RTL treats fixed-length record files like all record files and only allows file positioning to record boundaries. This change was requested by users. o The DEC C RTL BUFSIZ value is 8192; the VAX C RTL BUFSIZ is 512. Any program that links with the DEC C RTL and calls setbuf() with a pointer to a buffer of less than 8192 bytes in length will not execute properly because the DEC C RTL will write past the end of the buffer. This change occurred because of DEC C RTL performance improvements. o The ANSI C Standard defined behavior for negated scansets in the scanf function is different from the VAX C RTL behavior. The ANSI C Standard requires at least one character to match a negated scanset; the VAX C RTL allowed no characters to match. For example, the following code will fail if it encounters an empty line: /* read lines and throw away the newline */ fscanf("%[^\n]%*c", &string); The DEC C RTL requires the code to be implemented as follows: /* read lines and throw away the newline */ if (fscanf("%[^\n]%*c", &string) == 0 ) fscanf("%*c"); /* swallow blank-line newline */ 2.4 Linking with the DEC C RTL The DEC C RTL provides a new set of images with different names from the VAX C RTL images. If you want to link with the DEC C RTL, you will need to change your link procedures to use the new image names. The following sections describe linking with the DEC C RTL images. 24 2.4.1 Linking with DEC C RTL Shareable Images The DEC C RTL shareable image is called DECC$SHR.EXE. Users of the DEC C++ compiler will not have to do any extra work to link with this image, because the linker will find the image in IMAGELIB. If you are using the VAX C compiler and you want to link with DECC$SHR, you must link against a special set of shareable images. This is required because the VAX C compiler does not generate symbol references that are compatible with the DEC C RTL. The special object libraries are named VAXC2DECC.EXE and VAXCG2DECC.EXE. Use them in the same fashion as you use VAXCRTL.EXE and VAXCRTLG.EXE. For example: $ LINK PROG1, TT:/OPT SYS$SHARE:VAXC2DECC.EXE/SHARE ^Z These shareable images contain transfer vectors from the unprefixed names (for example, strcpy) produced by the VAX C compiler to the prefixed names (for example, decc$strcpy) contained in DECC$SHR.EXE. 2.4.2 Linking with DEC C RTL Object Libraries The DEC C RTL object libraries are named DECCRTL.OLB, DECCRTLG.OLB, and DECCCURSE.OLB. Use them in the same fashion as you use VAXCRTL.OLB, VAXCRTLG.OLB, and VAXCCURSE.OLB. For example: $! Link a D-float program $ LINK PROG1, SYS$LIBRARY:DECCRTL.OLB/LIB $! Link a G-float program $ LINK PROG2, TT:/OPT SYS$LIBRARY:DECCRTLG/LIB SYS$LIBRARY:DECCRTL/LIB ^Z The DEC C RTL object libraries contain the unprefixed entry points for modules compiled with VAX C, and the prefixed entry points for modules compiled with DEC C++. All types of modules may be linked together with the DEC C RTL object libraries. However, note that the behavior they will see is that of the DEC C RTL, as described in Section 2.3. 25 2.4.3 Linking with DEC C or VAX C RTL Object Libraries/NOSYSSHR If you want to link your program with either the DEC C or VAX C RTL object libraries /NOSYSSHR, you must specify /INCLUDE=CMA$TIS on the object library. Failure to do so will cause several symbols to be undefined and the resulting image will not execute. To add this qualifier, you must use a linker options file or list the DEC C or VAX C RTL object library on the command line. You cannot use the LNK$LIBRARY mechanism to link with the DEC C or VAX C RTL to add this qualifier. For example: $ LINK/NOSYSSHR PROG1, SYS$LIBRARY:DECCRTL.OLB/LIB/INCLUDE=CMA$TIS When linking against the VAX C RTL object libraries and not referencing any socket routine, please ignore any warning or informational messages relative to the undefined symbol LIB$FIND_IMAGE_SYMBOL. 2.5 DEC C RTL Obsolete Features The following routines are considered obsolete in the DEC C RTL and should not be used in new development. They will continue to be provided for VAX C RTL compatibility. The DEC C RTL versions of the standard C memory allocation routines are faster and more efficient compared to the VAX C RTL versions. o VAXC$CALLOC_OPT o VAXC$CFREE_OPT o VAXC$FREE_OPT o VAXC$MALLOC_OPT o VAXC$REALLOC_OPT The global symbols sys_nerr and sys_errlist are considered obsolete in the DEC C RTL and should not be used in new development. They will continue to be provided for VAX C RTL compatibility, but new error messages have not been added for a number of releases of the VAX C RTL. Digital recommends that programmers use perror() or strerror() instead. 26 2.6 DEC C RTL Interoperability Restrictions This section documents several interoperability restrictions that apply when multiple copies of the C RTL are used in the same process as part of running an application. The following are examples of this: o A single program is composed of modules created by both VAX C and DEC C++ and is linked in the default manner so that the VAX C modules call VAXCRTL.EXE and the C++ modules call DECC$SHR.EXE. o A program is linked with DECC$SHR.EXE (because it was created with DEC C++ or it was linked using VAXC2DECC.OLB), and also calls some shareable image that is linked with VAXCRTL.EXE, such as DECwindows, CDD, and so forth. o A program calls two different shareable images. One shareable image links with VAXCRTL.EXE and the other links with DECC$SHR.EXE. o A program calls two different shareable images. Each shareable image was linked with DECCRTL.OLB. o A program is linked with VAXCRTL.OLB and also calls some shareable image that is linked with VAXCRTL.OLB or DECCRTL.OLB. Most applications will work correctly with any mix of C RTLs in the same process. However, any shareable image that exchanges part of the C RTL context with its caller could lead to problems in an image that uses two C RTLs. An exporter of C RTL context is likely to be a programming library, a program that consists of multiple shareable images might also pass C RTL context between images. Exporting C RTL context between two C RTLs is unsupported by Digital. A shareable image that needs to pass C RTL context to its caller must ensure that the caller will be built with the same C RTL as the shareable image. C RTL context can never be passed between a C RTL object library and a C RTL shareable image, even if they are the same C RTL. 27 The following lists some data structures and information that is part of the C RTL context: o Dynamic memory areas allocated with the malloc function o File descriptors o File pointers o Global variables o errno o stdin o stdout o stderr o vfork context o setjmp context o Random number seed o signal context The following list describes some instances of exporting C RTL context. "Subsystem" refers to a shareable image that provides a set of routines to be called by the "caller," which is typically a main program or possibly another shareable image. If any of these occur in an application where a subsystem is linked with one C RTL, and the caller of that subsystem is linked with a different C RTL, then the application may not function correctly. o A subsystem that allocates memory with calls to malloc() and requires its caller to deallocate the memory at a later time by calling free() directly. Memory corruption or memory leakage is likely to occur as a result of such an operation. o A subsystem that opens a file and returns a file pointer for its callers to use by calling fprintf() directly. o A subsystem that reads a line from stdin and expects its caller to access the read data with calls to getc(). o A subsystem that expects its caller to provide a readable value in the errno global variable. 28 o A subsystem that calls vfork() and expects its callers to perform a corresponding exec() call. o Any attempt to exec() an image that was built with a different C RTL than the image that performed the exec() call. Possible symptoms of such an attempt would include no output produced by the child process, or a program that fails with a "bad file number" message. o A subsystem that expects output to the terminal to occur in a readable form when the caller is also performing output to the terminal. If a subsystem used by an application exports C RTL context, the only solution that ensures the application will run correctly is for the subsystem and the caller to use the same C RTL. For example, if the subsystem is linked with VAXCRTL.EXE, then the caller must also be linked with VAXCRTL.EXE. If the subsystem is linked with DECC$SHR.EXE, then the caller must also link with DECC$SHR.EXE. Note that any shareable image that does not export C RTL context will continue to function correctly with whatever version of the C RTL it is currently using. 2.7 Known Problems This section contains a list of known problems that have been reported against the DEC C RTL: o The VAXC$PATH logical does not work with execlp and execvp. o File output may not produce correct results if the process's file quota has been exceeded. o The malloc entry point is missing from the VAXCRTL* object libraries. o The getenv() function receives an access violation if the symbol being requested does not exist. o The printf() function receives an access violation if no virtual memory is available. o The chdir() function does not permanently change the default directory when the program is in executive mode. This functionality has not yet been implemented for OpenVMS AXP systems. 29 o The nice() function returns a success status when given an out-of-range priority value. o The nice() function does not support priority levels above 32. o The sbrk() function does not detect that no virtual memory is available. o The fcvt() function returns a NULL pointer when the number of fractional digits requested is 0. Use the following workaround: sprintf( buffer, "%.0f", data ); o The C RTL returns --HUGE_VAL from the exp() function for the overflow condition instead of HUGE_VAL. o A call to fgetname() with a null file name does not return the current device and directory. o The C RTL currently limits the number of simultaneously open files to 256. o The CPU time consumed by a system() call is not included in the time returned by the clock() and times() functions. o The C RTL currently does not set the longest record length value for a file that is created using stream I/O. o The parent process does not detect the disappearance of a child created with the vfork() function. o The C RTL hangs if a buffer larger than 65,535 bytes is passed to the setvbuf() function. 3 DEC C++ Class Library Version 1.1 Release Notes This kit provides the same version of the class library components that are provided with the DEC C++ Version 1.1 for OpenVMS VAX product. Following is an updated version of the original release notes for the DEC C++ Class Library. 30 4 DEC C++ Class Library Release Notes The DEC C++ Class Library is composed of the following packages: complex, generic, iostream, Messages, Objection, Stopwatch, String, task, and vector. These packages are documented in the DEC C++ Class Library Reference Manual. The DEC C++ Class Library also contains the cxxl (manifest declarations) package which is used by the implementation but does not export anything to the user name space. 4.1 Notes on All Packages o All other packages which display messages use the Messages package to retrieve the message text. The exact message text differs from that of other implementations. o Some packages which display messages use the Objection package to print the message text. o All functions which use double floating-point data are supplied in both forms, D_FLOAT and G_FLOAT. The correct function is automatically selected when you supply (or do not supply) the /G_FLOAT switch to the compiler. 4.2 Notes on the complex Package o The following functions have been added in the DEC C++ Class Library: arg1(const complex &) sqr(const complex &) tan(const complex &) tanh(const complex &) o In the DEC C++ Class Library, data members of the c_ exception class are public instead of private, so that they can be accessed by user-supplied error handlers. 4.3 Notes on the iostream Package o Anachronisms are generally not supported in this release. That is, there is no backward compatibility with AT&T releases before 2.0. However, because they continue to appear in examples in the C++ literature, selected anachronisms have been provided (on an unsupported basis) in a separate header file, 31 stream.hxx. They include the setbase manipulator and the functions oct, dec, hex, chr, str, and form. o As in other implementations, there are some undocumented protected data members. These may be absent, have different names, or contain different values with respect to other implementations. o Many functions have their parameters declared as const. This does not affect existing code but will simplify passing const data to these functions. o The function ostream::seekp(streamoff, ios::seek_dir) may work correctly only with Stream_LF format files. 4.4 Notes on the Messages Package o The Messages package provides an interface to message files. See the DEC C++ Class Library Reference Manual for details. See also the VMS System Services Reference Manual (the $GETMSG system service description) and the VMS Message Utility Manual for additional information on creating and using message files. Note that there are some parameters to the Messages class constructor and Messages::text function which are not used on OpenVMS (the message file name and message file location); they are required on other platforms. NULL may be supplied for these parameters on OpenVMS. 4.5 Notes on the String Package o The following functions are not included in the String class: firstX, lastX, is_empty, put, getX, unget, unputX, operator[], char_at, chunk, strcmp, and strchr. o The following function has been added in the DEC C++ Class Library: String::operator const char *() const o There is a memory leak in String::operator()(int, int). To extract a substring, cast the String object to type char * and then copy the desired characters. 32 4.6 Notes on the task Package o The task package is implemented on top of DECthreads. However, tasks are really coroutines and not threads. Parallelism is disabled for tasks, and interoperation of tasks and threads is not supported. o An improved version of DECthreads is automatically installed on the system when DEC C++ is installed, unless this version is already on the system. o Constructors for objects derived from class task must not be inlined. The compiler enforces this. o Shared stacks for tasks are not implemented; tasks are always created with dedicated stacks. o The DECthreads debugger is accessible through the function cxxl_call_thread_debug (global symbol CXXL$CXXL_CALL_THREAD_DEBUG) in module CXXL$FD_TASK_ TASK in the sharable image. Once in the DECthreads debugger, use the help command to find out about the other commands. For example: INFRNO$ cxx test_task_program.cxx/deb=all INFRNO$ link test_task_program.obj/exe/map/ful/deb INFRNO$ run/nodeb test_task_program The answer is 4 INFRNO$ run/deb test_task_program VAX DEBUG Version V6.0DS-004 %DEBUG-I-NOGLOBALS, some or all global symbols not accessible %DEBUG-I-INITIAL, language is C_PLUS_PLUS, module set to TEST_TASK_PROGRAM %DEBUG-I-NOTATMAIN, type GO to get to start of main program DBG> GO break at routine TEST_TASK_PROGRAM\main 8468: main() DBG> GO predefined break on THREADS event EXCEPTION_TERMINATED DBG> SET IMAGE CXXL$011_SHR DBG> SET MODULE CXXL$FD_TASK_TASK DBG> CALL CXXL$CXXL_CALL_THREAD_DEBUG DECthreads debug> thread 33 task id state hold pri substate thread_object %TASK 1 READY 12 Initial thread *%TASK 3 RUN 12 Term. by exc 00144B38 DECthreads debug> Exit value returned is 654828 DBG> GO The answer is 4 %DEBUG-I-EXITSTATUS, is '%SYSTEM-S-NORMAL, normal successful completion' DBG> Exit INFRNO$ Also, see the DECthreads release notes and documentation for more information. o The stack high water mark detection may not account for all space at the bottom of the stack or, if task::print or the task package's scheduler are not invoked, at the top of the stack. Stack overflow detection is done by checking a guard region added to the top of the stack. o The thread system's exception-handling mechanism may trap some errors (such as invalid memory address) and report them as exceptions. o The Interrupt_handler class in the task package provides an object-oriented interface to signals which is known to the task package's scheduler. When the first task is created, the thread system is initialized, and establishes a new signal handler for synchronous signals. It also establishes a new signal handler for asynchronous signals when sigwait is called. Whenever an Interrupt_handler object is created for a signal, the previous handler for that signal is saved. If the program subsequently establishes a new handler for that signal, the Interrupt_handler will not operate until the program reestablishes Interrupt_handler's signal handler (the function at the address returned to the program when the program called the signal function to take control of that signal). When the last Interrupt_handler object is destroyed for a signal, the signal handler which was in effect when the first Interrupt_handler object was created for that signal is restored. This is the DECthreads signal handler. 34 o If the function indicated by object::error_fct returns 0, the operation may not be retried if an infinite loop would occur. o If a program runs out of memory, it may not be possible to display the E_STORE message, "Can't allocate more memory." o For portability, the value passed to the exit function through sched::set_exit_status should not be anything other than 0 or EXIT_SUCCESS or EXIT_FAILURE (as defined in stdlib.h). o The exit status of a program using the task package may make it appear as if another error has also happened, due to the particular values assigned to the task package and OpenVMS error symbols. For example, a program encountering a histogram error (%CXXL-W-E_HISTO) will print that error's message and then will exit with $STATUS equal to 14, which appears as an additional access violation with an incorrect severity (%SYSTEM-?- ACCVIO). The exit status of a program using the task package is subject to change in a future release. The following problems with the task package have been fixed: 1. Internal class names now start with __ to keep them out of the user name space. 2. Internal handling of thread termination has been improved. 3. Thread package declarations are no longer exported by task.hxx. 4. The function sched::o_type is now public access. It still generates the E_SCHOBJ error to prevent creating objects of type sched instead of a type derived from sched. Classes derived from sched must define the o_type function to return an object type. 5. A closely related set of problems were fixed which allowed the functions task::cancel and sched::cancel to call the scheduler; which prevented a function from continuing execution after calling task::cancel on 35 itself; which did not allow the thread associated with a task to properly terminate if the task was waiting when it was cancelled; and which occasionally caused the run chain to become circular. 6. The constructor for the histogram class was fixed to always properly initialize the histogram data. Also, see the DECthreads release notes for changes which may affect programs that use the task package. 5 DEC C/C++ Run-Time Components Version 6.0 for OpenVMS VAX Installation Release Notes The DEC C/C++ Run-Time Components Version 6.0 for OpenVMS VAX kit contains bug fixes and enhancements to its installation files. 5.1 Bug Fixes This section contains a list of known problems that have been fixed in the DEC C/C++ Run-Time Components Version 6.0 for OpenVMS VAX kit installation files: o This kit allows the DEC C/C++ Run-Time Components Version 6.0 for OpenVMS VAX kit to install on OpenVMS /Japanese VAX systems. It will allow the DEC C/C++ Run-Time Components kit to install on Versions 5.5, 5.5-1, 5.5-2, and 6.0 of OpenVMS/Japanese VAX in the same manner as it would on the corresponding versions of OpenVMS VAX. On Version 6.0 of OpenVMS/Japanese VAX the DEC C++ Class libraries and C Run-Time Library interoperability tools will be installed if necessary. The kit will not install on an OpenVMS VAX nor OpenVMS /Japanese VAX Version 6.1 or higher system. In addition the kit will not install on an OpenVMS/Japanese VAX V5.5-2M system. o CRT$STARTUP.COM now allows each node starting up in a cluster to create its own version of check_id_ results.txt, the file used to hold the results of any installation problems. This will prevent more than two nodes in a cluster which start up at the same time from colliding in their use of this file. 36 o KITINSTAL.COM was corrected to check the last line of the control file for the DEC C/C++ Run Time Components installation kit for table parsing errors. Previously the next to last line was checked, allowing table parsing errors to be missed. o KITINSTAL.COM was also corrected to issue an error message when a table parsing error is encountered. Previously no error message was generated. o CRT$SPEC.DAT had its table entry for CMA$OPEN_LIB_ SHR.EXE corrected. 37