[an error occurred while processing this directive]

HP OpenVMS Systems

C Programming Language
Content starts here dec_c_help.HLP

noshare

Noshare variables are assigned the PSECT attribute NOSHR. Noshare variables may not be shared between processes. This modifier is used when linking variables that are not to be shared within a shareable image. You can use the noshare modifier with the storage-class keywords static, [extern], globaldef, and globaldef{"name"}.

readonly

Readonly variables are assigned the PSECT attribute NOWRT and are stored in the PSECT $READONLY$ which is a nonwritable data area. Other programs can access the PSECT directly, but none of the information can be overwritten. You can use the readonly modifier with the storage-class keywords [extern], static, globaldef, and globaldef{"name"}. You can use both the readonly and noshare modifiers with the [extern] and the globaldef{"name"} specifiers. If you use both modifiers with either the static or the globaldef specifiers, the compiler ignores noshare and accepts readonly.

_align

The _align modifier allows you to align objects of any of the HP C data types on a specified storage boundary. Use the _align modifier in a data declaration or definition. When specifying the boundary of the data alignment, you can use a predefined constant: BYTE or byte, WORD or word, LONGWORD or longword, QUADWORD or quadword, OCTAWORD or octaword, and PAGE or page. You can also specify an integer value that is a power of two. The power of two tells HP C the number of bytes to pad in order to align the data: For OpenVMS VAX systems, specify a constant 0, 1, 2, 3, 4, or 9. For OpenVMS Alpha systems, specify any constant from 0 to 16.

__align

The __align storage-class modifier has the same semantic meaning as the _align keyword. The difference is that __align is a keyword in all compiler modes while _align is a keyword only in modes that recognize VAX C keywords. For new programs, using __align is recommended.

__forceinline

Similar to the __inline storage-class modifier, the __forceinline storage-class modifier marks a function for inline expansion. However, using __forceinline on a function definition and prototype tells the compiler that it must substitute the code within the function definition for every call to that function. (With __inline, such substitution occurs at the discretion of the compiler.) Syntax: __forceinline [type] function_definition

__inline

The __inline modifier marks a function for inline expansion. Using __inline on a function definition and prototype tells the compiler that it can substitute the code within the function definition for every call to that function. Substitution occurs at the discretion of the compiler. The __inline storage-class specifier has the same effect as the #pragma inline preprocessor directive, except that the latter attempts to provide inline expansion for all functions in a translation unit, rather than for selected functions. Syntax: __inline [type] function_definition

inline

Similar to the __inline storage-class modifier, the inline storage-class modifier can be used as a declaration specifier in the declaration of a function. This modifier is supported in relaxed ANSI C mode (/STANDARD=RELAXED) or if the /ACCEPT=C99_KEYWORDS or /ACCEPT=GCCINLINE qualifier is specified. With static functions, inline has the same effect as applying __inline or #pragma inline to the function. However, when inline is applied to a function with external linkage, besides allowing calls within that translation unit to be inlined, the inline semantics provide additional rules that also allow calls to the function to be inlined in other translation units or for the function to be called as an external function, at the compiler's discretion: o If the inline keyword is used on a function declaration with external linkage, then the function must also be defined in the same translation unit. o If all of the file scope declarations of the function use the inline keyword but do not use the extern keyword, then the definition in that translation unit is called an inline definition, and no externally-callable definition is produced by that compilation unit. Otherwise, the compilation unit does produce an externally-callable definition. o An inline definition must not contain a definition of a modifiable object with static storage duration, and it must not refer to an identifier with internal linkage. These restrictions do not apply to the externally-callable definition. o As usual, at most one compilation unit in an entire program can supply an externally-callable definition of a given function. o Any call to a function with external linkage may be translated as a call to an external function, regardless of the presence of the inline qualifier. It follows from this and the previous point that any function with external linkage that is called must have exactly one externally-callable definition among all the compilation units of an entire program. o The address of an inline function with external linkage is always computed as the address of the unique externally-callable definition, never the address of an inline definition. o A call to inline function made through a pointer to the externally-callable definition may still be inlined or translated as a call to an inline definition, if the compiler can determine the name of the function whose address was stored in the pointer.