/[no]stand

Syntax:

/stand[:keyword], /nostand, /4Ys, or /4Ns

The /stand option issues compile-time messages for language elements that are not standard in the Fortran 90 or Fortran 95 language that can be identified at compile-time. In the visual development environment, specify the Fortran Standards Checking in the Compilation Diagnostics Compiler Option Category.

The /stand options are:

• /stand:f90 or /4Ys

  Specifies that diagnostic messages be generated with a warning-level severity (allows an object file to be created) for extensions to the Fortran 90 standard.

• /stand or /stand:f95

  Specifies that diagnostic messages be generated with a warning-level severity (allows an object file to be created) for extensions to the Fortran 95 standard.

• /stand:none, /nostand, or /4Ns

  Specifies that no messages be issued for language elements that are not standard in the Fortran 90 or Fortran 95 language.

  The same effect occurs if you omit the /stand, or /stand:keyword, /warn:stderrors, or /4Ys options.

Specify /warn:stderrors to request that diagnostic messages be generated with an error-level severity (instead of warning) to prevent an object file from being created.

Specifying /stand issues warning messages for:

• Obsolescent and deleted features specified by the Fortran standard.
• Syntax extensions to the Fortran 95 standard. Syntax extensions include nonstandard statements and language constructs.
• Fortran 95 standard-conforming statements that become nonstandard due to the way in which they are used. Data type information and statement locations are considered when determining semantic extensions.
• For fixed-format source files, lines that use tab formatting.

Source statements that do not conform to Fortran language standards are detected by the compiler under the following circumstances:

• The statements contain ordinary syntax and semantic errors.
• A source program containing nonconforming statements is compiled with the /stand or /check options.

Given these circumstances, the compiler is able to detect most instances of nonconforming usage. It does not detect all instances because the /stand option does not produce checks for all nonconforming usage at compile time. In general, the unchecked cases of nonconforming usage arise from the following situations:

• The standard violation results from conditions that cannot be checked at compile time.
• The compile-time checking is prone to false alarms.

Most of the unchecked cases occur in the interface between calling and called subprograms. However, other cases are not checked, even within a single subprogram.

The following items are known to be unchecked:

• Use of a data item prior to defining it
• Use of the SAVE statement to ensure that data items or common blocks retain their values when reinvoked
• Association of character data items on the right and left sides of character assignment statements
• Mismatch in order, number, or type in passing actual arguments to subprograms with implicit interfaces
• Association of one or more actual arguments with a data item in a common block when calling a subprogram that assigns a new value to one or more of the arguments