| Previous | Contents |
V8.3
The toascii function required by the X/Open specification had only a macro definition in <ctypes.h> .
This fix adds the
toascii
function, with an entry point in the DECC$SHR image.
5.9.3 64-Bit sigaction Problem Fixed
V8.3
Compile-time warnings resulted from using 64-bit pointers to the sigaction function.
This fix allows regular, long pointer (/POINTER=LONG), and short
pointer (/POINT=SHORT) compilations.
5.9.4 64-Bit Pointer Capability Added to Several Math Functions
V8.3
The following C RTL math functions can now pass 64-bit pointers when a user compiles with the /POINTER_SIZE qualifier:
frexp modf frexpf modff frexpl modfl |
V8.3
The C RTL malloc function accepts an unsigned int ( size_t ) as its parameter. The lib$vm_malloc action accepts a (positive) signed integer as its parameter.
Allocating 2 GB (0x80000000) did not allocate the proper amount of
memory and did not retun an error indication. A check is now added to
the
malloc
,
calloc
, and
realloc
functions for sizes equal to or greater than 2 GB that fail the call.
5.9.6 Memory Leak in exec* Fixed
V8.3
A memory leak in
exec
* is fixed.
5.9.7 Behavior of exit after a Failed execl Fixed
V8.3
The C RTL contains a fix for the problem in which a call to _exit after a failed execl really exits but should not.
In the OpenVMS implementation of vfork , a child process is not actually started as it is started on most UNIX systems. However, the C RTL creates some internal data structures intended to mimic child-process functionality (called the "child context").
A bug occurred whereby after a vfork while in the child context, a call to an exec function justifiably fails, then calls _exit . On UNIX systems, after the failed exec call, the child process continues to execute. A subsequent call to _exit terminates the child. In the OpenVMS implementation, after the failed exec call, the child context terminates. A subsequent call to _exit terminates the parent.
The C RTL fix is enabled by a feature logical switch, DECC$EXIT_AFTER_FAILED_EXEC. Enabling this feature logical allows the child context to continue execution.
With DECC$EXIT_AFTER_FAILED_EXEC disabled or not defined, the current
behavior remains the default.
5.9.8 confstr Enhancements
V8.3
To conform to the X/Open specification, the confstr function now allows a zero-length buffer to be passed in.
Also, confstr now supports the following three HP-UX symbolic constants, which are added to header file <unistd.h> :
_CS_MACHINE_IDENT
_CS_PARTITION_IDENT
_CS_MACHINE_SERIAL
V8.3
Previously, if a user called fopen (file, "wb+"), where file was a quoted DECNET specification and the remote file was absent, RMS reported a syntax error in the file specification instead of opening the file for update (creating a new version).
This problem is fixed in Version 8.3.
5.9.10 Possible File-Pointer-Locking Hang Condition
V8.3
OpenVMS Version 8.2 introduced file-pointer locking for multithreaded C programs ( flockfile and friends). The C RTL internally locks file pointers to conform to the X/Open specification.
A problem occurred in instances where file pointers were not unlocked on an error return during the preloading of data.
Users who experience this problem might see application hangs in multithreaded programs using file-pointer I/O. Analysis of the program state shows a deadlock of threads on TIS-recursive mutexes used to implement the file-pointer locks.
This problem is fixed in Version 8.3.
5.9.11 Backport Library No Longer Shipped
V8.3
Previously included with the compiler distribution kit was a C RTL
backport object library, which allowed developers on older versions of
OpenVMS to use the latest C RTL functions. This backport object library
is no longer being shipped.
5.9.12 Header File <time.h> Changes
V8.3
The following problem is fixed. Users who still experience this problem might have to recompile their application to see the corrected behavior.
The C RTL <time.h> header file defines the struct tm structure and the functions gmtime , localtime , gmtime_r , and localtime_r .
When the calling of one these functions and the application and the C RTL disagree about the size of struct tm , a user application can see data corruption or an access violation.
The tm structure has optional members for BSD extensions: tm_gmtoff and tm_zone . These are not defined in the ANSI or POSIX specifications or, for compatibility, with older compilations.
The previously mentioned functions have three different definitions in the C RTL:
The __UTCTZ_ prefixed functions expect to assign only the longer tm structure with the BSD extensions defined.
The problem occurs when the <time.h> header file and the C RTL do not agree on the number of structure members in struc tm . For example, the problem occurs with a C++ compilation using a compile-time macro implying _ANSI_C_SOURCE (such as _POSIX_C_SOURCE), which maps the listed C RTL functions using __UTC_ prefixes. The functions expect the shorter tm data structure, but the user program uses the longer tm structure definition. The copy-back of data from the function return tries to access data not allocated by the C RTL for the tm data members. This can result in unpredictable behavior, such as an unintended memory or access violation.
In OpenVMS Version 8.3, changes are made to
<time.h>
to make sure the C RTL selects the appropriate prefixing for the listed
functions.
5.9.13 Header File <time.h> Makes *_r Non-ANSI Functions Visible
V8.3
The C RTL functions ctime_r , gmtime_r , and localtime_r defined in the X/Open specification are not in the ISO/ANSI C standard and should not be visible when compiling only for ANSI compliance. Previously in the C RTL, they were visible.
This situation is fixed. Checks are added in the
<time.h>
header to make these functions visible only when not compiling for ANSI
compliance.
5.9.14 Header File <decc$types.h>: time_t int Declaration
V8.3
The time_t structure defined in the <decc$types.h> header file has been historically declared as unsigned long int on OpenVMS systems. UNIX platforms tend to declare it as a signed type, which can cause problems for ported programs on OpenVMS.
For UNIX compatibility, this fix uses a compile macro __SIGNED_INT_TIME_T to declare time_t as int .
The default remains
unsigned long int
for compatibility with older programs.
5.9.15 New DECC$SHRP.EXE Image
V8.3
OpenVMS installs a new shareable image DECC$SHRP.EXE to implement C RTL
functions requiring protected mode. This shareable image is installed
on all Alpha and Integrity processors and is invoked from either the
DECC$SHR.EXE or DECC$SHR_EV56.EXE shareable image.
5.9.16 Header File <wchar.h> and C++ %CXX-W-ENVIRSTKDIRTY Message
V8.3
The
<wchar.h>
header file is fixed to avoid the problem where the C++ Version 7.1
compiler can issue a %CXX-W-ENVIRSTKDIRTY warning when compiling with
the _XOPEN_SOURCE macro defined.
5.9.17 Header File <builtins.h> __CMP_SWAP* and _Interlocked* Visible to C++
V8.3
The compare and swap builtins (__CMP_SWAP* and _Interlocked*) in
<builtins.h>
did not include the OpenVMS Alpha C++ compiler. Because HP C++ Version
7.1 requires them, a change in conditional compilation now makes these
builtins visible.
5.9.18 Extra Parameters to fcntl Ignored
V8.3
Previously, calls to fcntl with a third-optional parameter when only two were expected (for commands not expecting a third parameter) returned errors.
This problem is fixed. Any unneeded third parameter is now ignored.
5.9.19 Problem with fwrite to stdout Fails with Large System MAXBUF
V8.3
Previously, using fwrite to stdout resulted in an error if the system's MAXBUF SYSGEN parameter was greater than or equal to 33278.
The following message might have been returned when using perror (as viewed by perror ) after the failing fwrite call:
Error writing output: : non-translatable vms error code: 0x186A4 %rms-f-rsz, invalid record size |
This problem is fixed.
5.9.20 Problem with Read/Write for Socket Transfers Greater Than 64K
V8.3
Support is added for socket transfers greater than 64K bytes for the following socket routines:
send recv read sendto recvfrom write sendmsg recvmsg |
V8.3
On OpenVMS I64 systems, the nanosleep function used to return an invalid status of -1 and set errno to EINTR (interrupted system call) when the function was correctly sleeping.
This problem is fixed.
5.9.22 Builtin __fci Added for I64 Systems
V8.3
The
<builtins.h>
header file is updated with the prototype for the new
__fci
builtin (a builtin for the
fc.i
instruction) now supported by the HP C compiler.
5.9.23 _FAST_TOUPPER Macro Added
V8.3
As of OpenVMS Version 8.3, to comply with the C99 ANSI standard and X/Open Specification, the _tolower and _toupper macros by default do not evaluate their parameter more than once. They simply call their respective tolower or toupper function. This avoids side effects (such as i++ or function calls) where the user can tell how many times an expression is evaluated.
To retain the older, optimized behavior of the
_tolower
and
_toupper
macros, compile with /DEFINE=_FAST_TOUPPER. Then, as in previous
releases, these macros optimize the call to avoid the overhead of a
run-time call. However, the macro's parameter is evaluated more than
once to determine how to calculate the result. this could create
unwanted side effects.
5.9.24 Call to atof("NaN") no Longer Gives Arithmetic Trap
V8.3
On OpenVMS Alpha Version 8.2 and higher, the following call to atof("NaN") gave an arithmetic trap:
d = atof("NaN");
%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000,
Fmask=00000002, summary=02, PC=FFFFFFFF80BB23D4, PS=0000001B
-SYSTEM-F-FLTINV, floating invalid operation, PC=FFFFFFFF80BB23D4,
PS=0000001B
|
This is fixed in OpenVMS Version 8.3. The arithmetic trap is no longer
generated.
5.9.25 No New Entries for DECC$*.OLB Object Libraries
V8.3
As of OpenVMS Alpha and I64 Version 8.2, no new entry points are being
added to the DECC$*.OLB object libraries. This means new C RTL entry
points do not get mapped through these libraries to prefixed entries.
For example, the new OpenVMS Version 8.3 entry point
crypt
, compiled with /PREFIX=NONE, does not get mapped from
crypt
to
decc$crypt
.
5.10 Calling Standard and Rotating Registers (I64 Only)
V8.3
This note supplements information in the HP OpenVMS Calling Standard.
The Calling Standard invocation context block (ICB) (see Table 4-16 in the HP OpenVMS Calling Standard) and mechanism vector (see Figure 8-7 and Table 8-6 in the HP OpenVMS Calling Standard) always record general, floating-point, and predicate registers as if the register rename base (CFM.rrb) and rotating size (CFM.sor) were both zero. That is, when rotating registers are in use, the effects of the rotation are ignored. This is also true of the register masks used by the LIB$I64_PUT_INVO_REGISTERS routine (see Section 4.8.3.13 in the HP OpenVMS Calling Standard), because these masks are defined in terms of fields in the ICB structure.
Previously, the supplemental access routines LIB$I64_GET_FR,
LIB$I64_SET_FR, LIB$I64_GET_GR and LIB$I64_SET_GR (see Section 4.8.4 in
the HP OpenVMS Calling Standard) improperly interpreted their
register number parameters without applying an adjustment for the
effects of the register rename base and rotating size registers. This
error is corrected.
5.11 Common Data Security Architecture (CDSA) Considerations
The following notes pertain to CDSA.
5.11.1 Secure Delivery
V8.3
Downloading of files over the Internet is becoming a requirement of OpenVMS customers who want to use this easy and convenient method to acquire software updates, but are wary of the security vulnerabilities. Secure Delivery makes use of public key and digital signature technology to implement a system that provides OpenVMS users with the ability to authenticate and validate the files they download from OpenVMS and third-party OpenVMS vendors.
Secure Delivery is fully functional with OpenVMS Version 8.3. For more
information, refer to the HP OpenVMS Version 8.3 New Features and Documentation Overview.
5.11.2 Installation and Initialization Considerations
V7.3-2
Installation of CDSA is done automatically when you install the operating system.
$ @SYS$STARTUP:CDSA$UPGRADE |
%PCSI-E-HRDREF, product CPQ AXPVMS CDSA V2.2 is referenced by DEC AXPVMS OPENVMS V8.3 -PCSI-E-HRDRF1, the two products are tightly bound by this software dependency |
Permanent Condition
The OpenVMS operating system has a number of special modes of operation designed to help you debug complex hardware and software problems. In general terms, these special modes enable an extra level of tracing, data recording, and consistency checking that is useful in identifying a failing hardware or software component. These modes of operation are controlled by several system parameters: MULTIPROCESSING, POOLCHECK, BUGCHECKFATAL, and SYSTEM_CHECK.
If you are using one of these special modes (for example, to debug a device driver or other complex application), under certain conditions, generally related to high I/O loads, it is possible to incur a CPUSPINWAIT bugcheck. Specifically, any privileged code that runs for extended periods of time while holding a spinlock can cause a CPU spinwait bugcheck. Spinlocks are used to delineate the entry and exit points for critical sections, and should not be held continuously, as can occur in this situation.
To prevent a CPUSPINWAIT bugcheck, either use the system default settings for these system parameters, or reduce the loading of the system.
If you have reason to change the default settings, you can reduce the
likelihood of encountering a problem by setting the SMP_LNGSPINWAIT
system parameter to a value of 9000000.
5.13 Delta/XDelta Debuggers
The following release notes pertain to the OpenVMS Delta and XDelta debuggers running on OpenVMS Alpha and I64 systems.
OpenVMS Debugger release notes are in Section 5.29.
5.13.1 XDELTA Register Display Consideration (I64 Only)
V8.2
XDELTA on OpenVMS I64 displays general, floating-point, and predicate
registers as if the register rename base (CFM.rrb) and the rotating
size (CFM.sor) are both zero. In other words, when rotating registers
are in use, the effects of the rotation are ignored. This condition
will be corrected in a future release. See Section 5.10 for additional
details.
5.14 File Applications: Corrections to Guide to OpenVMS File Applications
Permanent Correction
The following corrections will be made to the Guide to OpenVMS File Applications if this manual is revised in the future.
Permanent Condition
Quadword alignment has been added to the BLISS macros ($xxx_DECL) that can be used to allocate RMS user structures (for example, FAB, RAB). Alignment faults are costly to performance---especially as processors get faster. By implementing the alignment directly in the macros, a number of OpenVMS utilities and user applications written in BLISS that use these macros show improved performance.
The specific names of the macros are: $FAB_DECL, $NAM_DECL, $NAML_DECL, $RAB_DECL, $RAB64_DECL, $XABALL_DECL, $XABDAT_DECL, $XABFHC_DECL, $XABITM_DECL, $XABJNL_DECL, $XABKEY_DECL, $XABPRO_DECL, $XABRDT_DECL, $XABRU_DECL, $XABTRM_DECL, and $XABSUM_DECL.
The alignment added in the RMS macros might result in compiler warnings of conflicting alignment. Programs with compiler warnings should link and execute correctly. However, the minor source changes to eliminate the warnings are recommended.
If you use any of these macros in a BLISS application and the declaration includes the ALIGN attribute, the BLISS compiler issues a "conflicting or multiply specified attribute" warning. For example, the warning is issued for the following declaration: FAB: $FAB_DECL ALIGN(2). The compiler also issues this warning even if quadword alignment (ALIGN(3)) is specified. You should remove any explicit ALIGN attributes associated with these macros.
In addition, if any of these allocations is included in a PSECT that contains an explicit alignment that is in conflict with ALIGN(3) (that is, is lower than ALIGN(3)), the BLISS compiler issues an "align request negative or exceeds that of psect" warning. For example, the warning would be issued for the following declaration:
PSECT OWN = $OWN$ (..., ALIGN(2), ...)
OWN
FAB = $FAB_DECL, ...
|
If warnings on PSECT alignment are seen when recompiling a BLISS application, the correction is to increase the alignment of the PSECT to ALIGN(3) (or higher). In rare cases, applications may have assumptions on adjacency of data between PSECTs. Those assumptions could be broken in making this change. Therefore, check the code for such assumptions and make any necessary corrections.
While a number of OpenVMS utilities are written in BLISS, only a few warnings were generated in a full OpenVMS build. Changes in OpenVMS to eliminate warnings did not require other changes to correct assumptions. Based on this, few user applications likely will require modification.
| Previous | Next | Contents |