B.39 The ## Operator (§3.8.3.3)

The ## operator within a macro replacement list causes the two tokens on either side of the operator to be concatenated into a single token.

In common C and VAX C compatibility mode, comments can also concatenate two tokens because in these modes a comment is replaced by a null string after macro invocations.

This behavior is not supported in strict ANSI or default mode, where comments are replaced with a single space.

B.40 Error Directive (§3.8.5)

The #error directive causes an error message to be issued and the compilation to cease.

B.41 Pragma Directive (§3.8.6)

The Standard's approved method of adding extensions to the language is through the addition of pragmas. All unrecognized pragmas are diagnosed with an informational message. Supported pragmas vary across platforms. See your platform-specific HP C documentation for more information.

When only preprocessing a file, all pragmas recognized by HP C are written unaltered to the output.

B.42 Function Inline Expansion

Function inline expansion eliminates procedure-call overhead and allows general optimization methods to apply across the expanded code. Function inlining has advantages over macros in that arguments are evaluated only once, parentheses need not be overused to avoid problems with precedence, and the actual expansion can be controlled from the command line.

The following pragmas are provided to control function inline expansion:

#pragma inline (function_name [,function_name....]) #pragma noinline (function_name [,function_name....])

If a function is named in an inline directive, calls to it are expanded as inline code, if the function has the following properties:

• If a function is named in a noinline directive, calls to it are not expanded as inline code.
• If a function is not named in an inline or a noinline directive, the compiler uses a heuristic to perform inline expansion of calls where appropriate.
• The compiler issues an error if a function is named in both an inline and a noinline directive.
  If the noinline compiler option is used, it overrides all inline pragma directives.

Inline functions have the following properties:

• An inline function can be recursive, but only one level of inline expansion is performed if it is.
• Only calls from the source file containing the definition of the inlined function are expanded inline.
• The address of an inline function can be taken and expressions that imply the conversion of the inlined function name to an address are allowed.
• The use of the varargs package (allowing a function to take a variable number of arguments) is not allowed for inline functions.
• An inline function cannot be declared with an ellipsis in its argument list.

B.43 Linkage Pragmas

HP C supports the #pragma linkage and #pragma use_linkage preprocessor directives on OpenVMS Alpha systems.

These pragmas are used for defining special linkage characteristics and to associate these linkage characteristics with functions. See your platform-specific HP C documentation for more information.

B.44 Other Pragmas

The following pragmas are provided for VAX C compatibility mode only:

#pragma dictionary CDD_path #pragma module title ident

These pragmas correspond to the #dictionary and #module directives, respectively.

See your platform-specific HP C documentation for additional pragmas supported on your system.

Figure C-1 shows the ASCII character set. Each character's octal, decimal, and hexadecimal value is shown.

Figure C-1 ASCII Equivalence Chart

HP C supports several common C (old-style C) extensions to ANSI-standard C. These extensions are recognized only when the common C compatibility option is used on the compiler command line. The common C extensions allow you to use the c89 compiler to compile code originally written for the portable C compiler (pcc).

The following sections describe the common C extensions available with the common C compatibility option. Extensions to the ANSI-standard C language are divided into two categories:

• Extensions compatible with ANSI C programs that produce diagnostic messages when compiled without the common C compatibility option
• Extensions incompatible with ANSI C programs, which could produce different compiler behavior when used without the common C compatibility option

D.1 Extensions Compatible with ANSI C

• Relaxed pointer and pointer/integer compatibility is allowed. That is, all pointer and integer types are compatible, and pointer types are compatible with each other regardless of the type of object they point to. Therefore, under the common C option, a pointer to float is compatible with a pointer to int.
• The digits 8 and 9 are valid in octal integer constants. (A warning message is issued by the compiler, however.)
• Bit-field data types may include enum, short, char, and long. The ANSI C Standard allows only int, unsigned int, or signed int.
• long float is recognized as a synonym for double.
• A third argument to the function main(), namely char *envp[], is allowed. ¹
  When HP C is run in common C compatibility mode, the main function can accept a third parameter, the environment array envp. This array contains process information such as the user name and controlling information, and has no bearing on passing command-line arguments. Its primary use is during exec and getenv library function calls.
  See your platform-specific HP C documentation for more information about invoking the main function within your host environment.
