HP aC++ A.03.85 Release Notes

HP aC++ Release Notes
Problem Descriptions and Fixes, and Known Limitations
Chapter 1 79
— Use of optimization levels greater than 0 with debugging options is not supported.
— Limitation when unloading shared libraries in 32-bit and 64-bit applications:
Normally, at program termination (exit) or at a call to shl_unload() or dlclose(),
all explicitly loaded libraries are closed automatically and static destructors are
executed at that time.
When a 32-bit and 64-bit application call shl_unload() or dlclose() and that causes
libCsup to be unloaded, it fails when it executes static destructors at program
termination. This causes a program abort. This happens because related code and
data of libCsup are no longer present. See defect JAGaa86491.
• HP aC++ does not support installation and execution on HP-UX 9.x, 10.00, and 10.01
systems.
• HP aC++ does not support large files (greater than 2 GB) with <iostream.h> or
<iostream>.
• Known limitations of exception handling features:
— Interoperability with setjmp/longjmp (undefined by the ISO/ANSI C++ international
standard) is unimplemented. Executing longjmp does not cause destructors to be run.
— If an unhandled exception is thrown during program initialization phase (that is,
before the main program begins execution) destructors for some constructed objects
may not run.
— Symbolic debugging information is not always emitted for objects which are not
directly referenced. For instance, if a pointer to an object is used but no fields are ever
referenced, then HP aC++ only emits symbolic debug information for the pointer type
and not for the type of object that the pointer points to.
For instance, use of Widget * only emits debug information for the pointer type
Widget * and not for Widget. To generate such information, create an extra source
file which defines a dummy function that has a parameter of that type (Widget) and
link it into the executable program.
• Known limitations of signal handling features:
— Throwing an exception from a signal handler is not supported, since a signal can occur
at any place, including optimized regions of code in which the values of destructible
objects are temporarily held in registers. Exception handling depends on destructible
objects being up-to-date in memory, but this condition is only guaranteed at call sites.
— Issuing a longjmp in a signal handler is not recommended for the same reason that
throwing an exception is not supported. The signal handler interrupts processing of
the code resulting in undefined data structures with unpredictable results.