HP OpenVMS Systems

• The command line switch /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.
  
• New builtins for DEC C on OpenVMS/VAX
  Four new builtins (_HALT, _MFTR, _MTPR, _READ_GPR) are now supported by DEC C for OpenVMS VAX for use by privileged applications. These builtins were adapted from the VAX C builtins by the same name, and generally work the same as the VAX C builtins. As with the other builtins on DEC C for VAX, they are used in conjuction with the header file builtins.h, which describes their interfaces. _READ_GPR is unprivileged. The other three will all generate a reserved opcode fault if executed in a mode other than Kernel.
• #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++. Like the other pragmas with save/restore options, the state of this pragma is also controlled by #pragma environment.
  Note there is one known limitation with this feature: If a function is implicitly declared (ie, no prototype) then it does not get prefixed.
• 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) 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.
  This feature is primarily for compatibility with the DEC C and DEC C++ compilers for Alpha, where the addition of features to select 32-bit or 64-bit pointers has created a demand for a mechanism to address the short-term problem of automatically establishing a system-default compilation environment for the processing of system header files without having to edit all such files (which come from a number of different sources). The introduction of #pragma environment in V5.0 simplified the process of establishing a known compilation environment for an individual header file, which would not be changed by (and would not change) the environment of other header files or the main source file, without having to list explicitly each pragma implemented in the particular compiler version of interest. But that mechanism requires editing each header file needing to have that kind of stable compilation environment. The implicit processing of prologue/epilogue files is intended to support a prologue file containing "#pragma environment save" followed by one or more pragmas to establish the desired environment (typically either "#pragma environment header_defaults" or "#pragma environment command_line"), and an epilogue file containing "#pragma environment restore". By copying these two specially-named files or modules to a directory or text library, all of the header files or modules in that directory or library can be made to have the same compilation environment independent of command line switches and enclosing files or modules.

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.

• 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
  <dirent.h>	Directory Manipulation Functions
  <ftw.h>	File Tree Walking
  <if.h>	Socket Packet Transport Mechanism
  <if_arp.h>	Socket Address Resolution Protocol
  <ioctl.h>	I/O Controls for Special Files
  <iso646.h>	Alternative Spelling for Language Tokens
  <libgen.h>	Filename Manipulation
  <memory.h>	String Handling
  <mman.h>	Mapping Pages of Memory
  <nameser.h>	Maximum Domain Name Size
  <pwd.h>	Password File Access Functions
  <resolv.h>	Resolver Configuration File
  <resource.h>	Declarations for Resource Operations
  <strings.h>	String Handling
  <timers.h>	Clock and Timer Functions
  <times.h>	File Access and Modifications Times Structure
  <tzfile.h>	Time Zone Information
  <utsname.h>	User Information
  <wait.h>	Declarations for Process Waiting
  <wctype.h>	Wide Character Classification and Mapping

• 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.

  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.)

  _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.
• 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.
• 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.
• Upgrade to Support 4.4BSD Sockets
  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 <socket.h>.
• 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 <time.h>. 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.
• 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.
• 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.

• FILE Structure Changed to Increase Open File Limit
  Changes were made to the FILE type definition in <stdio.h> 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 FILE type definition which link on earlier OpenVMS versions obviously not be able to make use of this new functionality.
• Header <stdlib.h> No Longer Includes <types.h>
  As part of feature test macro work, <stdlib.h> no longer includes <types.h>. 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 <types.h>.

• Change to the documentation 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.
  
• 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 message identifiers from previous releases. 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:
  
  • 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:
    
    • Generation of whitespace to separate tokens only where necessary to prevent accidental token pasting when the .I file is compiled.
    • Generation of # num directives and blank lines to keep a better correspondence to the original source.
    • 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.
    • #pragma message, standard, and nostandard are now also respected under /preprocess_only, so that spurious diagnostics are not produced when making a .I file.
  • Token pasting
    More natural treatment of token-pasting operators that do not produce valid tokens: the pasting is simply ignored.
  • Preprocessing directives within macro invocations
    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.
  • 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.
  • 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.
  • 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.
  • Macro expansions in #pragma
    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 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.
    
    • _KAP
    • standard
    • nostandard
    • member_alignment
    • nomember_alignment
    • dictionary
    • inline
    • noinline
    • module
    • message
    • extern_model
    • builtins
    • linkage (Alpha-only)
    • use_linkage (Alpha-only)
    • define_template (C++ only)
  
  
• #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.
  
• __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 dereference, without making it apply to all dereferences. This qualifier is provided on OpenVMS VAX only for compatibility with the Alpha platforms. On OpenVMS VAX it is parsed but, has no effect upon code generation. However, it is fully functional on OpenVMS Alpha and Digital UNIX.
  
• New Predefined Macros
  There are two 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. However, newer versions of the compiler and VMS will always have larger values for these macros. If the VMS version string or the compiler's ident string can not be obtained (or analyzed), then the corresponding macro will be defined with the value zero. Please note that pre-5.0 compilers do not define these macros so it is useful to surround any version tests with #ifdef tests.
  

  /*__DECC_VER is not defined before V5.0 to test for a the compiler V5.1 or higher */ #ifdef __DECC_VER #if (__DECC_VER >= 50100000) / *Code */ #endif #endif /* to test for VMS 6.2 or higher */ #ifdef __VMS_VER #if __VMS_VER >= 60200000 /* code */ #endif #endif

  
  Defining __VMS_VER to 60100000 (or lower) is useful if you wish to build your application on VMS 6.2 or higher and link your application with pre-6.2 libraries so that the application can be run by customers running pre6.2 systems. If you define __VMS_VER, you may want to compile with the command line option /WARNINGS=DISABLE= MACROREDEF to suppress that warning message.
  
• Compile Time Performance Improvements
  Some compile-time improvements have been made for V5.0. The most notable improvement is that the preprocessor is now sometimes able to determine that a particular #include file has already been processed once, if the contents were guarded by a #ifndef FILE_SEEN, #define FILE_SEEN sequence, and if the FILE_SEEN macro is still defined. When the compiler detects this case, that include file will not be reopened and reread.
  
• 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's UNIX.
  
• /NESTED_INCLUDE_DIRECTORY=(PRIMARY_FILE, INCLUDE_FILE, NONE) has been extended.
  It now accepts 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 including file nor in the directory containing the top level source file.

  ---

  Previous

  Next

  Contents