DEC C
User's Guide for OpenVMS Systems

By default, DEC C for OpenVMS VAX systems does not align structure members on natural boundaries; they are stored on byte boundaries (with the exception of bit-field members).

By default, DEC C for OpenVMS Alpha systems does align structure members on natural boundaries.

The #pragma member_alignment preprocessor directive can be used to force natural-boundary alignment of structure members. The #pragma nomember_alignment preprocessor directive restores byte-alignment of structure members.

This pragma has the following formats:

#pragma member_alignment #pragma member_alignment save #pragma member_alignment restore #pragma nomember_alignment [base_alignment]

When #pragma member_alignment is used, the compiler aligns structure members on the next boundary appropriate to the type of the member, rather than on the next byte. For example, a long variable is aligned on the next longword boundary; a short variable is aligned on the next word boundary.

Consider the following example:

#pragma nomember_alignment struct x { char c; int b; }; #pragma member_alignment struct y { char c; /*3 bytes of filler follow c */ int b; }; main () { printf( "The sizeof y is: %d\n", sizeof (struct y) ); printf( "The sizeof x is: %d\n", sizeof (struct x) ); }

When this example is executed, it shows the difference between #pragma member_alignment and #pragma nomember_alignment .

Once used, the member_alignment pragma remains in effect until the nomember_alignment pragma is encountered; the reverse is also true.

The optional base_alignment parameter can be used to specify the base-alignment of the structure. Use one of the following keywords for the base_alignment:

• byte (1 byte)
• word (2 bytes)
• longword (4 bytes)
• quadword (8 bytes)
• octaword (16 bytes)

The #pragma member_alignment save and #pragma member_alignment restore directives can be used to save the current state of the member_alignment and to restore the previous state, respectively. This feature is necessary for writing header files that require member_alignment or nomember_alignment , or that require inclusion in a member_alignment that is already set.

5.4.11 #pragma message Directive

The #pragma message directive controls the issuance of individual diagnostic messages or groups of messages. Use of this pragma overrides any command-line options that may affect the issuance of messages.

The #pragma message directive has the following formats:

#pragma message option1 (message-list) #pragma message option2

The parameter option1 must be one of the following keywords:

• enable ---Enables issuance of the messages specified in the message-list
• disable ---Disables issuance of the messages specified in the message-list
• emit_once ---Emits the specified messages only once per compilation.
  Certain messages are emitted only the first time the compiler encounters the causal condition. When the compiler encounters the same condition later in the program, no message is emitted. Messages about the use of language extensions are an example of this kind of message. To emit one of these messages every time the causal condition is encountered, use the EMIT_ALWAYS option.
  Errors and Fatals are always emitted. You cannot set them to emit_once .
• emit_always ---Emits the specified messages at every occurrence of the condition.
• errors ---Sets the severity of the specified messages to Error.
  Supplied Error messages and Fatal messages cannot be made less severe. (Exception: A message can be upgraded from Error to Fatal, then later downgraded to Error again, but it can never be downgraded from Error.)
  Warnings and Informationals can be made any severity.)
• fatals ---Sets the severity of the specified messages to Fatal.
• informationals ---Sets the severity of the specified messages to Informational. Note that Fatal and Error messages cannot be made less severe.
• warnings ---Sets the severity of each message in the message-list to Warning. Note that Fatal and Error messages cannot be made less severe.

The message-list can be any one of the following:

• A single message identifier (within parentheses, or not). The message identifier is the name following the severity at the start of a line when a message is issued. For example, in the following message, the message identifier is GLOBALEXT:

  %CC-W-GLOBALEXT, a storage class of globaldef, globalref, or globalvalue is a language extension.

