HPlogo HP C/HP-UX Release Notes for HP-UX 11.01: HP 9000 Computers > Chapter 4 Problem Descriptions and Fixes

Workarounds

» 

Technical documentation

Complete book in PDF

 » Table of Contents

The following are workaround solutions to previous problems with the HP C/ANSI C compiler:

  • In the 64-bit environment, using the +ESlit option with the +DA2.OW option results in an error message. The combination of these options tells the code generator to locate the const data in the readonly code segment so that it becomes an error in the 64-bit environment. In the 32-bit environment, however, this error occurs silently. The linker will only detect and display error information for this inconsistency on 64-bit addressing.

  • +Onomoveflops should always be used with the +FPZ and +FPI floating point options. +Onomoveflops prevents floating point instructions from being moved, and and replaces integer division by floating point multiply by the inverse.

  • If you intend to use GNU style variable argument macros in HP C, note that you can make the concatenation operator '##' prevent syntax errors from occurring when the variable argument comes in as empty (the null string). However, you can also insert whitespace to the left of the left operand of '##' to more accurately specify the intended left operand.

    For example, if you use

    #define foo(f, s...) printf(f, s)

    Then the macro "call"

    foo("Hello world.\n");

    results in the expansion

    printf("Hello world.\n",);

    (note the comma ",") causing a syntax error.

    GNU provides the following workaround for this kind of a situation. If you use:

    #define foo(f, s...) printf(f, ## s)

    If the variable parameter 's' is non-null, if for example, you use:

    foo("%s %d\n", "Cycles", "1024");

    the result is

    printf("%s %d\n", "Cycles", "1024");

    as the expansion as you would expect.

    However, if 's' is null, this erases the comma to the left of the '##' in the macro definition and resulting expansion is:

    printf("Hello world.\n");

    Note that the comma is gone.

    In order to get the same behavior in HP C, you must insert a space to the left of the comma to make it clear to the preprocessor that the comma is the left operand of the '##' operator. Thus your definition for the macro 'foo' is:

    #define foo(f, s...) printf(f , ## s)

    (Note the space to the left of the '##' operator in the macro definition.)

    If the space is not inserted, the left operand of the '##' operator is understood to be:

    printf(f,

    Because there is no parameter by that name for 'foo', it is erased.

  • When specifying declarations within code in the HP C/ANSI C compiler, do not expect the same behavior in HP aC++. For the example:

    for(int i = 0; i < j; i ++) int i;

    Note the lack of a new block opening for the "for" statement. The C++ compiler accepts this form, with warnings, but the C compiler does not. The difference in the way the stack is handled causes the difference in behavior.

    Previously, the C compiler did not emit the source file information for the global typedefs. To correct this, use -y option along with -g when debug info is generated. You can generate debug information by compiling with +Oobjdebug.

  • The +Olibcalls transformation in the HP C compiler has been changed so that the following information in the HP C/HP-UX Programmer's Guide is no longer valid:

    "Calls to setjmp() and longjmp() may be replaced by their equivalents _setjmp() and _longjmp(), which do not manipulate the process's signal mask."

    Note that all other tranformations of +Olibcalls are unaffected by this change.

© Hewlett-Packard Development Company, L.P.