HELPLIB.HLB  —  CC  Language topics, Preprocessor  #pragma
  The #pragma preprocessor directive performs compiler-specific tasks
  as designated by each implementation of the C language.

  All pragmas have a <pragma-name>_m version, which makes the pragma
  subject to macro replacement.  For example, #pragma assert is not
  subject to macro expansion, but #pragma assert_m is.

  All pragmas also have a <pragma-name>_nm version, which prevents
  macro expansion.  For example, #pragma inline is subject to macro
  expansion, but #pragma inline_nm is not.

  There is also a _Pragma operator (C99 Standard), which destringizes
  its string literal argument, effectively allowing #pragma
  directives to be produced by macro expansion.  When specified using
  this operator, the tokens of the pragma, which appear together
  within a single string literal in this form, are not macro
  expanded, even if they have an "_m" suffix.  But macro expansion
  can be accomplished if desired by using the stringization operator
  (#) to form the string.

  The _Pragma operator has the following syntax:

      _Pragma ( string-literal )

  VSI C for OpenVMS Systems supports the following #pragma
  directives:

  #pragma assert[_m|_nm]

      Lets you specify assertions that the compiler can make about a
      program to generate more efficient code.

      The #pragma assert directive is never needed to make a program
      execute correctly, however if a #pragma assert is specified,
      the assertions must be valid or the program might behave
      incorrectly.

      Syntax:

      #pragma assert func_attrs(identifier-list)function-assertions
      #pragma assert global_status_variable(variable-list)
      #pragma assert non_zero(constant-expression) string-literal

      Descriptions follow.

      The #pragma assert func_attrs directive:

      The identifier-list is a list of function identifiers about
      which the compiler can make assertions.  If more than one
      identifier is specified, separate them by commas.

      The function-assertions specify the assertions for the compiler
      to make about the functions.  Specify one or more of the
      following, separating multiple assertions with whitespace:

      noreturn

           The compiler can assert that any call to the routine will
           never return.

      nocalls_back

           The compiler can assert that no routine in the source
           module will be called before control is returned from this
           function.

      nostate

           The compiler can assert that the value returned by the
           function and any side-effects the function might have are
           determined only by the function's arguments.  If a
           function is marked as having both noeffects and nostate,
           the compiler can eliminate redundant calls to the
           function.

      noeffects

           The compiler can assert that any call to this function
           will have no effect except to set the return value of the
           function.  If the compiler determines that the return
           value from a function call is never used, it can remove
           the call.

      file_scope_vars(option)

           The compiler can make assertions about how a function will
           access variables declared at file scope (with either
           internal or external linkage).

           The file_scope_vars option is one of the following:

            o  none - The function will not read nor write to any
               file-scope variables except those whose type is
               volatile or those listed in a #pragma assert
               global_status_variable.

            o  noreads - The function will not read any file-scope
               variables except those whose type is volatile or those
               listed in a #pragma assert global_status_variable.

            o  nowrites - The function will not write to any
               file-scope variables except those whose type is
               volatile or those listed in a #pragma assert
               global_status_variable.

      format (<style>, <format-index>, <first-to-check-index>)

           Asserts to the compiler that this function takes printf-
           or scanf-style arguments to be type-checked against a
           format string.  Specify the parameters as follows:

            o  <style> -- PRINTF or SCANF.

               This determines how the format string is interpreted.

            o  <format-index> -- {1|2|3|...}

               This specifies which argument is the format-string
               argument (starting from 1).

            o  <first-to-check-index> -- {0|1|2|...}

               This is the number of the first argument to check
               against the format string.  For functions where the
               arguments are not available to be checked (such as
               vprintf), specify the third parameter as 0.  In this
               case, the compiler only checks the format string for
               consistency.

      The #pragma assert global_status_variable directive:

      Use the #pragma assert global_status_variable(variable-list)
      form of the pragma to specify variables that are to be
      considered global status variables, which are exempt from any
      assertions given to functions by #pragma assert func_attrs
      file_scope_vars directives.

      The variable-list is a list of variables.

      The #pragma assert non_zero directive:

      When the compiler encounters this directive, it evaluates the
      constant-expression.  If the expression is zero, the compiler
      generates a message that contains both the specified
      string-literal and the compile-time constant-expression.  For
      example:

      #pragma assert non_zero(sizeof(a) == 12) "a is the wrong size"

      In this example, if the compiler determines that the sizeof a
      is not 12, the following diagnostic message is output:

      CC-W-ASSERTFAIL, The assertion "(sizeof(a) == 12)" was not
      true. a is the wrong size.

      Unlike the #pragma assert options func_attrs and
      global_status_variable, #pragma assert non_zero can appear
      either inside or outside a function body.  When used inside a
      function body, the pragma can appear wherever a statement can
      appear, but the pragma is not treated as a statement.  When
      used outside a function body, the pragma can appear anywhere a
      declaration can appear, but the pragma is not treated as a
      declaration.

      Because macro replacement is not performed on #pragma assert,
      you might need to use the #pragma assert_m directive to obtain
      the results you want.  Consider the following program that
      verifies both the size of a struct and the offset of one of its
      elements:

      #include <stddef.h>
      typedef struct {
          int a;
          int b;
      } s;
      #pragma assert non_zero(sizeof(s) == 8) "sizeof assert failed"
      #pragma assert_m non_zero(offsetof(s,b) == 4) "offsetof assert
      failed"

      Because offsetof is a macro, the second pragma must be #pragma
      assert_m so that offsetof will expand correctly.

  #pragma builtins[_m|_nm]

      Enables the VSI C built-in functions that directly access
      processor instructions.

      The #pragma builtins directive is provided for VAX C
      compatibility.

      VSI C implements #pragma builtins by including the <builtins.h>
      header file, and is equivalent to #include <builtins.h> on
      OpenVMS systems.

      This header file contains prototype declarations for the
      built-in functions that allow them to be used properly.  By
      contrast, VAX C implemented this pragma with special-case code
      within the compiler, which also supported a #pragma nobuiltins
      preprocessor directive to turn off the special processing.
      Because declarations cannot be "undeclared", VSI C does not
      support #pragma nobuiltins.  Furthermore, the names of all the
      built-in functions use a naming convention defined by ANSI C to
      be in a namespace reserved to the C language implementation.

  #pragma dictionary[_m|_nm]

      Allows you to extract CDD data definitions and include these
      definitions in your program.

      The ANSI C compliant #pragma dictionary directive is equivalent
      to the VAX C compatible #dictionary directive, but is supported
      in all compiler modes.  (The #dictionary directive is retained
      for compatibility and is supported only when compiling with the
      /STANDARD=VAXC qualifier.)

      Syntax:

           #pragma dictionary "cdd_path" [null_terminate]
           [name(structure_name)] [text1_to_array | text1_to_char]

      The cdd_path is a character string that gives the path name of
      the CDD record.  It can also be a macro that resolves to such a
      character string.

      The optional null_terminate keyword can be used to specify that
      all string data types should be null-terminated.

      The optional name() can be used to supply an alternate tag name
      or a declarator, struct_name for the outer level of a CDD
      structure.

      The optional text1_to_char keyword forces the CDD type "text"
      to be translated to char, rather than "array of char" if the
      size is 1.  This is the default if null_terminate is not
      specified.

      The optional text1_to_array keyword forces the CDD type "text"
      to be translated to type "array of char" even when the size
      is 1.  This is the default when null_terminate is specified.

  #pragma environment[_m|_nm]

       Sets, saves, or restores the states of context pragmas.  This
       directive protects include files from contexts set by
       encompassing programs, and protects encompassing programs from
       contexts that could be set in header files that they include.

       The #pragma environment directive affects the following
       pragmas:

        o  #pragma extern_model

        o  #pragma extern_prefix

        o  #pragma member_alignment

        o  #pragma message

        o  #pragma names

        o  #pragma pointer_size

        o  #pragma required_pointer_size

       Syntax:

           #pragma environment command_line
           #pragma environment header_defaults
           #pragma environment restore
           #pragma environment save

      command_line

           Sets, as specified on the command line, the states of all
           the context pragmas.  You can use this pragma to protect
           header files from environment pragmas that take effect
           before the header file is included.

      header_defaults

           Sets the states of all the context pragmas to their
           default values.  This is almost equivalent to the
           situation in which a program with no command-line options
           and no pragmas is compiled, except that this pragma sets
           the pragma message state to #pragma nostandard, as is
           appropriate for header files.

      save

           Saves the current state of every pragma that has an
           associated context.

      restore

           Restores the current state of every pragma that has an
           associated context.

  #pragma extern_model[_m|_nm]

       Controls the compiler's interpretation of objects that have
       external linkage.  This pragma lets you choose the global
       symbol model to be used for externs.

       Syntax:

           #pragma extern_model common_block [attr[,attr]...]
           #pragma extern_model relaxed_refdef [attr[,attr]...]
           #pragma extern_model strict_refdef "name" [attr[,attr]...]
           #pragma extern_model strict_refdef
           #pragma extern_model globalvalue
           #pragma extern_model save
           #pragma extern_model restore

      The default model on VSI C is #pragma relaxed_refdef noshr.
      This is different from the model used by VAX C, which is common
      block, shr.

      The [attr[,attr]...] are optional psect attribute
      specifications chosen from the following (at most one from each
      line):

       o  gbl lcl (Not allowed with relaxed_refdef)

       o  shr noshr

       o  wrt nowrt

       o  pic nopic (Not meaningful for Alpha)

       o  ovr con

       o  rel abs

       o  exe noexe

       o  vec novec

       o  noreorder (named strict_refdef only)

       o  natalgn (named strict_refdef only)

       o  0 byte 1 word 2 long 3 quad 4 octa 5 6 7 8 9 10 11 12 13 14
          15 16 page

      See the HP C User's Guide for more information on the #pragma
      extern_model directive.

  #pragma extern_prefix[_m|_nm]

       Controls the compiler's synthesis of external names, which the
       linker uses to resolve external name requests.

       When you specify #pragma extern_prefix with a string argument,
       the compiler prepends the string to all external names
       produced by the declarations that follow the pragma
       specification.

       This pragma is useful for creating libraries where the
       facility code can be attached to the external names in the
       library.

       Syntax:

           #pragma extern_prefix "string" [(id[,id]...)]
           #pragma extern_prefix {NOCRTL|RESTORE_CRTL} (id[,id]...)
           #pragma extern_prefix  save
           #pragma extern_prefix  restore

      Where "string" prepends the quoted string to external names in
      the declarations that follow the pragma specification.

      You can also specify an extern prefix for specific identifiers
      using the optional list [(<emphasis>(id)[,<emphasis>(id)]...)].

      The NOCRTL and RESTORE_CRTL keywords control whether or not the
      compiler applies its default RTL prefixing to the names
      specified in the id-list, required for this form of the pragma.
      The effect of NOCRTL is like that of the EXCEPT=keyword of the
      /PREFIX_LIBRARY_ENTRIES command-line qualifier.  The effect of
      RESTORE_CRTL is to undo the effect of a #pragma extern_prefix
      NOCRTL or a /PREFIX=EXCEPT= on the command line.

      The save and restore keywords can be used to save the current
      pragma prefix string and to restore the previously saved pragma
      prefix string, respectively.

      The default external prefix, when none has been specified by a
      pragma, is the null string.

  #pragma function[_m|_nm]

      Specifies that calls to the specified functions are not
      intrinsic but are, in fact, function calls.  This pragma has
      the opposite effect of #pragma intrinsic.

      Syntax:

           #pragma function[_m|_nm] (function1[, function2, ...])

  #pragma include_directory[_m|_nm]

      The effect of each #pragma include_directory is as if its
      string argument (including the quotes) were appended to the
      list of places to search that is given its initial value by the
      /INCLUDE_DIRECTORY qualifier, except that an empty string is
      not permitted in the pragma form.

      Syntax:

           #pragma include_directory <string-literal>

      This pragma is intended to ease DCL command-line length
      limitations when porting applications from POSIX-like
      environments built with makefiles containing long lists of -I
      options specifying directories to search for headers.  Just as
      long lists of macro definitions specified by the /DEFINE
      qualifier can be converted to #define directives in a source
      file, long lists of places to search specified by the
      /INCLUDE_DIRECTORY qualifier can be converted to #pragma
      include_directory directives in a source file.

      Note that the places to search, as described in the help text
      for the /INCLUDE_DIRECTORY qualifier, include the use of
      POSIX-style pathnames, for example "/usr/base".  This form can
      be very useful when compiling code that contains POSIX-style
      relative pathnames in #include directives.  For example,
      #include <subdir/foo.h> can be combined with a place to search
      such as "/usr/base" to form "/usr/base/subdir/foo.h", which
      will be translated to the filespec "USR:[BASE.SUBDIR]FOO.H"

      This pragma can appear only in the main source file or in the
      first file specified on the /FIRST_INCLUDE qualifier.  Also, it
      must appear before any #include directives.

  #pragma [no]inline[_m|_nm]

      Expands function calls inline.  The function call is replaced
      with the function code itself.

      Syntax:

           #pragma inline (id,...)
           #pragma noinline (id,...)

      If a function is named in an inline directive, calls to that
      function will be expanded as inline code, if possible.

      If a function is named in a noinline directive, calls to that
      function will not be expanded as inline code.

      If a function is named in both an inline and a noinline
      directive, an error message is issued.

      For calls to functions named in neither an inline nor a
      noinline directive, DEC C expands the function as inline code
      whenever appropriate as determined by a platform-specific
      algorithm.

  #pragma intrinsic[_m|_nm]

      Specifies that calls to the specified functions are intrinsic
      (that is, handled internally by the compiler, allowing it to
      generate inline code, move or eliminate calls, or do various
      other optimizations).  This pragma is only valid for functions
      that are known to the compiler.

      Syntax:

           #pragma intrinsic (function1[, function2, ...])

  #pragma linkage[_m|_nm]

      Specifies special linkage types for function calls.  This
      pragma is used with the #pragma use_linkage directive, which
      associates a previously defined special linkage with a
      function.

      Syntax:

           #pragma linkage linkage-name = (characteristics)
           #pragma linkage_ia64 linkage-name = (characteristics)

      On I64 systems, these two formats behave differently:

       o  The #pragma linkage_ia64 format requires I64 register names
          be specified.

       o  The #pragma linkage format requires Alpha register names be
          specified, which are automatically mapped, where possible,
          to specific I64 registers.

      The two formats are further described after the description of
      the characteristics.

      The characteristics specify information about where parameters
      will be passed, where the results of the function are to be
      received, and what registers are modified by the function call.
      Specify these characteristics as a parenthesized list of items
      of the following forms:

           parameters (register-list)
           result     (simple-register-list)
           preserved  (simple-register-list)
           nopreserve (simple-register-list)
           notused    (simple-register-list)
           notneeded  (ai, lp)
           standard_linkage

      You can supply the option keywords in any order.

      Description of Options:

        simple-register-list

           A comma-separated list of register names, either Rn or Fn.
           Example:

                nopreserve(F5, F6)

           For the #pragma linkage format, valid registers for the
           preserved, nopreserve, and notused options include
           general-purpose registers R0 through R30, and
           floating-point registers F0 through F30.

           Valid registers for the result and parameters options
           include general-purpose registers R0 through R25, and
           floating-point registers F0 through F30.

           For the #pragma linkage_ia64 format, see below for an
           explanation of register usage.

        register-list

           Similar to a simple-register-list except that it can
           contain parenthesized sublists.  Use the register-list to
           describe arguments and function result types that are
           structs, where each member of the struct is passed in a
           single register.  Example:

                parameters(R5, (F5, F6))

        parameters

           Use this option to pass arguments to the parameters of a
           routine in specific registers.

        result

           Use this option to specify the register to be used to
           return the value for the function.  If a function has a
           return type of void, do not specify the result option as
           part of the linkage.

        preserved

           A preserved register contains the same value after a call
           to the function as it did before the call.

        nopreserve

           A nopreserve register does not necessarily contain the
           same value after a call to the function as it did before
           the call.

        notused

           A notused register is not used in any way by the called
           function.

        notneeded

           Indicates that certain items are not needed by the
           routines using this linkage.  Valid options are:

                AI -- Specifies that the Argument Information
                register (R25) does not need to be set up when
                calling the specified functions.

                LP -- Specifies that the Linkage Pointer register
                does not need to be set up when calling the specified
                functions.  Note that for I64 systems, there is no
                linkage pointer, so this setting is accepted but does
                not change the behavior of the pragma.

        standard_linkage

           Tells the compiler to use the standard linkage appropriate
           to the target platform.  This can be useful to confine
           conditional compilation to the pragmas that define
           linkages, without requiring the corresponding #pragma
           use_linkage directives to be conditionally compiled as
           well.

           If the standard_linkage keyword is specified, it must be
           the only option in the parenthesized list following the
           linkage name.  For example:

           #pragma linkage special1 = (standard_linkage)

      If the standard_linkage keyword is not specified, you can
      supply the parameters, result, preserved, nopreserve, and
      notused options in any order, separated by commas.

      Description of the two formats of this pragma:

      The #pragma linkage_ia64 format of this preprocessor directive
      requires register names to be specified in terms of an OpenVMS
      I64 system.  The register names are never mapped to a different
      architecture.  This form of the pragma always produces an error
      if encountered on a different architecture.

      For this format of the pragma, valid registers for the
      preserved, nopreserve, notused, parameters, and result options
      are:

       o  Integer registers R3 through R12 and R19 through R31

       o  Floating-point registers F2 through F31

      In addition, the parameters and result options also permit
      integer registers R32 through R39 to be specified, according to
      the following convention.  On IA64, the first eight integer
      input/output slots are allocated to stacked registers, and thus
      the calling routine refers to them using different names than
      the called routine.  The convention for naming these registers
      in either the parameters or result option of a #pragma
      linkage_ia64 directive is always to use the hardware names as
      they would be used within the called routine:  R32 through R39.
      The compiler automatically compensates for the fact that within
      the calling routine these same registers are designated using
      different hardware names.

      The #pragma linkage format of this preprocessor directive
      accepts Alpha register names and conventions and automatically
      maps them, where possible, to specific I64 registers.  So
      whenever VSI C for I64 encounters a #pragma linkage directive,
      it attempts to map the Alpha registers specified in the linkage
      to corresponding I64 registers, and emits a SHOWMAPLINKAGE
      informational message showing the I64 specific form of the
      directive, #pragma linkage_ia64, with the I64 register names
      that replaced the Alpha register names.  The SHOWMAPLINKAGE
      message is suppressed under the #pragma nostandard directive,
      normally used within system header files.

      Code compiled on I64 systems that deliberately relies on the
      register mapping performed by #pragma linkage should either
      ignore the SHOWMAPLINKAGE informational, or disable it.

      The following shows the mapping that VSI C applies to the Alpha
      integer register names used in #pragma linkage format
      directives when they are encountered on an I64 system.  Note
      that the six standard parameter registers on Alpha (R16-R21)
      are mapped to the first six (of eight) standard parameter
      registers on I64 systems, which happen to be stacked registers:

      Integer Register Mapping:

       Alpha -> I64          Alpha -> I64

        R0 -> R8              R16 -> R32 *
        R1 -> R9              R17 -> R33 *
        R2 -> R28             R18 -> R34 *
        R3 -> R3              R19 -> R35 *
        R4 -> R4              R20 -> R36 *
        R5 -> R5              R21 -> R37 *
        R6 -> R6              R22 -> R22
        R7 -> R7              R23 -> R23
        R8 -> R26             R24 -> R24
        R9 -> R27             R25 -> R25
        R10 ->R10             R26 - no mapping
        R11 ->R11             R27 - no mapping
        R12 ->R30             R28 - no mapping
        R13 ->R31             R29 -> R29
        R14 ->R20             R30 -> R12
        R15 ->R21             R31 -> R0

        * In parameters or result; else ignored

      The following shows the mapping that VSI C applies to the Alpha
      floating-point register names used in #pragma linkage
      directives when they are encountered on an I64 system:

      Floating-Point Register Mapping:

       Alpha -> I64          Alpha -> I64

        F0 -> F8              F16 -> F8
        F1 -> F9              F17 -> F9
        F2 -> F2              F18 -> F10
        F3 -> F3              F19 -> F11
        F4 -> F4              F20 -> F12
        F5 -> F5              F21 -> F13
        F6 -> F16             F22 -> F22
        F7 -> F17             F23 -> F23
        F8 -> F18             F24 -> F24
        F9 -> F19             F25 -> F25
        F10 ->F6              F26 - F26
        F11 ->F7              F27 - F27
        F12 ->F20             F28 - F28
        F13 ->F21             F29 -> F29
        F14 ->F14             F30 -> F30
        F15 ->F15

      Mapping Diagnostics:

      In some cases, the HP C compiler on Alpha systems silently
      ignores linkage registers if, for example, a standard parameter
      register like R16 is specified in a preserved option.  When you
      compile on an I64 system, this situation emits an MAPREGIGNORED
      informational message, and the SHOWMAPLINKAGE output might not
      be correct.  If there is no valid mapping to I64 registers, the
      NOMAPPOSSIBLE error message is output.  There are two special
      situations that can arise when floating-point registers are
      specified in a linkage:

       o  Only IEEE-format values are passed in floating-point
          registers under the OpenVMS Calling Standard for I64:  VAX
          format values are passed in integer registers.  Therefore,
          a compilation that specifies /FLOAT=D_FLOAT or
          /FLOAT=G_FLOAT produces an error for any linkage that
          specifies floating-point registers.  Note that this
          includes use in options that do not involve passing values,
          such as the preserved and notused options.

       o  The mapping of floating-point registers is many-to-one in
          two cases:

           -  Alpha registers F0 and F16 both map to I64 register F8

           -  Alpha F1 and F17 both map to I64 register F9.

          A valid Alpha linkage may well specify uses for both F0 and
          F16, and/or both F1 and F17.  Such a linkage cannot be
          mapped on an I64 system.  But because of the way this
          situation is detected, the MULTILINKREG warning message
          that is produced can only identify the second occurrence of
          an Alpha register that got mapped to the same I64 register
          as some previous Alpha register.  The actual pair of Alpha
          registers in the source is not identified, and so the
          message can be confusing.  For example, an option like
          preserved(F1,F17) gets a MULTILINKREG diagnostic saying
          that F17 was specified more than once.

  #pragma [no]member_alignment[_m|_nm]

      Tells the compiler to align structure members on the next
      boundary appropriate to the type of the member rather than the
      next byte.  For example, a long variable is aligned on the next
      longword boundary; a short variable on the next word boundary.

      Syntax:

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

      The optional base_alignment parameter can be used with #pragma
      nomember_alignment to specify the base alignment of the
      structure.  Use one of the following keywords to specify the
      base_alignment:

       o  BYTE (1 byte)

       o  WORD (2 bytes)

       o  LONGWORD (4 bytes)

       o  QUADWORD (8 bytes)

       o  OCTAWORD (16 bytes)

      The optional save and restore keywords 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.

  #pragma message[_m|_nm]

      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.

      Syntax:

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

      where option1 is:

         disable             Suppresses the issuance of the indicated
                             messages.

                             Only messages of severity Warning (W) or
                             Information (I) can be disabled.  If the
                             message has severity of Error (E) or
                             Fatal (F), it is issued regardless of
                             any attempt to disable it.

         enable              Enables the issuance of the indicated
                             messages.

         emit_once           Emits the specified messages only once
                             per compilation.

         emit_always         Emits the specified messages at every
                             occurrence of the condition.

         error               Sets the severity of each message in the
                             message-list to Error.

         fatal               Sets the severity of each message on the
                             message-list to Fatal.

         informational       Sets the severity of each message in the
                             message-list to Informational.

         warning             Sets the severity of each message in the
                             message-list to Warning.

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

       o  A single message identifier (within parentheses or not).

       o  A single message-group name (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.

                             NOTE:  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.

             NEWC99          Messages reporting the use of the new
                             C99 Standard features.

             NOANSI          Messages reporting the use of non-ANSI
                             Standard features.  The NOANSI message
                             group is a synonym for NOC89.  Also see
                             message groups NEWC99, NOC89, NOc99.

             NOC89           Messages reporting the use of non-C89
                             Standard features.

             NOC99           Messages reporting the use of non-C99
                             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.
                             Enabling the QUESTCODE group provides
                             lint-like checking.

             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.

                             Note, however, that unlike any other
                             messages, these messages must be enabled
                             on the command line
                             (/WARNINGS=ENABLE=UNUSED) to be
                             effective.

      o  A single message-level name (within parentheses or not).

         Note:  There is a core of very important compiler messages
         that are enabled by default, regardless of anything
         specified 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 disable level 0.  However, you can disable
         individual messages in level 0 that are not errors or
         fatals.

         Message-level names are:

           LEVEL1          Important messages.  These are less
                           important than level 0, because messages
                           in this group are not displayed if #pragma
                           nostandard is active.

           LEVEL2          Moderately important messages.  This level
                           is used to introduce new messages that
                           will be output in the DIGITAL UNIX V4.0
                           release.  LEVEL2 is the default for
                           DIGITAL UNIX and Tru64 UNIX platforms.

           LEVEL3          Less important messages.  In general,
                           these are the messages output by default
                           in DEC C Version 5.5 for OpenVMS Systems.
                           LEVEL3 is the default message level for
                           VSI C for OpenVMS systems.

           LEVEL4          Useful check/portable messages.

           LEVEL5          Not so useful check/portable messages.

           LEVEL6          All messages in LEVEL5 plus additional
                           "noisy" messages.

        Enabling a level also enables all the messages in the levels
        below it.  So enabling LEVEL3 messages also enables messages
        in LEVEL2 and LEVEL1.

        Disabling a level also disables all the messages in the
        levels above it.  So disabling LEVEL4 messages also disables
        messages in LEVEL5 and LEVEL6.

      o  A comma-separated list of message identifiers, group names,
         and messages levels, freely mixed, enclosed in parentheses.

     option2 is:

           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.

     The #pragma message (quoted-string) form outputs the
     quoted-string as a compiler message.  This form of the pragma is
     subject to macro replacement.  For example, the following is
     valid:

        #pragma message ("Compiling file " __FILE__)

  #pragma module[_m|_nm]

      The ANSI C compliant #pragma module directive is equivalent to
      the VAX C compatible #module directive, but is supported in all
      compiler modes.  (The #module directive is retained for
      compatibility and is supported only when compiling with the
      /STANDARD=VAXC qualifier.) The #pragma module directive is
      specific to VSI C for OpenVMS Systems and is not portable.

      Use the #pragma module directive to change the
      system-recognized module name and version number.  You can find
      the module name and version number in the compiler listing file
      and the linker load map.

      Syntax:

           #pragma module identifier identifier
           #pragma module identifier string

      The first parameter must be a valid VSI 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 VSI
      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.

  #pragma names[_m|_nm]

      Provides the same kinds of control over the mapping of external
      identifiers' object-module symbols as does the /NAMES
      command-line qualifier, and it uses the same keywords.  But as
      a pragma, the controls can be applied selectively to regions of
      declarations.

      This pragma should only be used in header files and is intended
      for use by developers who supply libraries and/or header files
      to their customers.

      The pragma has a save/restore stack that is also managed by
      #pragma environment, and so it is well-suited for use in header
      files.  The effect of #pragma environment header_defaults is to
      set NAMES to "uppercase,truncated", which is the compiler
      default.

      Syntax:

           #pragma names <stack-option>
           #pragma names <case-option>
           #pragma names <length-option>

      Where

      <stack-option> is one of:

       o  save - save the current names state

       o  restore - restore a saved names state

      <case-option> is one of:

       o  uppercase - uppercase external names

       o  as_is - do not change case

      <length-option> is one of:

       o  truncated - truncate at 31 characters

       o  shortened - shorten to 31 using CRC

  #pragma optimize[_m|_nm]

      Sets the optimization characteristics of function definitions
      that follow the directive.  It allows optimization-control
      options that are normally set on the command line for the
      entire compilation to be specified in the source file for
      individual functions.

      Syntax:

           #pragma optimize <settings>
           #pragma optimize save
           #pragma optimize restore
           #pragma optimize command_line

      Where <settings> is any combination of the following:

       o  <level settings>

          Set the optimization level.  Specify as:

           level=n

      Where n is an integer from 0 to 5.

   o  <unroll settings>

      Control loop unrolling.  Specify as:

           unroll=n

      Where n is a nonnegative integer.

   o  <ansi-alias settings>

      Control ansi-alias assumptions.  Specify one of the following:

           ansi_alias=on
           ansi_alias=off

   o  <intrinsic settings>

      Control recognition of intrinsics.  Specify one of the
      following:

           intrinsics=on
           intrinsics=off

      Use the save, restore, and command_line keywords as follows:

       o  save -- Saves the current pointer size

       o  restore -- Restores the current pointer size to its last
          saved state

       o  command_line -- Sets the optimization settings to what was
          specified on the command line

      Example:

           #pragma optimize level=5 unroll=6

      Usage Notes:

       o  If the level=0 clause is present, it must be the only
          clause present.

       o  The #pragma optimize directive must appear at file scope,
          outside any function body.

       o  The #pragma environment save and restore operations include
          the optimization state.

       o  The #pragma environment command_line directive resets the
          optimization state to that specified on the command line.

       o  If #pragma optimize does not specify a setting for one of
          the optimization states, that state remains unchanged.

       o  When a function definition is encountered, it is compiled
          using the optimization settings that are current at that
          point in the source.

       o  When a function is compiled under level=0, the compiler
          will not inline that function.  In general, when functions
          are inlined, the inlined code is optimized using the
          optimization controls in effect at the call site instead of
          using the optimization controls specified for the function
          being inlined.

       o  When the OpenVMS command line specifies /NOOPT (or
          /OPTIMIZE=LEVEL=0), the #pragma optimize directive has no
          effect (except that its arguments are still validated).

  #pragma pack[_m|_nm]

      Specifies the byte boundary for packing members of C
      structures.

      Syntax:

           #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.

      When #pragma pack is specified without a value or with a value
      of 0, packing reverts to that specified by the
      /[NO]MEMBER_ALIGNMENT qualifier setting (either explicitly
      specified or by default) on the command line.  Note that when
      specifying #pragma pack without a value, you must use
      parentheses:  #pragma pack ().

  #pragma pointer_size[_m|_nm]

      Controls whether pointers are 32-bit pointers or 64-bit
      pointers.

      Syntax:

           #pragma pointer_size keyword

      Where keyword is one of the following:

       o  short -- 32-bit pointer

       o  long -- 64-bit pointer

       o  system_default -- 32-bit pointers on OpenVMS systems;
          64-bit pointers on Tru64 UNIX systems

       o  save -- Saves the current pointer size

       o  restore -- Restores the current pointer size to its last
          saved state

  This directive is enabled only when the /POINTER_SIZE command-line
  qualifier is specified.  Otherwise, #pragma pointer_size has the
  same effect as #pragma required_pointer_size.

  #pragma required_pointer_size[_m|_nm]

      Intended for use by developers of header files to control
      pointer size within header files.

      Syntax:

           #pragma required_pointer_size keyword

      Where keyword is one of the following:

       o  short -- 32-bit pointer

       o  long -- 64-bit pointer

       o  system_default -- 32-bit pointers on OpenVMS systems;
          64-bit pointers on Tru64 UNIX systems

       o  save -- Saves the current pointer size

       o  restore -- Restores the current pointer size to its last
          saved state

  This directive is always enabled, even if the /POINTER_SIZE
  command-line qualifier is omitted.  Otherwise, #pragma
  required_pointer_size has the same effect as #pragma pointer_size.

  #pragma [no]standard[_m|_nm]

      Directs the compiler to define regions of source code where
      portability diagnostics are not to be issued.

      Use #pragma nostandard to suppress diagnostics about non-ANSI C
      extensions, regardless of the /STANDARD qualifier specified,
      until a #pragma standard directive is encountered.

      Use #pragma standard to reinstate the setting of the /STANDARD
      qualifier that was in effect before before the last #pragma
      nostandard was encountered.

      Every #pragma standard directive must be preceded by a
      corresponding #pragma nostandard directive.

      Note that this pragma does not change the current mode of the
      compiler or enable any extensions not already supported in that
      mode.

  #pragma unroll[_m|_nm]

      Directs the compiler to unroll the for loop that follows it by
      the number of times specified in the unroll_factor argument.
      The #pragma unroll directive must be followed by a for
      statement.

      Syntax:

           #pragma unroll (unroll_factor)

      The unroll_factor is an integer constant in the range 0 to 255.
      If a value of 0 is specified, the compiler ignores the
      directive and determines the number of times to unroll the loop
      in its normal way.  A value of 1 prevents the loop from being
      unrolled.  The directive applies only to the for loop that
      follows it, not to any subsequent for loops.

  #pragma use_linkage[_m|_nm]

      Associates a special linkage, defined by the #pragma linkage
      directive, with the specified functions.

      Syntax:

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

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

      The parenthesized list contains the names of functions you want
      to associated with the named linkage.

      The list can also contain typedef names of function type, in
      which case functions or pointers to functions declared using
      that type will have the specified linkage.
Close Help