• Text is allowed following the preprocessing directives #else and #endif.
• Address constants may be cast to int.
• Tentative definitions that exist at the completion of a compilation remain tentative to the linker, in accordance with the traditional model of definition resolution.
• Casts that do not cause a change in representation are legal as lvalues.
• Implicit function declarations are created at file level, rather than at block level.
• The types int and long are compatible.
• Taking the address of a variable with the register storage class is allowed.
• Block-level declarations of functions with static storage class are allowed.
• In array types, the element types are allowed to be incomplete.
• The type of a tentatively-defined variable is allowed to be incomplete at the end of the compilation unit. A warning is issued for this case.
• Values in case labels are allowed to have a pointer type.
• Trailing (extra) commas are allowed in enumeration lists.
• The semicolon following the last structure or union member may be omitted.
• Carriage returns are accepted and treated as white space.

D.2 Extensions Incompatible with ANSI C

• Unsigned preserving rules apply. (unsigned char and unsigned short promote to unsigned int.)
• Comments are converted to no spaces instead of a single space to allow token concatenation. (The compiler attempts to concatenate the two adjacent tokens.)
• All extern objects have file scope.
• Macro parameters are recognized and replaced within string or character constants in the macro definition.
• During macro replacement, an argument's preprocessing tokens are not macro replaced before the macro is expanded.
  If the name of a macro being replaced is found during the rescan of the replacement list, it is macro replaced.
• Support for predefined macro names that do not conform to the ANSI C Standard (that is, that do not start with two underscores or an underscore followed by a capital letter).
• A preprocessor directive is only recognized as such if the beginning # character occurs in the first column of a line. Any preprocessor directives preceded by white space are ignored.
• #ifdef is treated as "#if defined"
• #ifndef is treated as "#if !defined"
• Comments in macro replacement lists behave like ## operators when a valid token results after concatenation, except that adjoining white space is not deleted. If the resulting token is not valid, the comment in a macro replacement is deleted.
• Trigraphs are not recognized and replaced.

HP C supports several VAX C extensions to ANSI-standard C. These extensions are recognized only when the VAX C compatibility option is used on the compiler command line. The VAX C extensions allow you to use the HP C compiler to compile code originally written for the VAX C compiler.

The following sections describe the VAX C extensions available with the VAX C compatibility option. Extensions to the ANSI-standard C language are divided into two categories:

• Extensions compatible with ANSI C programs that produce diagnostic messages when compiled without the VAX C compatibility option
• Extensions incompatible with ANSI C programs, which could produce different compiler behavior when used without the VAX C compatibility option

E.1 Extensions Compatible with ANSI C

• VAX C specific pragmas are recognized.
• Relaxed pointer and pointer/integer compatibility is allowed. That is, all pointer and integer types are compatible, and pointer types are compatible with each other regardless of the type of object they point to. Therefore, under the VAX C option, a pointer to float is compatible with a pointer to int.
• The #module directive is allowed. (On Tru64 UNIX systems this directive produces a warning message and is ignored.)
• The #dictionary directive is allowed. (On Tru64 UNIX systems this directive produces a warning message and is ignored.)
• The module form of #include is allowed. (On Tru64 UNIX systems the module form of this directive produces an error.)
• Specifying int for the type of a bit field is equivalent to specifying signed int in VAX C mode.
• Built-in functions are recognized.
• The main_program option may be used to identify a particular function as the main function for a given program.
  When compiling in VAX C mode, another way to specify the main function in a program is to include the following option in the function definition:

  main_program

  
  This option is not a keyword, and it can be written uppercase or lowercase. The main_program option is useful for allowing a name other than main for the main program.
  In a prototype-style function definition, include main_program between the function declaration part and the left brace, as in the following example:

  char lower(int c_up) main_program { . . . }

  
  In an old-style function definition, include main_program in the same place as in the prototype style, but before any parameter declarations, as in the following example:

  char lower(c_up) main_program int c_up; { . . . }

  
  Both examples establish the function lower as the main function; execution begins there, regardless of the order in which the functions are linked.