• The name of a single message group (within parentheses, or not). Message-group names are:
  • ALL---All the messages in the compiler
  • ALIGNMENT---Messages about unusual or inefficient data alignment.
  • C_TO_CXX---Messages reporting the use of C features that would be invalid or have a different meaning if compiled by a C++ compiler.
  • CDD---Messages about CDD (Common Data Dictionary) support.
  • CHECK---Messages reporting code or practices that, although correct and perhaps portable, are sometimes considered ill-advised because they can be confusing or fragile to maintain. For example, assignment as the test expression in an "if" statement.
    The check group gets defined by enabling LEVEL5 messages.
  • DEFUNCT---Messages reporting the use of obsolete features: ones that were commonly accepted by early C compilers but were subsequently removed from the language.
  • NOANSI---Messages reporting the use of non-ANSI Standard features.
  • OBSOLESCENT---Messages reporting the use of features that are valid in ANSI Standard C, but which were identified in the standard as being obsolescent and likely to be removed from the language in a future version of the standard.
  • OVERFLOW---Messages that report assignments and/or casts that can cause overflow or other loss of data significance.
  • PERFORMANCE---Messages reporting code that might result in poor run-time performance.
  • PORTABLE---Messages reporting the use of language extensions or other constructs that might not be portable to other compilers or platforms.
  • PREPROCESSOR---Messages reporting questionable or non-portable use of preprocessing constructs.
  • QUESTCODE---Messages reporting questionable coding practices. Similar to the CHECK group, but messages in this group are more likely to indicate a programming error rather than just a non-robust style.
  • RETURNCHECKS---Messages related to function return values.
  • UNINIT---Messages related to using uninitialized variables.
  • UNUSED---Messages reporting expressions, declarations, header files, CDD records, static functions, and code paths that are not used.
• A single message-level name (within parentheses, or not).
  Message-level names are:
  • LEVEL1---Important messages. These are less important than the level 0 core messages, because messages in this group are not displayed if #pragma nostandard is active.
  • LEVEL2---Moderately important messages.
  • LEVEL3---Less important messages.
    LEVEL3 is the default message level for DEC C for OpenVMS systems.
  • LEVEL4---Useful check/portable messages.
  • LEVEL5---Not so useful check/portable messages.
  • LEVEL6---Additional "noisy" messages.
  
  Be aware that there is a core of very important compiler messages that are enabled by default, regardless of what you specify with /WARNINGS or #pragma message. Referred to as message level 0, it includes all messages issued in header files, and comprises what is known as the nostandard group. All other message levels add additional messages to this core of enabled messages.
  You cannot modify level 0 (You cannot disable it, enable it, change its severity, or change its EMIT_ONCE characteristic). However, you can modify individual messages in level 0, provided such modification is allowed by the action. For example, you can disable a warning or informational in level 0, or you can change an error in level 0 to a fatal, and so on. (See restrictions on modifying individual messages.)
  Enabling a level also enables all the messages in the levels lower than it. So enabling LEVEL3 messages also enables messages in LEVEL2 and LEVEL1.
  Disabling a level also disables all the messages in the levels higher than it. So disabling LEVEL4 messages also disables messages in LEVEL5 and LEVEL6.
• A comma-separated list of message identifiers, group names, and messages levels, freely mixed, enclosed in parentheses.

The parameter option2 must be one of the following keywords:

• save ---Saves the current state of which messages are enabled and disabled.
• restore ---Restores the previous state of which messages are enabled and disabled.

The save and restore options are useful primarily within header files.

5.4.12 #pragma module Directive

When you compile source files to create an object file, the compiler assigns the first of the file names specified in the compilation unit to the name of the object file. The compiler adds the .OBJ file extension to the object file. Internally, the OpenVMS system (the debugger and the librarian) recognizes the object module by the file name; the compiler also gives the module a version number of 1. For example, given the object file EXAMPLE.OBJ, the debugger recognizes the EXAMPLE object module.

To change the system-recognized module name and version number, use the #pragma module directive. The #pragma module directive is specific to DEC C for OpenVMS systems and is not portable.

You can find the module name and the module version number listed in the compiler listing file and the linker load map.

The #pragma module directive is equivalent to the VAX C compatible #module directive. The #pragma module directive may be used when compiling in any mode. Use #module only when compiling with the /STANDARD=VAXC qualifier.

The #pragma module directive has the following formats:

#pragma module identifier identifier #pragma module identifier string

The first parameter must be a valid DEC C identifier. It specifies the module name to be used by the linker. The second parameter specifies the optional identification that appears on listings and in the object file. It must be either a valid DEC C identifier of 31 characters or less, or a character-string constant of 31 characters or less.

Only one #pragma module directive can be processed per compilation unit, and that directive must appear before any C language text. The #pragma module directive can follow other directives, such as #define , but it must precede any function definitions or external data definitions.

The parameters in a #pragma module directive are subject to text replacement and can, therefore, contain references to identifiers defined in previous #define directives. The replacement occurs before the parameters are processed.

5.4.13 #pragma pack Directive

