Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP Integrity Servers: HP aC++/HP ANSI C Release Notes > Chapter 5 Known Problems and Workarounds

Known Limitations

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Index

The following is a list of known limitations for this release. Some of these limitations will be removed in future releases of HP aC++. Please be aware that some of these limitations are platform-specific.

  • HP aC++ does not support large files (files greater than 2 GB) with <iostream.h> or <iostream>

  • 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. If you wish such information, you can 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 exception handling features:

    • Interoperability with setjmp/longjmp (undefined by the ISO/ANSI C++ international standard) is unimplemented. Executing longjmp does not cause any 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.

    • HP aC++ does not support the linker option -Bsymbolic. Use the compile time option -Bprotected_def if you want to throw types out of a shared library. This limitation also occurs for dynamic_cast and RTTI.

  • Known limitations of signal handling features:

    • Throwing an exception from a signal handler is not supported, since a signal can occur anyplace, including optimized regions of code in which the values of destructible objects are temporarily held in registers. Exception handling depends on destructible object 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.

  • Source-level debugging of C++ shared libraries is supported. However, there are limitations related to debugging C++ shared libraries, generally associated with classes whose member functions are declared in a shared library, and that have objects declared outside the shared library where the class is defined. Refer to the appropriate release notes and manuals for the operating system and debugger you are using. Refer also to the Software Status Bulletin for additional details.

  • Instantiation of shared objects with virtual functions in shared memory is not supported.

  • Using shl_load(3X) or dlopen(3C) with Library-Level Versioning:

    Once library-level versioning is used, calls to shl_load() or dlopen() (see shl_load(3X)) should specify the actual version of the library that is to be loaded.

    For example, if libA.so is now a symbolic link to libA.so.1, then calls to dynamically load this library should specify the latest version available when the application is compiled, such as:

    shl_load("libA.so.1", BIND_DEFERRED, 0);

    This will insure that, when the application is migrated to a system that has a later version of libA available, the actual version desired is the one that is dynamically loaded.

  • Memory Allocation Routine alloca()

    The compiler supports the built in function, alloca, defined in the /usr/include/alloca.h header file. The implementation of the alloca() routine is system dependent, and its use is not encouraged.

    alloca() is a memory allocation routine similar to malloc() (see malloc(3C)). The syntax is:

    void *alloca(size_t <size>);

    alloca() allocates space from the stack of the caller for a block of at least <size> bytes, but does not initialize the space. The space is automatically freed when the calling routine exits.

    NOTE: Memory returned by alloca() is not related to memory allocated by other memory allocation functions. Behavior of addresses returned by alloca() as parameters to other memory functions is undefined.

    To use this function, you must use the <alloca.h> header file.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2008 Hewlett-Packard Development Company, L.P.