• Bit-field data types may include enum, short, char, and long. The ANSI C standard allows only int, unsigned int, or signed int.
• The last member of a structure may be an array with no size specified.
• Two struct types or two union types are considered the same type if their sizes are the same.
• Block-level declarations of functions with static storage class are allowed.
• The address of a constant may be passed to a function.
• Taking the address of a variable with register storage class is allowed.
• A third argument to the function main(), namely char *envp[], is allowed.
  When HP C is run in VAX C compatibility mode, the main function can accept a third parameter, the environment array envp. This array contains process information such as the user name and controlling information, and has no bearing on passing command-line arguments. Its primary use is during exec and getenv library function calls. ¹
  See your platform-specific HP C documentation for more information about invoking the main function within your host environment.
• long float is recognized as a synonym for double.
• Character constants containing multiple characters are packed in little endian order. For example, 'AB' is treated as 'B' << 8 + 'A' instead of 'A' << 8 + 'B'.
• Trailing (extra) commas are allowed in enumeration lists.
• The element type of an array may be incomplete.
• Carriage returns are accepted and treated as white space.

E.2 Extensions Incompatible with ANSI C

• Unsigned preserving rules apply. (unsigned char and unsigned short promote to unsigned int.)
• VAX C-specific predefined macros are recognized.
• VAX C-specific keywords are recognized.
• Macro parameters are recognized and are replaced as string or character constants in the macro definition.
• Comments are converted to no spaces instead of a single space to allow token concatenation. (The compiler attempts to concatenate the two adjacent tokens.)
• Comments in macro replacement lists behave like ## operators when a valid token results after concatenation, except that adjoining white space is not deleted. If the resulting token is not valid, the comment in a macro replacement is deleted.
• Trigraphs are not recognized or replaced.
• Variant structures and unions are allowed.
  Variant structure and union declarations allow reference to members of nested aggregates without having to refer to intermediate structure or union identifiers. When a variant structure or union declaration is nested within another structure or union declaration, the enclosed variant aggregate ceases to exist as a separate aggregate, and HP C copies its members to the enclosing aggregate.
  Variant structures and unions are declared using the variant_struct and variant_union keywords. The format of these declarations is the same as that for regular structures or unions, with the following exceptions:
  • Variant aggregates must be nested within other valid structure or union declarations.
  • A tag cannot be used in a variant aggregate declaration.
  • At least one member must be declared in the variant aggregate declaration, and it may not be declared as a pointer or an array.
  
  Initialization of a variant structure or union is the same as that of a normal structure or union.
  With the VAX C compatibility option, two structures or unions in an assignment operation need only have the same size, rather than requiring the same members and member types.
  The following example shows the format of a variable structure declaration, and how to reference members of a variant structure:

  #include <stdio.h> enum packet_type {TEXT, INTEGER}; /* This structure can contain either a text_packet or an integer value. It can only contain one of these at a time, since they share the same storage. */ struct packet { enum packet_type type; variant_union { variant_struct { int str_size; char *text; } text_packet; variant_struct { int value; } value_packet; } text_or_int; } packet = {TEXT, 24 ,"I love the color purple"}; main() { if (packet.type == TEXT) printf(" %s. \n",packet.text); else printf(" %d \n", packet.value); packet.type = INTEGER; packet.value = 42; printf(" The meaning of life, the universe, and everything is: %d. \n", packet.value); }