The #pragma pack preprocessor directive specifies the byte boundary for packing members of C structures.

The #pragma pack directive has the following format:

#pragma pack [n]

The n specifies the new alignment restriction in bytes:

1	align to byte
2	align to word
4	align to longword
8	align to quadword
16	align to octaword

A structure member is aligned to either the alignment specified by #pragma pack or the alignment determined by the size of the structure member, whichever is smaller. For example, a short variable in a structure gets byte-aligned if #pragma pack 1 is specified. If #pragma pack 2 , 4 , or 8 is specified, the short variable in the structure gets aligned to word.

If #pragma pack is not used or if it is specified without the n, packing defaults to 16 on OpenVMS Alpha systems, and to 1 (byte alignment) on OpenVMS VAX systems.

5.4.14 #pragma pointer_size Directive (ALPHA ONLY)

The #pragma pointer_size preprocessor directive can be used throughout a program to control whether pointers are 32-bit pointers or 64-bit pointers.

This directive has the same effect as the #pragma required_pointer_size directive, except that #pragma pointer_size is enabled only when the /POINTER_SIZE command-line qualifier is specified. If /POINTER_SIZE is omitted from the command line, #pragma pointer_size is ignored. (The #pragma required_pointer_size directive always takes effect, whether or not /POINTER_SIZE is specified.)

The #pragma pointer_size directive has the following format:

#pragma pointer_size keyword

The keyword is one of the following:

{ short |32}	32-bit pointer
{ long |64}	64-bit pointer
system_default	32-bit pointers on OpenVMS systems; 64-bit pointers on DIGITAL UNIX systems
save	Saves the current pointer size
restore	Restores the current pointer size to its last saved state

The #pragma required_pointer_size preprocessor directive is intended for use by developers of header files to control the size of pointers within a header file in those cases where the pointers are architecturally required to be a particular size, and must not be altered by the user's use of pointer-size controls.

This directive has the same effect as the #pragma pointer_size directive, except that a #pragma required_pointer_size always takes effect, even if /POINTER_SIZE is omitted from the command line. (The #pragma pointer_size directive is ignored if /POINTER_SIZE is omitted.)

The #pragma required_pointer_size directive has the following format:

#pragma required_pointer_size keyword

The keyword is one of the following:

{ short |32}	32-bit pointer
{ long |64}	64-bit pointer
system_default	32-bit pointers on OpenVMS systems; 64-bit pointers on DIGITAL UNIX systems
save	Saves the current pointer size
restore	Restores the current pointer size to its last saved state

Use the nostandard and standard pragmas together to define regions of source code where portability diagnostics are not to be issued.

This pragma has the following format:

#pragma [no]standard

Use #pragma nostandard to suppress diagnostics about non-ANSI extensions, regardless of the /STANDARD qualifier specified.

Use #pragma standard to direct the compiler to reinstate the setting of the /STANDARD qualifier that was in effect before the last #pragma nostandard was encountered. Every #pragma standard directive must be preceded by a corresponding #pragma nostandard directive.

The following example demonstrates the use of these pragmas:

#include <stdio.h> #pragma nostandard extern noshare FILE *stdin, *stdout, *stderr; #pragma standard

In this example, nostandard prevents the NOSHAREEXT diagnostic from being issued against the noshare storage-class modifier, which is specific to DEC C for OpenVMS systems.

After defining a special linkage using the #pragma linkage directive, described in Section 5.4.9, use the #pragma use_linkage directive to associate the linkage with a function.

This pragma has the following format:

#pragma use_linkage linkage-name (routine1, routine2, ...)

The linkage-name is the name of a linkage previously defined by the #pragma linkage directive.

routine1, routine2, ... are the names of functions that you want associated with the specified linkage.

The #pragma use_linkage directive must appear in the source file before any use or definition of the specified routines. Otherwise, the results are unpredictable.

The following example defines a special linkage and associates it with a routine that takes three integer parameters and returns a single integer result in the same location where the first parameter was passed:

#pragma linkage example_linkage (parameters(r16, r17, r19), result(r16)) #pragma use_linkage example_linkage (sub) int sub (int p1, int p2, short p3); main() { int result; result = sub (1, 2, 3); }

In this example, the result (r16) option indicates that the function result will be returned in R16 rather than the usual location (R0). The parameters option indicates that the three parameters passed to sub should be passed in R16, R17, and R19.