Jump to 
content
HP.com Home Products and Services Support and Drivers Solutions How to Buy
»  Contact HP

 

HP C

HP C
Language Reference Manual


Previous Contents Index

B.19 Structure and Union Members (§3.3.2.3)

The result of accessing a union member different than the member holding a value depends on the data types of the members and their alignment within the union.

B.20 The sizeof Operator (§3.3.3.4)

The type of the sizeof operator is size_t . HP C defines this type, which is the type of integer required to hold the maximum size of an array, in the <stddef.h> header as unsigned int .

B.21 Cast Operators (§3.3.4)

The Standard specifies that a pointer can be converted to an integral type, but the size of the integer required and the result are implementation-defined. A pointer occupies the same amount of storage as objects of type int or long (or their unsigned equivalents). Therefore, a pointer can be converted to any of these integer types and back again without changing its value. No scaling takes place, and the representation of the value does not change.

Converting between a pointer and a shorter integer type, such as char , is similar to the conversion between an object of unsigned long type and a shorted integer type. The high-order bits of the pointer are discarded. Converting between a shorter integer and a pointer is similar to the conversion between the shorter integer type and unsigned long . The high-order bits of the pointer are filled with copies of the sign bit if the shorter integer type was signed. Messages are issued for cast operations of these types under the error-checking compiler option.

B.22 Multiplicative Operators (§3.3.5)

The Standard does not provide portable semantics for the division and remainder operators. HP C follows these semantics:

  • If either operand of the division operator (/) is negative, the result is truncated toward zero (the largest integer of lesser magnitude than the algebraic quotient)
  • If either operand of the remainder operator (%) is negative, the sign of the result is the same as the sign of the first operand (for common C, MIPS C, and VAX C compatibility)

The compiler issues a warning in the following cases of undefined behavior detected at compile time:

  • Integer overflow
  • Division by zero
  • Remainder by zero

B.23 Additive Operators (§3.3.6)

Pointers to members of the same array can be subtracted. The result is the number of elements between the two array members. The type of the result is ptrdiff_t . HP C defines this type as int .

B.24 Bitwise Shift Operators (§3.3.7)

The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has a signed type, the value of the result is the shifted value of E1 with the vacated high-order bits filled with a copy of E1 's sign bit (arithmetic shift).

B.25 Storage-Class Specifiers (§3.5.1)

The register storage-class specifier suggests that access to the object be as fast as possible. Specifying register is intended to give a variable an increased probability of being stored in a register. However, compiler register allocation techniques make using the register keyword obsolete. That is, HP C accepts and ignores all register requests.

B.26 Type Specifiers (§3.5.2)

The combination long float is supported as a synonym for double for compatibility with common C and VAX C. This combination results in a warning if compiled with the default mode or the strict ANSI mode.

B.27 Structure and Union Specifiers (§3.5.2.1)

The high-order bit position of an int bit field is not treated as a sign bit, except in the VAX C compatibility mode. In other words, the type int designates the same type as unsigned int for all bit-field types. In VAX C mode, the type int designates the same type as signed int for all bit-field types.

B.28 Variant Structures and Unions

Variant structures and unions are VAX C extensions that allow nested structures and unions to be declared as members of the enclosing aggregate. This eliminates the need to specify an intermediate qualifier when referring to those members. These capabilities are only available in VAX C mode.

Your platform-specific HP C documentation contains details about these extensions.

B.29 Structure Alignment

The alignment and size of a structure is affected by the alignment requirements and sizes of the structure components for each platform. A structure can begin on any byte boundary and occupy any integral number of bytes. However, individual architectures or operating systems can specify particular default alignment and padding requirements, which can be overridden by pragmas and command-line options.

OpenVMS Alpha and Tru64 UNIX

On OpenVMS Alpha and Tru64 UNIX systems, nonbit-field structure members are, by default, aligned on natural boundaries.

The default alignment of a structure is the maximum alignment required by any member within the structure. The structure is padded to ensure that the size of a structure, in bytes, is a multiple of its alignment requirement to achieve the appropriate alignment when the structure or union is a member of an array.

The components of a structure are laid out in memory in the order they are declared. The first component has the same address as the entire structure. Padding is introduced between components to satisfy the alignment requirements of individual components.

A bit field can have any integral type. However, the compiler issues a warning with the error-checking option if the type is anything other than int , unsigned int , or signed int . The presence of bit fields causes the alignment of the whole structure or union to be at least the same as that of the bit field's base type.

Bit fields (including zero-length bit fields) not immediately declared following other bit fields have the alignment requirement imposed by their base type. Bit fields are allocated within the alignment unit (of the same size as the bit field's base type) from low-order to high-order.

With #pragma member_alignment in effect, if a bit field immediately follows another bit field, the bits are packed into adjacent space in the same unit, if sufficient space remains. Otherwise, padding is inserted at the end of the first bit field and the second bit field is put into the next unit.

With #pragma nomember_alignment in effect, bit fields are allowed to span storage unit boundaries. Alpha systems default to member_alignment while VAX systems default to nomember_alignment .

Bit fields of base type char cannot be larger than 8 bits. Bit fields of base type short cannot be larger than 16 bits.

OpenVMS VAX

OpenVMS VAX systems do not require that structures or structure members be aligned on any particular boundaries; nonbit-field structure members are byte-aligned by default.

The components of a structure are laid out in memory in the order they are declared. The first component has the same address as the entire structure. Each additional component follows its predecessor in the immediately following byte.

Natural alignment of structure members, can be obtained by using the following pragma:


pragma member_alignment 
 

The HP C User's Guide for OpenVMS Systems has examples and diagrams of OpenVMS VAX structure alignment.

Bit fields can have any integral type. However, the compiler issues a warning if /STANDARD=ANSI89 is specified, and the type is other than int , unsigned int , or signed int . Bit fields are allocated within the unit from low order to high order. If a bit field immediately follows another bit field, the bits are packed into adjacent space, even if this overflows into another byte. However, if an unnamed bit field is specified to have length 0, filler is added so the bit field immediately following starts on the next byte boundary.

The HP C User's Guide for OpenVMS Systems has examples and diagrams of OpenVMS VAX bit-field alignment.

B.30 Enumeration Specifiers (§3.5.2.2)

The Standard specifies that each enumerated type be compatible with an implementation-defined integer type. In HP C, each enumerated type is compatible with the signed int type.

B.31 Type Qualifiers (§3.5.3)

The volatile storage class is specified for those variables that can be modified in ways unknown to the compiler. Thus, if an object is declared volatile, every reference to the object in the source code results in a reference to memory in the object code.

B.32 Declarators (§3.5.4)

There is no internal limit on the number of pointer, function or array declarators that can modify an arithmetic, structure, union, or incomplete type.

B.33 Initialization (§3.5.7)

C allows initializers to be optionally surrounded by braces ( { } ) when they are not logically necessary. This has resulted in aggregate initializers with partially ignored braces that are parsed differently depending on the type of parser implemented (bottom-up or top-down). The Standard has specified the top-down parse originally specified in Kernighan and Ritchie's The C Programming Language. Programs depending on a bottom-up parse (common C parse) of partially braced initializers can yield unexpected results. Even though this construct is allowed, a warning message is given to inform the user of ignored braces when in common C mode or if using the check option.

B.34 The switch Statement (§3.6.4.2)

There is no limit on the number of case labels in a switch statement.

B.35 External Object Definitions (§3.7.2)

In common C mode, all extern objects have file scope.

B.36 Conditional Inclusion (§3.8.1)

Previous preprocessors have allowed extraneous text after a preprocessor directive. For example:


        #endif system1 

However, the Standard has stated that the only text allowed after a preprocessing directive is a comment. Therefore, the HP C compiler issues a warning message if this syntax rule is violated.

The numeric value for character constants within #if and #elif directives matches the value obtained when an identical character constant occurs in expressions that are not part of these directives.

B.37 Source File Inclusion (§3.8.2)

Source files can be included using either a quoted path name ( #include "stdio.h" ) or bracketed path names ( #include <stdio.h> ). OpenVMS systems also support a method of including modules from a text library. See your platform-specific HP C documentation for the search-path algorithm for including source files.

B.38 Macro Replacement---Predefined Macro Names (§3.8.3)

In addition to the predefined macro names defined in the Standard, the HP C compiler defines other preprocessor macros for various identification purposes. When the compiler is invoked, the appropriate identification macros are defined depending on the operating system, architecture, language, compiler mode, and other environment variables. You can reference these macros in #ifdef preprocessor directives to isolate code that applies to a particular environment.

Each HP C platform can have additional predefined macros. See your platform-specific HP C documentation for more information.

Table B-1 shows the predefined macro names for Tru64 UNIX.

Table B-1 Tru64 UNIX Predefined Macro Names
  Macro Name
Operating system name: unix
  __unix__
  __osf
  SYSTYPE_BSD
  _SYSTYPE_BSD
Architecture name: __alpha
Product name: __DECC
  __DECC_VER
  LANGUAGE_C
  __LANGUAGE_C__

Table B-2 shows the predefined macro names for OpenVMS VAX and Alpha systems. All forms are defined unless strict ANSI mode is in effect, in which case only the new spellings are defined.

Table B-2 OpenVMS VAX, OpenVMS Alpha, and I64 Predefined Macro Names
  New Spelling Traditional Spelling
Operating system name: __vms vms
  __VMS VMS
  __vms_version vms_version
  __VMS_VERSION VMS_VERSION
Architecture name: __vax (VAX) vax (VAX)
  __VAX (VAX) VAX (VAX)
  __alpha (ALPHA) ---
  __ALPHA (ALPHA) ---
  __Alpha_AXP (ALPHA) ---
  __IA64 (I64) ---
  __IA64__ (I64) ---
  __32BITS (ALPHA) ---
Product name: __vaxc vaxc
  __VAXC VAXC
  __vax11c vax11c
  __VAX11C VAX11C
  __STDC__ ---
  __DECC ---
  __DECC_VER ---
  __VMS_V6_RTL_COMPAT ---
Compiler Mode: __DECC_MODE_STRICT ---
  __DECC_MODE_RELAXED ---
  __DECC_MODE_VAXC ---
  __DECC_MODE_COMMON ---
Floating-Point: __D_FLOAT ---
  __G_FLOAT ---
  __IEEE_FLOAT (ALPHA) ---
  __X_FLOAT (ALPHA) ---
Other: __HIDE_FORBIDDEN_NAMES ---
  __INITIAL_POINTER_SIZE (ALPHA) ---

You can explicitly define the macros in Table B-3 to control which C library routines are declared in header files and to obtain standards conformance checking. To define these macros use one of the following:

  • -D flag (TRU64 UNIX)
  • /DEFINE qualifier (OPENVMS)
  • #define preprocessor directive

Table B-3 Library Routine Standards Conformance Macros---All platforms
Macro Standard
_XOPEN_SOURCE_EXTENDED XPG4-UNIX
_XOPEN_SOURCE XPG4
_POSIX_C_SOURCE POSIX
_ANSI_C_SOURCE ISO C and ANSI C
_AES_SOURCE (TRU64 UNIX) Application Environment Services
_OSF_SOURCE (TRU64 UNIX) OSF compatibility
_VMS_V6_SOURCE (OPENVMS) OpenVMS Version 6 compatibility
_DECC_V4_SOURCE (OPENVMS) DEC C Version 4 compatibility

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.


Previous Next Contents Index

Privacy statement Using this site means you accept its terms
© 2007 Hewlett-Packard Development Company, L.P.