
1 FTNCHEK
       ftnchek - Fortran 77 program checker

2 Introduction
      ftnchek  (short  for Fortran checker) is designed to detect cer-
 tain errors in a Fortran program that a compiler  usually  does  not.
 ftnchek  is not primarily intended to detect syntax errors.  Its pur-
 pose is to assist the user in finding semantic errors.  Semantic  er-
 rors  are legal in the Fortran language but are wasteful or may cause
 incorrect operation.  For example, variables which are never used may
 indicate  some  omission in the program; uninitialized variables con-
 tain garbage which may cause incorrect results to be calculated;  and
 variables which are not declared may not have the intended type.  ft-
 nchek is intended to assist users in the debugging of  their  Fortran
 program.  It is not intended to catch all syntax errors.  This is the
 function of the compiler.  Prior to using ftnchek,  the  user  should
 verify that the program compiles correctly.

 For more detailed information, consult the printed documentation.

2 Invoking_Ftnchek
       ftnchek is invoked through a command of the form:

        $ ftnchek [/option /option ...] filename [filename ...]
      The brackets indicate something which is optional.  The brackets
 themselves are not actually typed.   Here  options  are  command-line
 switches  or settings, which control the operation of the program and
 the amount of information that will be printed out.  If no option  is
 specified,  the  default action is to print error messages, warnings,
 and informational messages, but not the program listing or symbol ta-
 bles.

      Each option begins with the '/' character.  (ftnchek also allows
 the '-' character to be used.)
      ftnchek options fall into two categories:  switches,  which  are
 either  true  or  false, and settings, which have a numeric or string
 value.  The name of a switch is prefixed by 'no' or 'no-' to turn  it
 off: e.g. /nopure would turn off the warnings about impure functions.
 The 'no' prefix can also be used with numeric  settings,  having  the
 effect of turning off the corresponding warnings.  Settings that con-
 trol lists of warnings have a special syntax discussed  below.   Only
 the  first 3 characters of an option name (not counting the '/') need
 be provided.  A colon may be used in place of an equals sign for  nu-
 meric or string setting assignments; however, we show only the equals
 sign form below.

      When more than one option is used, they should be separated by a
 blank  space.  No blank spaces may be placed around the equals sign (
 = ) in a setting.  ftnchek "?"  will produce a command summary  list-
 ing all options and settings.
      For  settings  that  take a list of keywords, namely /arguments,
 /array, /calltree, /common, /crossref, /f77, /f90, /f95,  /intrinsic,
 /makedcls, /mkhtml, /portability, /pretty, /project, /source, /style,
 /truncation, and /usage, the list consists of keywords  separated  by
 commas  or colons.  If the list of keywords is omitted, the effect is
 to set the option to its turn-on value (same as ''all'' in most  cas-
 es).   Also, if the list is omitted, the setting name can be prefixed
 with no or no- to turn off all the options it controls.  For example,
 /f77  turns  on  all  warnings about nonstandard constructions, while
 /nof77 turns them all off.    Three special keywords are:
    help Print out all the option keywords controlled by the  setting,
        with a brief explanation of their meanings.  This keyword can-
        not be given in a list with other keywords.
    all Set all options. This turns on all options controlled  by  the
        setting.
    none  Clear all options.  This turns off all options controlled by
        the setting.
      These three special keywords must be given  in  full.   For  all
 other  keywords, only as many letters of the keyword as are necessary
 to identify it unambiguously need be given, or a wildcard pattern may
 be used.  Including a keyword in the list turns the corresponding op-
 tion on.  For example, /f77=intrinsic would turn on only the warnings
 about use of nonstandard intrinsic functions.  Prefixing a keyword by
 no- turns its option off.  For  example,  /pretty=no-long-line  turns
 off warnings about lines exceeding 72 columns in length while leaving
 all other warnings about misleading appearance in effect.  If a  set-
 ting  has default none, you can turn on all options except one or two
 by using all first.  For example, /f77=all,no-include  enables  warn-
 ings  about all nonstandard extensions except INCLUDE statements.  If
 a setting has default all, you can turn off all warnings  except  one
 or  two  by using none first.  For example, /truncation=none,demotion
 would turn off all precision related warnings except about demotions.
 Wildcard  patterns  contain  an  asterisk  to stand for any string of
 characters.  If a wildcard pattern is used,  all  the  warnings  that
 match  it  are  affected.  If no- is prefixed to the pattern, all the
 matching warnings are turned off, otherwise they are all  turned  on.
 The minimum unambiguous length rule does not apply to wildcard match-
 ing.    For example, use /usage=no-*var* to turn off all warnings re-
 lating  to  variable  usage (both local and common).  (Unix users may
 need to quote any options containing wildcards in  order  to  prevent
 the  shell from attempting to expand them.)  Wildcards are recognized
 only in lists of warning keywords, not in the top-level options them-
 selves.
      When  ftnchek  starts up, it looks for environment variables and
 also for a preferences file.  Any options defined in the  environment
 or  in  the  preferences  file  are  used as defaults in place of the
 built-in defaults.  They are over-ridden by any command line options.
 See  the section on changing the defaults for details about the envi-
 ronment options and the preferences file.

2 Files
      When giving a name of an input file, the extension is  optional.
 If  no extension is given, ftnchek will first look for a project file
 with extension .prj, and will use that if it exists.   If  not,  then
 ftnchek  will look for a Fortran source file with the extension .for.
 More than one file name can be given to ftnchek, and it will  process
 the modules in all files as if they were in a single file.

      Wildcards  are  allowed in the specification of filenames on the
 command line.
      If no filename is given, ftnchek will read input from the  stan-
 dard input.


2 Options
      ftnchek  options  fall  into two categories: switches, which are
 either true or false, and settings, which have a  numeric  or  string
 value.   The  name  of a switch or numeric setting can be preceded by
 'no' to turn it off: e.g. /nocommon would turn off the warnings about
 common  block inconsistencies.  Only the first 3 characters of an op-
 tion name (not counting the '/') need be provided.  Most options  are
 positional:  each  option  remains in effect from the point it is en-
 countered until it is overridden by a later change.


3 /arguments=list
       Controls warnings about mismatches  between  actual  and  dummy
 subprogram  arguments, and also about mismatches between expected and
 actual subprogram type.  (An actual argument is an argument passed to
 the  subprogram  by  the  caller; a dummy argument is an argument re-
 ceived by the subprogram.)  By default, all warnings are turned on.
      The list consists of keywords separated  by  commas  or  colons.
 Since  all  these  warnings are on by default, include a keyword pre-
 fixed by no- to turn off a particular warning.  There are three  spe-
 cial  keywords: all to turn on all the warnings about arguments, none
 to turn them all off, and help to print the list of all the  keywords
 with  a brief explanation of each.  If list is omitted, /arguments is
 equivalent to /arguments=all, and /noarguments is equivalent to  /ar-
 guments=none.   The  warning keywords with their meanings are as fol-
 lows:
    arrayness: warn about inconsistent use of arguments that  are  ar-
        rays.   These warnings can be further controlled by the /array
        option.
    type: warn about dummy arguments of a different data type from the
        actual arguments.
    function-type:  warn  if the invocation assumes the function's re-
        turn value is a different type  than  it  actually  is.   Also
        warns  if a function is called as a subroutine, or vice-versa.
    number: warn about invoking a subprogram with a  different  number
        of arguments than the subprogram expects.
      For  compatibility with previous versions of ftnchek,  a numeric
 form of this setting is also accepted: the list is replaced by a num-
 ber from 0 to 3.  A value of 0 turns all the warnings off, 1 turns on
 only number, 2 turns on all except number, and 3 turns all the  warn-
 ings on.
      This setting does not apply to checking invocations of intrinsic
 functions or statement functions, which can only be turned off by the
 /nocheck option.
      See also: /array, /library, /usage.


3 /array=list
       Controls the degree of strictness in checking agreement between
 actual and dummy subprogram arguments that are arrays.  The  warnings
 controlled  by  this setting are for constructions that might legiti-
 mately be used by a knowledgeable programmer, but that often indicate
 programming errors.  By default, all warnings are turned on.
      The  list  consists  of  keywords separated by commas or colons.
 Since all these warnings are on by default, include  a  keyword  pre-
 fixed  by no- to turn off a particular warning.  There are three spe-
 cial keywords: all to turn on all the warnings about array arguments,
 none to turn them all off, and help to print the list of all the key-
 words with a brief explanation of each.  If list is  omitted,  /array
 is  equivalent  to  /array=all,  and  /noarray  is equivalent to /ar-
 ray=none.  The warning keywords with their meanings are as follows:
    dimensions: warn if the arguments differ in their number of dimen-
        sions, or if the actual argument is an array element while the
        dummy argument is a whole array.
    size: warn if both arguments are arrays, but they differ in number
        of elements.
      For  compatibility with previous versions of ftnchek,  a numeric
 form of this setting is also accepted: the list is replaced by a num-
 ber from 0 to 3.  A value of 0 turns all the warnings off, 1 turns on
 only dimensions, 2 turns on only size, and 3 turns all  the  warnings
 on.
      Note:  A  warning  is always given regardless of this setting if
 the actual argument is an array while the dummy argument is a  scalar
 variable,  or  if the actual argument is a scalar variable or expres-
 sion while the dummy argument is an array.  These  cases  are  seldom
 intentional.  (To turn off even these warnings, use /arguments=no-ar-
 rayness.)  No warning is ever given if the actual argument is an  ar-
 ray element while the dummy argument is a scalar variable.  Variable-
 dimensioned arrays and arrays dimensioned with 1  or  asterisk  match
 any number of array elements.  There is no check of whether multi-di-
 mensional arrays agree in the size of each dimension separately.
      See also: /arguments, /library, /usage.


3 /brief
       Selects  a  shorter  format  for  some  warning  messages.   At
 present, the only warnings controlled by this flag are those that are
 printed at the end of  processing  each  subprogram.   These  include
 warnings  about  variables  that  are set but not used or used before
 set, variable names that do not conform to the Fortran  77  standard,
 etc.   (These  warnings may be suppressed entirely depending on other
 flags, such as the /usage or /f77 flags.)  In the default format each
 variable  is  listed  on  a separate line, along with the line number
 where the variable is declared, set or used, according to the  nature
 of  the  warning.   The  briefer format simply lists all variables to
 which the warning applies, with up to 4 variables per line.
      See also: /quiet.


3 /calltree=list
       Causes ftnchek to print out the call structure of the  complete
 program.
      The  list  consists  of  keywords separated by commas or colons.
 There are two special keywords: none to turn off all the options, and
 help  to  print the list of all the keywords with a brief explanation
 of each.  (The keyword all turns on all the options, but  should  not
 normally be used since only one format should be specified.)  If list
 is omitted, /calltree is equivalent to /calltree=tree,  and  /nocall-
 tree  is  equivalent  to /calltree=none.  By default no call graph is
 printed.
      If the /mkhtml option is invoked and tree is the  applied  call-
 tree  option,  a  file named CallTree.html, will also be produced de-
 picting the tree in HTML format.  This file is useful as  a  starting
 point  for  browsing  the HTML files describing each component of the
 program.
      The keywords which control which format is used are as follows:
    tree: produce the call graph in tree format.
    reference: produce the call graph in who-calls-who format (same as
        /reference switch).
    vcg: produce the call graph in VCG format (same as /vcg switch).
      Only  one  of  the formats tree, reference, or vcg may be speci-
 fied.
      The following keywords control options affecting the output:
    prune: prune repeated subtrees (applicable only with tree).   This
        the default.
    sort: sort children of each routine into alphabetical order.  This
        is the default.
      See the discussion of the /reference and /vcg flags for  details
 about these formats.
      For tree format, The call graph is printed out starting from the
 main program, which is listed on the first line at the  left  margin.
 Then  on the following lines, each routine called by the main program
 is listed, indented a few spaces, followed by the subtree starting at
 that routine.
      In  the  default  mode,  if a routine is called by more than one
 other routine, its call subtree is printed only the first time it  is
 encountered  Later  calls  give  only the routine name and the notice
 ''(see above)''.  To have the subtree printed for each occurrence  of
 the routine, use option no-prune.
      Note  that  the call tree will be incomplete if any of the input
 files are project files containing more than  one  module  that  were
 created in /library mode.  See the discussion of project files below.
      Technical points: Each list of routines called by a  given  rou-
 tine  is  printed  in alphabetical order unless the no-sort option is
 given.  If multiple main programs are found, the call tree of each is
 printed  separately.   If  no main program is found, a report to that
 effect is printed out, and the call trees of  any  top-level  non-li-
 brary  routines are printed.  This flag only controls the printing of
 the call tree: ftnchek constructs the call tree in any  case  because
 it  is used to determine which library modules will be cross-checked.
 See the discussion of the /library flag.
      For compatibility with previous versions of ftnchek,  a  numeric
 form of this setting is also accepted: the list is replaced by a num-
 ber from 0 to 15.  This number is formed from 1 for  tree  format,  2
 for reference format, or 3 for vcg format, plus 4 for no-prune, and 8
 for no-sort.
      See also: /crossref, /library, /reference, /sort, /symtab, /vcg.


3 /check
       This switch is provided so that errors and warning messages can
 be turned off when ftnchek is used for purposes  other  than  finding
 bugs,  such  as making declarations or printing the call tree.  It is
 positional, so after turning all checks off, selected checks  can  be
 turned  back  on.  The effect of /nocheck is to put all switches, nu-
 meric settings, and settings controlling lists of warnings  to  their
 turn-off  values, as if they had all been specified with the /no pre-
 fix.  Switches and settings that specify options and modes of  opera-
 tion,  rather  than  controlling warnings, are unaffected.  These are
 /columns, /crossref, /include, /intrinsic, /library,  /list,  /maked-
 cls,  /novice,  /output,  /pointersize, /project, /quiet, /reference,
 /resources, /sort, /source, /symtab, /vcg, /version,  /wordsize,  and
 /wrap.  Default = yes.
      Parse  errors  (syntax  errors  due to unrecognized or malformed
 statements) are not suppressed by this switch, since the results  may
 be incorrect if ftnchek has not parsed the program correctly.
      There  are  some  miscellaneous errors and warning messages that
 are not controlled by any other switch, and so can be turned off only
 by  this  switch.  Note that using /check following /nocheck only has
 the effect of turning these special warnings back on,  and  does  not
 restore all the checks it turned off.  These warnings are:
    o Module contains no executable statements.
    o In free source form, missing space where space is required (e.g.
        between a keyword and an identifier) or  space  present  where
        none is allowed (e.g. within an identifier).
    o Zero or negative length specification in a data type declaration
        of the form type*len.
    o Invalid operand(s) in an expression.
    o Array assigned to scalar.
    o Type mismatch between DO index and bounds.
    o Undefined common block declared in SAVE statement.
    o Intrinsic function  explicitly  declared  with  an  incompatible
        type.
    o  Unknown  intrinsic function explicitly declared in an INTRINSIC
        statement.
    o Intrinsic function passed as a subprogram argument  is  not  de-
        clared in an INTRINSIC statement.
    o Intrinsic function or statement function invoked incorrectly.
    o Function does not set return value prior to RETURN statement.
    o Parameter constant value not evaluated (this is ftnchek's fault,
        and it is just informing you of the fact).
    o Entry point of a subprogram is later used as a different subpro-
        gram's name.
    o Unknown keyword used in an I/O statement.
    o  Illegal  label  reference (e.g. GOTO refers to a non-executable
        statement; I/O statement refers to a non-format statement).
      See also: /errors.



3 /columns=num
       Set maximum statement length to num columns.  (Beyond  this  is
 ignored.)   This  setting  is  provided to allow checking of programs
 which may violate the Fortran standard limit of 72  columns  for  the
 length  of  a  statement.   According to the standard, all characters
 past column 72 are  ignored.   If  this  setting  is  used  when  the
 /f77=long-line  option  is in effect, a warning will be given for any
 lines in which characters past column 72 are  processed.   Turn-on  =
 max = 132.  Default = 72.
      This  setting  does  not suppress warnings about the presence of
 characters beyond column 72.  To process code with meaningful program
 text  beyond  column  72,  use  this  setting  and  be  sure the /f77
 long-line option is off.  To process code with  sequence  numbers  in
 columns  73 to 80, leave the the columns setting at the default value
 and use the /pretty=no-long-line flag.
      See also: /f77, /pretty.


3 /common=list
       This setting controls the  strictness  of  checking  of  COMMON
 blocks.  By default, all warnings except volatile are turned on.
      The  list  consists  of  keywords separated by commas or colons.
 Since most of these warnings are on by  default,  include  a  keyword
 prefixed  by  no-  to turn off a particular warning.  There are three
 special keywords: all to turn on all the warnings, none to turn  them
 all  off, and help to print the list of all the keywords with a brief
 explanation of each.  If list is omitted, /common  is  equivalent  to
 /common=dimensions,exact,length,type,  and /nocommon is equivalent to
 /common=none.  The warning keywords with their meanings are  as  fol-
 lows:
    dimensions:  corresponding  arrays  in each declaration of a block
        must agree in size and number of dimensions.  This option only
        has an effect when used together with exact.
    exact:  the  comparison of two blocks is done variable-by-variable
        rather than simply requiring agreement  between  corresponding
        storage  locations.   Use  this if all declarations of a given
        COMMON block are supposed to be identical,  which  is  a  good
        programming practice.
    length:  warn  if different declarations of the same block are not
        equal in total length.  The Fortran 77 Standard requires  each
        named  common  block,  but  not  blank  common, to be the same
        length in all modules of the program.
    type: in each declaration of a given COMMON  block,  corresponding
        memory locations (words or bytes) must agree in data type.  If
        used together with exact, this will require that corresponding
        variables agree in data type.
    volatile: Assume that COMMON blocks are volatile.
      Many Fortran programmers assume that variables, whether local or
 in COMMON, are static, i.e. that once assigned a value,  they  retain
 that  value  permanently until assigned a different value by the pro-
 gram.  However, in fact the Fortran 77 Standard does not require this
 to be the case.  Local variables may become undefined between activa-
 tions of a module in which  they  are  declared.   Similarly,  COMMON
 blocks  may  become undefined if no module in which they are declared
 is active.  (The technical term for entities with  this  behavior  is
 ''automatic'',  but  ftnchek  uses  the word ''volatile'' since it is
 clearer to the nonspecialist.)  Only COMMON blocks declared in a SAVE
 statement, or declared in the main program or in a block data subpro-
 gram remain defined as long as the program is running.  Variables and
 COMMON  blocks  that  can  become  undefined at some point are called
 volatile.
      If the /common=volatile flag is turned on, ftnchek will warn you
 if  it finds a volatile COMMON block.  If, at the same time, the /us-
 age=com-block-volatile  option is turned on (which is  the  default),
 ftnchek  will  try to check whether such a block can lose its defined
 status between activations of the modules where it is declared.   ft-
 nchek  does  not  do a very good job of this: the rule used is to see
 whether the block is declared in two separated subtrees of  the  call
 tree.   For  instance,  this  would  be the case if two modules, both
 called from the main program, shared  a  volatile  COMMON  block.   A
 block  can  also become undefined between two successive calls of the
 same subprogram, but ftnchek is not smart enough to  tell  whether  a
 subprogram  can be called more than once, so this case is not checked
 for.
      The /common=volatile flag does not affect the way ftnchek checks
 the usage of local variables.
      For  compatibility with previous versions of ftnchek,  a numeric
 form of this setting is also accepted: the list is replaced by a num-
 ber  from  0  to  3.   A  value of 0 turns all the warnings off, 1 or
 greater turns on type, 2 or greater turns on length, and 3  turns  on
 dimensions  and  exact  also.   The  numeric  form cannot turn on the
 volatile option.
      See also: /library, /usage.


3 /crossref=list
       Prints cross-reference tables.  Default = none.
      The list consists of keywords separated  by  commas  or  colons.
 The keywords with their meanings are as follows:
    calls:  table lists each subprogram followed by a list of routines
        that call it.  This listing omits library modules that are not
        in  the  call tree of the main program.  The list is alphabet-
        ized.
    common: table lists each COMMON block followed by a  list  of  the
        routines  that  access it.  These listed routines are those in
        which some variables in the COMMON  block  are  accessed,  not
        simply  those  routines  that declare the block.  (To find out
        what routines declare a COMMON block but do not  use  it,  see
        the /usage flag.)
    labels:  table  lists  each label followed by a list of all refer-
        ences to it.  A label reference is denoted by the line  number
        and  statement  type  of  the referring statement.   The label
        list is in sequential order.  The references are listed in the
        order they are encountered in the program.
      See also: /calltree, /reference, /sort, /symtab, /vcg.


3 /declare
        If this flag is set, all identifiers whose datatype is not de-
 clared in each module will be listed.  This flag is useful for  help-
 ing to find misspelled variable names, etc.  The same listing will be
 given if the module contains an IMPLICIT NONE statement.   Default  =
 no.
      See also: /sixchar, /usage.


3 /division
        This  switch is provided to help users spot potential division
 by zero problems.  If this switch is selected, every division  except
 by  a  constant will be flagged.  (It is assumed that the user is in-
 telligent enough not to divide by a constant which is equal to zero!)
 Default = no.
      See also: /portability, /truncation.


3 /errors=num
        Set  the  maximum  number  of error messages in a ''cascade''.
 During checking of agreement of subprogram  arguments,  common  block
 declarations,  and  so forth, sometimes a single case will generate a
 long string of warnings.  Often  this  simply  indicates  some  other
 cause  than  a  genuine  item-by-item mismatch, such as for example a
 varible missing from one list.  So in such cases ftnchek stops print-
 ing  the warnings after the cascade limit is reached, and the trailer
 ''etc...'' is printed to indicate that there  were  more  errors  not
 printed.   If you think that these warnings are likely to be genuine,
 use this setting to see more of them.  Turn-on = default = 3,  max  =
 999.  A value of 0 means no limit.
      This  setting does not set an overall limit on the number of er-
 ror messages printed, only the number printed  in  any  one  cascade.
 Most types of warnings and error messages are not subject to the cas-
 cade effect and so are not affected by this  setting.   To  turn  off
 warnings generally, use the individual warning control options or the
 /nocheck option.
      See also: /check.


3 /extern
       Causes ftnchek to report whether any subprograms invoked by the
 program  are never defined.  Ordinarily, if ftnchek is being run on a
 complete program, each subprogram other than the intrinsic  functions
 should  be  defined somewhere.  Turn off this switch if you just want
 to check a subset of files which form part of a larger complete  pro-
 gram.   Subprogram  arguments  will still be checked for correctness.
 Default = yes.
      The /extern flag is now superseded by  the  /usage=ext-undefined
 option.   For  the sake of convenience, the /extern flag is retained,
 so that /noextern is equivalent  to  /usage=no-ext-undefined  option.
 The /extern switch may be retired eventually.
      See also: /library.


3 /f77=list
       Use this setting to catch language extensions which violate the
 Fortran 77 Standard.  Such extensions may cause your program  not  to
 be  portable.   Examples  include  the use of underscores in variable
 names; variable names longer than  six  characters;  statement  lines
 longer  than 72 characters; and nonstandard statements such as the DO
 ... ENDDO structure.  ftnchek does not report on the use of lowercase
 letters.  By default, all warnings are turned off.
      This  setting  provides detailed control over the warnings about
 supported extensions to the Fortran 77 Standard.  The  list  consists
 of  keywords  separated by commas or colons.  There are three special
 keywords: all to turn on all the warnings  about  nonstandard  exten-
 sions,  none  to turn them all off, and help to print the list of all
 the keywords with a brief explanation of each.  If list  is  omitted,
 /f77   is  equivalent  to  /f77=all,  and  /nof77  is  equivalent  to
 /f77=none.  The warning keywords with their meanings are as follows:
    accept-type: ACCEPT and TYPE I/O statements.
    array-bounds: Expressions defining array bounds that contain array
        elements or function references.
    assignment-stmt:  Assignment statements involving arrays.  In For-
        tran 90, an array can be assigned to another array of compati-
        ble  shape,  or a scalar can be assigned to an array.  Neither
        of these assignments is permitted in Fortran 77.

     A related warning occurs when an array is assigned to  a  scalar.
 Since  this  is illegal also in Fortran 90, it is always warned about
 regardless of the /f77 setting (unless all  checking  is  turned  off
 with the /nocheck flag).
    attribute-based-decl:  Type declarations in the new Fortran 90 at-
        tribute-based style.  This style  of  declaration  is  distin-
        guished  by the use of a double colon (::) between the list of
        attributes and the list of declared  variables.   This  option
        also  controls  warnings  for use of Fortran 90 length or kind
        specifiers in type declarations.  (Although  these  specifiers
        can be used in non-attribute-based declarations, they are con-
        trolled by this option to  avoid  proliferation  of  /f77  op-
        tions.)
    automatic-array:  Local  (not  dummy)  arrays  which have variable
        size.  These would correspond to arrays  whose  storage  would
        have to be dynamically allocated at run time.
    backslash: Unix backslash escape in strings.  This warning will be
        given only if the /source=unix-backslash setting is  specified
        to cause the escape interpretation of backslash..
    byte: BYTE data type declaration.
    case-construct: The SELECT CASE construct.
    character: Extensions to the Fortran 77 standard regarding charac-
        ter data.  At present, this only controls warnings about char-
        acter  variables  declared  with  zero or negative length.  In
        Fortran 77,  all  character  variables  must  be  of  positive
        length.   In Fortran 90, they can be zero length, and declara-
        tions that specify negative lengths are permitted, turning in-
        to  zero  for  the  declared  length.   Note: because negative
        length specifiers may indicate a programming error, the  warn-
        ing about them is given even if this option is turned off, and
        is suppressed only by the /nocheck flag.
    common-subprog-name: Common block and subprogram having  the  same
        name.
    construct-name:  Use of a construct-name to label a control state-
        ment.
    continuation: More than 19 successive continuation lines.
    cpp: Unix C preprocessor directives in the source code.
    cray-pointer: ''Cray pointer'' syntax.
    cycle-exit: The CYCLE and EXIT statements.
    d-comment: Debugging comments starting with D in the source  code.
    dec-tab:  DEC Fortran style tab-formatted source code.  This warn-
        ing will be given only if the /source=dec-tab setting is spec-
        ified to cause interpretation of tabs in this style.
    do-enddo:  DO  loop  extensions: terminal statement label omitted,
        END DO, and WHILE.
    double-complex: Double precision complex datatype.
    format-dollarsign: Dollar sign control code in FORMAT  statements.
    format-edit-descr:  Nonstandard  edit descriptors in FORMAT state-
        ments.
    function-noparen: Function definition without parentheses.
    implicit-none: IMPLICIT NONE statement.
    include: INCLUDE statement.
    inline-comment:  Inline  comments  starting  with  an  exclamation
        point.
    internal-list-io: List-directed I/O to or from an internal file.
    intrinsic: Nonstandard intrinsic functions.
    io-keywords  Nonstandard  keywords  used in I/O statements.  These
        fall into three groups.  The  first  group  includes  keywords
        that are accepted in Fortran 90:
                        ACTION    PAD        READWRITE
                        ADVANCE   POSITION   SIZE
                        DELIM     READ       WRITE
                        EOR
        The second group comprises the following VMS Fortran keywords:
                BLOCKSIZE         EXTENDSIZE       READONLY
                BUFFERCOUNT       INITIALSIZE      RECORDSIZE
                CARRIAGECONTROL   MAXREC           RECORDTYPE
                DEFAULTFILE       NAME (in OPEN)   SHARED
                DISP              NOSPANBLOCK      TYPE
                DISPOSE           ORGANIZATION
        (The keyword NAME is standard only in the INQUIRE  statement.)
        The third group consists of the following IBM/MVS keyword:
                                 NUM
        This  flag  also  controls  a warning about use of ACCESS='AP-
        PEND', which is accepted by some compilers.  The value of 'AP-
        PEND'  is  not valid for any I/O specifier in standard Fortran
        77, and in Fortran 90 'APPEND' should be used as  a  value  of
        the POSITION specifier, not  ACCESS.
    long-line:  Statements with meaningful code past 72 columns.  This
        warning is given only if the /columns setting has been used to
        increase the statement field width.
    long-name: Identifiers over 6 characters long.
    mixed-common:  Mixed  character  and  noncharacter  data in COMMON
        block.
    mixed-expr: Nonstandard type combinations in expressions, for  ex-
        ample  DOUBLE  PRECISION  with COMPLEX, assigning hollerith to
        integer, logical operations on integers.
    name-dollarsign: Dollar sign used as a character in identifiers.
    name-underscore: Underscore used as a character in identifiers.
    namelist: NAMELIST statement.
    param-implicit-type: Implicit typing of a parameter  by  the  data
        type  of  the  value assigned.  This warning can only occur if
        implicit  parameter  typing  has  been  turned   on   by   the
        /source=param-implicit-type option, or if the PARAMETER state-
        ment is of the nonstandard form without parentheses.  If  this
        option is turned on, then any instances where implicit parame-
        ter typing occurs will be warned about.  If  you  want  to  be
        warned  only  in  those instances where the implicit data type
        differs from the default type, use  /portability=param-implic-
        it-type  instead.   According  to the Fortran 77 standard, the
        data type of a parameter is given by the same rules as  for  a
        variable,  and if necessary a type conversion is done when the
        value is assigned.
    param-intrinsic: Intrinsic function or exponentiation  by  a  real
        used to define the value of a PARAMETER definition.
    param-noparen:  PARAMETER statement without parentheses.  The user
        should be aware that the semantics of this form of the  state-
        ment differs from that of the standard form: in this form, the
        parameter takes its data type from the value assigned,  rather
        than having its default data type based on the first letter of
        the parameter name.  (This form of the PARAMETER statement was
        introduced  by DEC before the Fortran 77 standard was defined,
        and should be avoided.)
    pointer: Fortran 90  standard  pointer-related  syntax,  including
        POINTER,  TARGET  and ALLOCATABLE type declarations, ALLOCATE,
        DEALLOCATE, and NULLIFY statements, and pointer assignment us-
        ing =>.
    quad-constant:  Quad  precision  real  constants, e.g. of the form
        1.23Q4.
    quotemark: Strings delimited by quote marks rather  than  apostro-
        phes.
    relops: Relational (comparison) operators composed of punctuation,
        namely: < <= == /= > >=.
    semicolon: Semicolon used as statement separator.
    statement-order: Statements out of the sequence  mandated  by  the
        Standard.   The  allowed sequence is illustrated in Table 1 in
        the section on Interpreting the Output.
    typeless-constant: Typeless constants, for example Z'19AF'.
    type-size: Type declarations specifying a size,  for  example  RE-
        AL*8.
    variable-format:  Variable  repeat  specification or field size in
        FORMAT.  These are of the form < expr >.
    vms-io: Obsolete.  Now has the same  meaning  as  the  io-keywords
        keyword.
      See  also: /f90, /f95, /portability, /pretty, /style, /wordsize.


3 /f90=list
       This setting provides detailed control over the warnings  about
 supported extensions to the Fortran 77 Standard that were not adopted
 as part of the Fortran 90 Standard.  Note that ftnchek does not  sup-
 port  the  full  Fortran  90 language.  However, it does support some
 common extensions to Fortran 77 that were prevalent before Fortran 90
 was  defined.  Some of these extensions became part of the Fortran 90
 Standard, but others did not.  The /f90 setting warns only about  the
 latter.  That is, this flag covers things that are neither legal For-
 tran 77 nor legal Fortran 90.  Therefore, the warnings controlled  by
 this  flag are basically a subset of the warnings controlled by /f77.
 There are a few cases, described below, where  the  circumstances  in
 which  the warning is given are slightly different for the two flags.
      The list consists of keywords separated  by  commas  or  colons.
 There  are  three  special  keywords: all to turn on all the warnings
 about nonstandard extensions, none to turn them all off, and help  to
 print  the list of all the keywords with a brief explanation of each.
 If list is omitted, /f90 is equivalent to  /f90=all,  and  /nof90  is
 equivalent to /f90=none.
      The  following  keywords have identical meanings for /f90 as for
 /f77.  The reader is referred to the explanations under /f77.
          accept-type   double-complex        param-noparen
          backslash     format-dollarsign     cray-pointer
          byte          format-edit-descr     quad-constant
          cpp           function-noparen      type-size
          d-comment     name-dollarsign       variable-format
          dec-tab       param-implicit-type   vms-io
      The keywords which differ somewhat from the  corresponding  /f77
 keywords are as follows.
    continuation:  The limit on the number of continuation lines for a
        statement in fixed source form is the same, namely 19, in For-
        tran  90  as in Fortran 77.  For free source form the limit is
        39 continuation lines, and a line  containing  a  continuation
        mark cannot be otherwise empty or contain only a comment.
    intrinsic:  This  is the same as for /f77 except for the intrinsic
        functions defined in MIL-STD 1753, which are all  included  in
        Fortran  90, and so are not warned about.  (See /intrinsic for
        a list.)
    io-keywords: This is the same as for /f77 except that no  warnings
        are  given  for  the I/O keywords that are standard in Fortran
        90.
    long-line: Although the Fortran 90 Standard  allows  lines  longer
        than 72 characters in free source form, this restriction still
        applies to fixed source form.  In free source  form  the  line
        length limit is 132 characters, and unlike fixed form, ftnchek
        does not allow this limit to be increased.
    mixed-expr: This is the same as for /f77  except  for  expressions
        mixing  extended precision real with complex data types, which
        are permitted in Fortran 90.
    statement-order: This is similar to the corresponding  /f77  warn-
        ing, but applies the somewhat looser restrictions on statement
        order of the Fortran 90 Standard.  In particular,  Fortran  90
        allows  DATA  statements and statement-function definitions to
        be intermixed with specification statements.
    typeless-constant: In Fortran 90, binary, octal,  and  hexadecimal
        constants  of the form B'ddd', O'ddd', and Z'ddd', respective-
        ly, are permitted.  Here 'ddd' represents a string of  digits.
        ftnchek  recognizes  these  forms, as well as a variant of the
        form X'ddd' for a hexadecimal constant, and other variants  in
        which  the  base  indicator  B,  O,  Z, or X follows the digit
        string.  These variants were not adopted in Fortran 90, so on-
        ly they are warned about when this flag is turned on.
      See  also: /f77, /f95, /portability, /pretty, /style, /wordsize.


3 /f95=list
       This setting provides  detailed  control  over  warnings  about
 standard  Fortran  77  features that were deleted from the Fortran 95
 Standard.  Unlike the /f77 and /f90 settings, these warnings apply to
 syntax which is legal Fortran 77.  However, since these features have
 been deleted from the Standard, it is possible that programs contain-
 ing them will be unacceptable to some newer compilers.
      The  list  consists  of  keywords separated by commas or colons.
 There are three special keywords: all to turn  on  all  the  warnings
 about  nonstandard extensions, none to turn them all off, and help to
 print the list of all the keywords with a brief explanation of  each.
 If  list  is  omitted,  /f95 is equivalent to /f95=all, and /nof95 is
 equivalent to /f95=none.  The warning keywords  with  their  meanings
 are as follows.
    real-do: A DO variable of any real numeric type.
    pause: The PAUSE statement.
    assign: The ASSIGN statement, assigned GOTO, or assigned format.
    h-edit: The H edit descriptor in a format.
      There is one other Fortran 77 syntax feature that was deleted in
 Fortran 95, namely  branching to an ENDIF from outside the IF  block.
 However,  ftnchek  is  unable to analyze program flow, and so it does
 not provide a warning for this.
      See also: /f77, /f90, /portability, /pretty, /style,  /wordsize.


3 /help
        Prints a list of all the command-line options with a short de-
 scription of each along with its  default  value.   This  command  is
 identical  in  function  to the ''?''  argument, and is provided as a
 convenience for those systems in which the question mark has  special
 meaning to the command interpreter.  Default = no.
      The  help listing also prints the version number and patch level
 of ftnchek and a copyright notice.
      Note: the ''default'' values printed in square brackets  in  the
 help  listing  are,  strictly speaking, not the built-in defaults but
 the current values after any environment options and any command-line
 options preceding the /help option have been processed.
      See  also:  /novice,  /version,  and help option of all settings
 that take a list of keywords.


3 /identifier-chars=list
       Define non-alphanumeric characters that may be used in  identi-
 fiers.   By  default, ftnchek only accepts the dollar sign and under-
 score as non-alphanumeric characters in identifier names.  The  char-
 acters  in the list replace whatever set of accepted non-alphanumeric
 characters was previously in effect.  Thus, if dollar sign or  under-
 score are not included in the list, they lose their status as accept-
 able characters.
      This option is provided to enable ftnchek to handle source files
 containing non-standard identifer names that may be needed, for exam-
 ple, to access certain operating system services.  See the section on
 Limitations  and Extensions for the treatment of identifiers contain-
 ing these characters in implicit typing.
      Using /noidentifer-chars turns off acceptance of non-alphanumer-
 ic characters entirely.
      See also: /source.


3 /include=path
       Specifies a directory to be searched for files specified by IN-
 CLUDE statements.  Unlike other command-line options, this setting is
 cumulative;  that  is,  if  it is given more than once on the command
 line, all the directories so specified are placed on a list that will
 be  searched in the same order as they are given.  The order in which
 ftnchek searches for a file to be included is: the current directory;
 the  directory  specified  by environment variable FTNCHEK_INCLUDE if
 any; the directories specified by any /include options; the directory
 specified  by environment variable INCLUDE; and finally in a standard
 system-wide directory (/usr/include for UNIX,  SYS$LIBRARY  for  VMS,
 and \include for MSDOS).
      See also: /f77, /source.


3 /intrinsic=list
       Controls whether ftnchek recognizes certain nonstandard intrin-
 sic functions as intrinsic.  The list consists of keywords  separated
 by  commas or colons.  Some of the keywords control whether to recog-
 nize certain groups of functions, and other keywords control the  ex-
 pected  syntax  for  invoking some nonstandard intrinsics.  Include a
 keyword to turn on recognition of the corresponding set of intrinsics
 or  to allow the corresponding syntax.  Include a keyword prefixed by
 no- to turn off that recognition.
      There are three special keywords: all  turns on  recognition  of
 all the nonstandard intrinsics (listed below) and accepts either syn-
 tax for those that have variations.  Use none to turn off recognition
 of  all nonstandard intrinsics except those noted below.  Use help to
 print the list of all the keywords with a brief explanation of  each.
 If  list  is omitted, /intrinsic is equivalent to /intrinsic=all, and
 /nointrinsic is equivalent to /intrinsic=none.
      The nonstandard intrinsic functions needed to support  the  non-
 standard  extended precision data types (double complex and quad pre-
 cision) are always recognized.  The intrinsics for the double complex
 data type are:
                    CDABS   CDSQRT   DREAL   ZLOG
                    CDCOS   DCMPLX   IMAG    ZSIN
                    CDEXP   DCONJG   ZABS    ZSQRT
                    CDLOG   DIMAG    ZEXP    ZCOS
                    CDSIN

 The intrinsics for the quad precision and quad complex types are:
                   CQABS    QARCOS   QEXT     QNINT
                   CQCOS    QARSIN   QEXTD    QPROD
                   CQEXP    QATAN    QFLOAT   QREAL
                   CQLOG    QATAN2   QIMAG    QSIGN
                   CQSIN    QCMPLX   QINT     QSIN
                   CQSQRT   QCONJG   QLOG     QSINH
                   DBLEQ    QCOS     QLOG10   QSQRT
                   IQINT    QCOSH    QMAX1    QTAN
                   IQNINT   QDIM     QMIN1    QTANH
                   QABS     QEXP     QMOD     SNGLQ

 The  keywords  controlling recognition of other nonstandard intrinsic
 functions are as follows:
    extra: recognize the following commonly available nonstandard  in-
        trinsics  (all  except  EXIT  and  LOC  are defined in MIL-STD
        1753):
                        BTEST   IBCLR   IEOR    ISHFTC
                        EXIT    IBITS   IOR     LOC
                        IAND    IBSET   ISHFT   NOT

    unix: recognize these common Unix-specific intrinsic functions:
                      ABORT    GMTIME   LTIME    SRAND
                      AND      IARGC    OR       SYSTEM
                      GETARG   IRAND    RAND     TIME
                      GETENV   LSHIFT   RSHIFT   XOR

    vms: recognize these common VMS-specific intrinsic functions:
                        DATE     IDATE   SECNDS   TIME
                        ERRSNS   RAN     SIZEOF

    iargc-no-argument: specify that IARGC may be invoked with no argu-
        ments.
    iargc-one-argument: specify that IARGC may be invoked with one ar-
        gument.
    rand-no-argument: specify that RAND and IRAND may be invoked  with
        no arguments.
    rand-one-argument: specify that RAND and IRAND may be invoked with
        one argument.
      The no-argument and one-argument keywords work as follows: turn-
 ing  the  option on causes ftnchek to accept the corresponding syntax
 for invocation of the function, without excluding the possibility  of
 the  alternative  syntax.   Turning  the option off causes the corre-
 sponding syntax not to be accepted.  If both options are turned on at
 once (the default), then either syntax is accepted.  Turning both op-
 tions off at once would not be meaningful.  These options have no ef-
 fect if recognition of Unix intrinsics has been turned off.
      Note  that  this  setting  does not control whether non-standard
 warnings are issued about these functions.  It controls  whether  the
 functions  are  assumed  to be intrinsic or not, which determines how
 their usage is checked.  When functions in any of these sets are  in-
 cluded,  their invocations will be checked according to the rules for
 the intrinsic functions; otherwise they will  be  checked  as  normal
 (user-written)  external  functions.   The  non-standard warnings are
 controlled by the /f77=intrinsic option.
      The default value of this setting is equivalent to

 /intrinsic=all,no-unix.
      Note: In versions of ftnchek prior to 2.10, the /intrinsic  flag
 took  a  numeric argument instead of a list of options.  For the sake
 of users who may have written scripts invoking ftnchek in  this  way,
 the  numeric form is still accepted.  The numeric form of the setting
 consists of three digits.  The ones digit selects the set of  intrin-
 sic  functions  to be supported.  The digit 0 selects only Fortran 77
 standard intrinsics plus those needed to support the nonstandard  ex-
 tended  precision  data types.  The digit 1 is equivalent to extra, 2
 is equivalent to extra,unix, and 3 is equivalent to  extra,vms.   The
 tens  digit of this setting controls the syntax of the RAND intrinsic
 function, and the hundreds digit controls the  syntax  of  the  IARGC
 function.   For these digits, specify 0 to require invocation with no
 argument, 1 to require one argument, and 2 to allow either form.
      See also: /f77.


3 /library
       This switch is used when a number of subprograms are  contained
 in  a file, but not all of them are used by the application.  Normal-
 ly, ftnchek warns you if any subprograms are defined but never  used.
 This switch will suppress these warnings.  Default = no.
      This  switch  also  controls  which  subprogram calls and COMMON
 block declarations are checked.  If a file is read with the  /library
 flag  in  effect,  the  subprogram calls and COMMON declarations con-
 tained in a routine in that file will be checked only if that routine
 is  in  the main program's call tree.  On the other hand, if the /li-
 brary switch is turned off, then ftnchek checks the  calls  of  every
 routine  by every other routine, regardless of whether those routines
 could ever actually be invoked at run time, and likewise  all  COMMON
 block declarations are compared for agreement.
      The  difference between this switch and the /usage=no-ext-unused
 option for subprograms is that the latter suppresses only the warning
 about routines being declared but not used.  The /library switch goes
 further and excludes unused routines processed while it is in  effect
 from all cross-checking of arguments and COMMON block declarations as
 well.
      (If there is no main program anywhere in the set of  files  that
 ftnchek  has  read,  so that there is no call tree, then ftnchek will
 look for any non-library routines that are not called  by  any  other
 routine,  and  use  these as substitutes for the main program in con-
 structing the call tree and deciding what to check.  If no such  top-
 level non-library routines are found, then all inter-module calls and
 all COMMON declarations will be checked.)
      See also: /arguments, /calltree, /common, /extern, /usage.


3 /list
       Specifies that a listing of the Fortran program is to be print-
 ed  out  with  line  numbers.  If ftnchek detects an error, the error
 message follows the program line with a caret ( ^  )  specifying  the
 location  of  the error.  If no source listing was requested, ftnchek
 will still print out any line containing an error, to aid the user in
 determining where the error occurred.  Default = no.
      See also: /output, \fB-symtab, fB-quiet.


3 /makedcls=list
        Prepare  a neatly-formatted file of declarations of variables,
 common blocks, and namelist lists,  for  possible  merging  into  the
 source  code.  The declarations are stored in a file of the same name
 as the source code, but with the extension changed to If no  declara-
 tions  are  written to the file, it is deleted to reduce clutter from
 empty files.
      If input comes from standard input, instead  of  a  named  file,
 then declarations are written to standard output.
      Variables  are declared in alphabetical order within each decla-
 ration class and type, with integer variables first, because of their
 later possible use in array dimensions.
      PARAMETER  statements are an exception to the alphabetical order
 rule, because the Fortran 77 Standard requires that  the  expressions
 defining parameter values refer only to constants and already-defined
 parameter names.  This forces the original source file order of  such
 statements to be preserved in the declaration files.
      Explicit declaration of variables is considered good modern pro-
 gramming practice.  By using compiler options  to  reject  undeclared
 variables,  misspelled variable names (or names extending past column
 72) can be caught at compile time.  Explicit declarations also great-
 ly  facilitate changing floating-point precision with filters such as
 and These programs are capable of changing types of  explicit  float-
 ing-point  type declarations, intrinsic functions, and constants, but
 because they do not carry out rigorous lexical and grammatical analy-
 sis  of  the  Fortran  source code, they cannot provide modified type
 declarations for undeclared variables.  Default setting = 0,  turn-on
 = 1.
      Various  options  for the form of the declarations file are con-
 trolled by the list, which consists of keywords separated  by  commas
 or  colons.  There are three special keywords: all to turn on all the
 options, none to turn them all off, and help to print the list of all
 the  keywords  with a brief explanation of each.  If list is omitted,
 /makedcls is equivalent to /makedcls=declarations (i.e.  produce  the
 declarations  file  using  the  default  options), and /nomakedcls is
 equivalent to /makedcls=none.
      For compatibility with previous versions of ftnchek,  a  numeric
 form  of  this  setting  is also accepted:  the list is replaced by a
 number which is the sum of the numbers in parentheses beside the key-
 words  in  the following list.  The warning keywords with their mean-
 ings are as follows:
    declarations (1): Write a declaration file.  (This is  implied  by
        any  of the other options, and can be omitted if any other op-
        tions are given.)
    undeclared-only (2): By default, all variables are included in the
        declaration  file.   With this option, include only variables.
        This setting is useful if you want  to  check  for  undeclared
        variables, since Fortran source files with all variables prop-
        erly declared will not result in a file.   With  this  option,
        common  blocks  and namelist lists will not be included in the
        declaration file, since by their nature they cannot  be  unde-
        clared.
    compact  (4):  The declarations are normally prettyprinted to line
        up neatly in common columns, as in the declaration files  out-
        put  by the Extended PFORT Verifier, This option value selects
        instead compact output, without column alignment.
    use-continuation-lines (8): Causes continuation lines to  be  used
        where  permissible.  The default is to begin a new declaration
        on each line.  This option is appropriate to use together with
        compact.
    keywords-lowercase (16): Output Fortran keywords in lowercase, in-
        stead of the default uppercase.
    vars-and-consts-lowercase (32): Output variables and constants  in
        lowercase,  instead  of  the  default  uppercase.    Character
        string constants are not affected by this option.
    exclude-sftran3 (64): Omit declarations of internal integer  vari-
        ables  produced  by  the  SFTRAN3 preprocessor, as part of the
        translation of structured Fortran statements to ordinary  For-
        tran.   These  variables  have six-character names of the form
        and where is a decimal digit.  Because they are  invisible  in
        the  SFTRAN3  source code, and will change if the SFTRAN3 code
        is modified, such variables should not be explicitly declared.
        Instead,  they  should just assume the default Fortran INTEGER
        data type based on their initial letter,
    asterisk-comment (128): Use an asterisk as the comment  character;
        the default is otherwise 'C'.
    comment-char-lowercase (256): Use 'c' instead of 'C' or '*' as the
        comment character.
    suppress-array-dimensions (512): Suppress dimensioning  of  arrays
        in  the  generated  declarations.  This option is for use with
        code lacking type declarations, to allow the declaration files
        to  be  inserted without change into the code.  Since the code
        will have dimension statements already, dimensioning the array
        variables  in  the  type statements of the declaration file is
        redundant.  This option should be  used  only  in  conjunction
        with  option  2 = undeclared-only because otherwise any arrays
        that were dimensioned in a type statement will lose their  di-
        mensioning.
    free-form  (1024): Produce declarations in free source form.  This
        mode is automatically used if the input source is  free  form.
        Use  this  option to produce declarations in free form even if
        the input is in fixed form.  Free form  declarations  are  in-
        dented  only  2 columns instead of 6, use the exclamation mark
        as the comment character, and indicate continuation  lines  by
        an ampersand at the end of the line to be continued.
      The declaration files contain distinctive comments that mark the
 start and end of declarations for each program  unit,  to  facilitate
 using  text  editor macros for merging the declarations back into the
 source code.
      The ftnchek distribution includes a program, dcl2inc, which pro-
 cesses  declaration files to produce files containing declarations of
 all COMMON blocks, in a form suitable for use as INCLUDE files.   See
 the man page for the details of its use.
      See also: /mkhtml.


3 /mkhtml=list
       Produce HTML documentation from source. Creates individual HTML
 files from ftnchek analysis and code comments. All  comments  immedi-
 ately  preceding  and following the function or subroutine definition
 are captured to the HTML file. No reformatting of source comments  is
 performed other than stripping of FORTRAN comment characters.  In ad-
 dition, the HTML file lists  the  local  variables  declared,  common
 block  variables used, functions and subroutines called, I/O unit us-
 age, and other information about each subprogram.  Usually  you  will
 also  want  to  specify /call=tree to create the root HTML file Call-
 Tree.html.  (Perhaps this file should be named index.html.)
      Various options for the form of the HTML files are controlled by
 the  list,  which consists of keywords separated by commas or colons.
 There are three special keywords: all to turn  on  all  the  options,
 none to turn them all off, and help to print the list of all the key-
 words with a brief explanation of each.  If list is omitted,  /mkhtml
 is  equivalent  to  /mkhtml=documents (i.e. produce the HTML document
 files using the default options), and  /nomkhtmls  is  equivalent  to
 /mkhtml=none.
      For the sake of simplicity, the options for /mkhtml are the same
 as those for /makedcls except for those that are inapplicable.  Like-
 wise,   a numeric form of this setting can be used, formed as the sum
 of the numbers in parentheses in the list below.   The  warning  key-
 words with their meanings are as follows:
    documents (1): Create the HTML documents.  (This is implied by any
        of the other options, and can be omitted if any other  options
        are given.)
    compact  (4):  The declarations are normally prettyprinted to line
        up neatly in common columns.  This option  value  selects  in-
        stead compact output, without column alignment.
    use-continuation-lines  (8):  Causes continuation lines to be used
        instead of beginning a new declaration on each line.  This op-
        tion is appropriate to use together with compact.
    keywords-lowercase (16): Output Fortran keywords in lowercase, in-
        stead of the default uppercase.
    vars-and-consts-lowercase (32): Output variables and constants  in
        lowercase,  instead  of  the  default  uppercase.    Character
        string constants are not affected by this option.
    exclude-sftran3 (64): Omit declarations of internal integer  vari-
        ables produced by the SFTRAN3 preprocessor, (See /makedcls for
        discussion.)
    suppress-array-dimensions (512): Suppress dimensioning  of  arrays
        in  the generated declarations.  This is normally undesirable,
        but is available if for some reason you do not want the  array
        dimensions to appear in the HTML.
    free-form  (1024):  Produce  variable  declarations in free source
        form.  This mode is automatically used if the input source  is
        free form.  This mainly affects the form of continuation lines
        if they are used.
      See also: /calltree, /makedcls.


3 /novice
       This flag is intended to provide more helpful output for begin-
 ners.  It has two effects:
    (a)  provides  an extra message to the effect that a function that
        is used but not defined anywhere might be an array  which  the
        user  forgot  to  declare  in a DIMENSION statement (since the
        syntax of an array reference is the same as that of a function
        reference).
    (b)  modifies the form of the error messages and warnings.  If the
        flag is turned off by /nonovice, these messages are printed in
        a style more resembling UNIX lint.
      Default = yes.


3 /output=filename
        This  setting  is provided for convenience on systems which do
 not allow easy redirection of output from programs.  When  this  set-
 ting  is  given, the output which normally appears on the screen will
 be sent instead to the named file.  Note, however,  that  operational
 errors of ftnchek itself (e.g. out of space or cannot open file) will
 still be sent to the screen.  The extension for the filename  is  op-
 tional,  and  if  no  extension  is given, the extension .lis will be
 used.


3 /pointersize=num
       Specifies the size of a ''Cray pointer''  variable  to  be  num
 bytes.  Default = turn-on = 4 bytes.
      The  pointer  size is used to inform precision mismatch warnings
 involving pointer variables, for example when a pointer is assigned a
 value  from  an allocation routine, or passed as a subprogram parame-
 ter.
      See also: /f77, /portability, /truncation, /wordsize.


3 /portability=list
       ftnchek will give warnings for a variety  of  non-portable  us-
 ages.   Examples include the use of tabs except in comments or inside
 strings, the use of Hollerith constants,  and  the  equivalencing  of
 variables  of  different  data  types.   This option does not produce
 warnings for supported extensions to the Fortran 77  Standard,  which
 may  also  cause  portability problems.  To catch those, use the /f77
 setting.  By default, all warnings are turned off.
      This setting provides detailed control over the  warnings  about
 possible  portability  problems.  The list consists of keywords sepa-
 rated by commas or colons.  There are three special keywords: all  to
 turn  on all the warnings about nonportable usages, none to turn them
 all off, and help to print the list of all the keywords with a  brief
 explanation  of each.  If list is omitted, /portability is equivalent
 to /portability=all, and /noportability is equivalent to  /portabili-
 ty=none.  The warning keywords with their meanings are as follows:
    backslash:  Backslash  character in strings.  Since some compilers
        treat the backslash as an escape character, its  presence  can
        cause problems even though it is used in a standard-conforming
        way.
    common-alignment: COMMON block variables not in  descending  order
        of storage size.  Some compilers require this ordering because
        of storage alignment requirements.
    hollerith: Hollerith constants (other than within FORMAT  specifi-
        cations).   The Hollerith data type is a feature of Fortran IV
        that has been deleted in the Fortran 77 standard.  It  is  su-
        perseded  by  the character data type.  Storing Hollerith data
        in variables of a numeric or logical data type is  nonportable
        due to differing word sizes.
    long-string:  String constants, variables, or expressions over 255
        chars long.
    mixed-equivalence: Variables of different data types equivalenced.
    mixed-size:  Variables  declared  with default precision used with
        variables given explicit precision,  in  expressions,  assign-
        ments,  or  as arguments.  For example, if a variable declared
        as REAL*8 is treated as equivalent to DOUBLE PRECISION.
    real-do: Non-integer DO loop index and bounds.  These can cause  a
        program's results to depend on the hardware characteristics of
        the particular computer used.
    param-implicit-type: Implicit typing of a parameter  by  the  data
        type  of  the  value  assigned, if it differs from the default
        type.  This warning can only occur if implicit parameter  typ-
        ing  has been turned on by the /source=param-implicit-type op-
        tion, or if the PARAMETER statement is of the nonstandard form
        without  parentheses.   If  this option is turned on, then any
        instances where implicit parameter typing occurs and where the
        implicit  type is different from the default type based on the
        first letter of the parameter name, will be warned about.  Im-
        plicit parameter typing can change the semantics of statements
        where the parameter is used, causing portability problems.
    tab: Tabs in source code.  Tabs  are  interpreted  differently  by
        different compilers.  This warning will be given only once, at
        the end of the file.
      See also: /f77, /f90, /f95, /pretty, /style, /wordsize.


3 /pretty=list
       Controls certain messages related  to  the  appearance  of  the
 source  code.  These warn about things that might make a program less
 readable or be deceptive to the reader.  By default, all warnings are
 turned on.
      This  setting  provides detailed control over the warnings about
 appearance.  The list consists of keywords  separated  by  commas  or
 colons.  Since all warnings are on by default, include a keyword pre-
 fixed by no- to turn off a particular warning.  There are three  spe-
 cial  keywords:  all to turn on all the warnings about misleading ap-
 pearances, none to turn them all off, and help to print the  list  of
 all  the keywords with a brief explanation of each.  If list is omit-
 ted, /pretty is equivalent to /pretty=all, and /nopretty  is  equiva-
 lent  to  /pretty=none.  The warning keywords with their meanings are
 as follows:
    alternate-return: A RETURN statement has a constant specifying  an
        alternate return point that is not between 0 and the number of
        dummy arguments that are labels.  This is legal, and  has  the
        same  effect  as a RETURN with no alternate return expression,
        but suggests that the programmer intended to use an  alternate
        return label that is not provided.
    embedded-space: Space embedded in variable names or in multi-char-
        acter operators such as **.
    continuation: Continuation mark following a comment line.
    long-line: Lines (except comments) over 72 columns in  width  (be-
        yond 72 is normally ignored by compiler).
    missing-space: Lack of space between variable and a preceding key-
        word.
    multiple-common: COMMON block declared in multiple statements.  No
        warning  is given if the statements are consecutive except for
        comment lines.
    multiple-namelist: NAMELIST declared in multiple  statements.   No
        warning  is given if the statements are consecutive except for
        comment lines.
    parentheses: Parentheses around a variable by itself.  As  a  sub-
        program  argument,  this makes the argument an expression, not
        modifiable by the subprogram.
      Note that in free source form, extra space and missing space are
 forbidden  by  the Fortran 90 Standard, and are not mere style viola-
 tions.  In this case the warnings are replaced by syntax  error  mes-
 sages, and can be turned off only by using /nocheck.
      See also: /f77, /portability, /style.


3 /project=list
        ftnchek  will create a project file from each source file that
 is input while this option is turned on.  The project  file  will  be
 given  the  same name as the input file, but with the extension .f or
 .for replaced by .prj.  (If input is from standard input, the project
 file is named Default = none.
      The  list  consists  of  keywords separated by commas or colons.
 There are three special keywords: all to turn  on  all  the  options,
 none to turn them all off, and help to print the list of all the key-
 words with a brief explanation of each.  If list is omitted, /project
 is  equivalent  to  /project=all,  and  /noproject  is  equivalent to
 /project=none.  The keywords with their meanings are as follows:
    create: Produce a project file.  The default is not to  produce  a
        project  file.  If this option is not turned on, the other op-
        tions have no effect.
    trim-calls: Trim the amount of information stored in  the  project
        file about subprogram declarations and calls.  This is the de-
        fault.  Turn this option off only in  rare  situations.   (See
        discussion below.)  The amount of trimming varies depending on
        the /library flag.  More information is trimmed if  that  flag
        is turned on.
    trim-common:  Trim  the number of common block declarations stored
        in the project file.  This is the default.  Turn  this  option
        off  only  in  rare situations.  (See discussion below.)  This
        option has no effect if the /library flag is turned off:  when
        not  in library mode, no trimming of common block declarations
        is done regardless of this option.
      A project file contains a summary of information from the source
 file,  for  use in checking agreement among FUNCTION, SUBROUTINE, and
 COMMON usages in other files.  It allows incremental checking,  which
 saves  time  whenever you have a large set of files containing shared
 subroutines, most of which seldom change.  You can run  ftnchek  once
 on  each file with the /project flag set, creating the project files.
 Usually you would also set the /library and /noextern flags  at  this
 time,  to suppress messages relating to consistency with other files.
 Only error messages pertaining to each file by itself will be printed
 at this time.  Thereafter, run ftnchek without these flags on all the
 project files together, to  check  consistency  among  the  different
 files.   All  messages  internal  to the individual files will now be
 omitted.  Only when a file is altered will a new project file need to
 be made for it.
      Naturally,  when  the /project option is turned on, ftnchek will
 not read project files as input.
      Ordinarily, the trim options should be left on when  you  intend
 to  create project files for future input to ftnchek.  Since trimming
 is on by default, this means that simply giving the command  /project
 with  no  option  list is the recommended mode.  The trim options are
 provided only as a convenience for those who  want  to  make  use  of
 project  files  for purposes other than checking the program with ft-
 nchek.  To use project files for their intended purpose, the trim op-
 tions should not be turned off.
      Project  files  contain  only  information  needed  for checking
 agreement between files.  This means that a project file is of no use
 if  all  modules  of  the  complete program are contained in a single
 file.
      A more detailed discussion is given  in  the  section  on  Using
 Project Files.


3 /pure
        Assume  functions  are ''pure'', i.e., they will not have side
 effects by modifying their arguments or variables in a COMMON  block.
 When  this  flag is in effect, ftnchek will base its determination of
 set and used status of the actual arguments on  the  assumption  that
 arguments passed to a function are not altered.  It will also issue a
 warning if a function is found to modify any of its arguments or  any
 COMMON variables.  Default = yes.
      When  this  flag is turned off, actual arguments passed to func-
 tions will be handled the same way as actual arguments passed to sub-
 routines.   This means that ftnchek will assume that arguments may be
 modified by the functions.  No warnings will be given if  a  function
 is found to have side effects.  Because stricter checking is possible
 if functions are assumed to be pure, you should turn  this  flag  off
 only if your program actually uses functions with side effects.


3 /quiet
       This option reduces the amount of output relating to normal op-
 eration, so that error messages are more apparent.   This  option  is
 provided  for  the convenience of users who are checking large suites
 of files.  The eliminated output includes the names of project files,
 and  the message reporting that no syntax errors were found.  It also
 eliminates some blank lines that are ordinarily included for clarity.
 (Some  of  this output is turned back on by the /list and /symtab op-
 tions.)  Default = no.
      Note: the way to remember the difference  between the /quiet and
 /brief  is  that /quiet doesn't suppress any warning-related informa-
 tion, whereas /brief does.
      See also: /brief.


3 /reference
       Specifies that a who-calls-who table be  printed.   This  table
 lists  each  subprogram  followed by a list of the routines it calls.
 This switch is equivalent to /calltree=reference.  Default = no.
      The reference list omits routines called by unused library  mod-
 ules.   Thus  it  contains  the same information as for the call-tree
 format, namely the hierarchy of subprogram calls, but  printed  in  a
 different way.  This prints out a breadth-first traversal of the call
 tree whereas /calltree=tree prints out a depth-first traversal.
      See also: /calltree, /crossref, /library, /sort, /symtab,  /vcg.


3 /resources
        Prints  the  amount of resources used by ftnchek in processing
 the program.  This listing may be useful in analyzing  the  size  and
 complexity  of  a program.  It can also help in choosing larger sizes
 for ftnchek's internal tables if they are too small to analyze a par-
 ticular program.  Default = no.
      In  this  listing,  the  term  ''chunk size'' is the size of the
 blocks of memory allocated to store the item in question, in units of
 the  size  of one item, not necessarily in bytes.  When the initially
 allocated space is filled up, more memory is allocated in  chunks  of
 this size.  The following is an explanation of the items printed:
    Total  number of lines of code, with separate totals for statement
        lines and comment lines.  Comment lines include lines with 'C'
        or '*' in column 1 as well as blank lines and lines containing
        only an inline comment.  Statement lines are all other  lines,
        including  lines  that  have  an inline comment following some
        code.  Continuation  lines  are  counted  as  separate  lines.
        Lines  in  include files are counted each time the file is in-
        cluded.
    Number of statements in the program, other than specification, da-
        ta, statement-function, FORMAT, ENTRY, and END statements.
    A  module  is any external subprogram, including the main program,
        subroutines, functions, and block data units.  This  count  is
        of  modules defined within the source, not modules referenced.
        Statement functions are not included.  A subprogram with  mul-
        tiple entry points is only counted once.
    Number  of  labels  attached to statements (often called statement
        numbers).  The total label count for  the  entire  program  is
        given, as well as the maximum number in any single subprogram.
    Number of characters used for storing identifier names.  An  iden-
        tifier is a variable, subprogram, or common block name.  Local
        names are those of local variables in  a  subprogram,  whereas
        global  names  refer  to subprogram and common block names, as
        well as dummy argument names and common variable names.  Actu-
        al  argument  text  (up to 15 characters for each argument) is
        also included here.  The space used for local names is not re-
        covered at the end of each module, so this number, like global
        space, grows until the whole program  is  analyzed.   Unfortu-
        nately,  this  figure  may  include some text stored more than
        once, although a heuristic is used that will avoid  duplicates
        in many cases.
    A  token  is  the  smallest syntactic unit of the FORTRAN language
        above the level of individual characters. For instance a token
        can  be  a  variable name, a numerical constant, a quoted text
        string, or a punctuation  character.   Token  text  is  stored
        while  a  module  is  being processed.  For technical reasons,
        single-character tokens are not included in this total.  Items
        that  are not represented in the symbol table may be duplicat-
        ed.  The space for token text is recovered at the end of  each
        module, so this figure represents the maximum for any one mod-
        ule.
    This is the largest number of entries in the  local  symbol  table
        for  any module.  Local symbol table entries include all vari-
        ables and parameters, common block names, statement functions,
        external subprograms and intrinsic functions referenced by the
        module.  Literal constants are not stored in the local  symbol
        table.
    This  is  the  number of entries in the global symbol table at the
        end of processing.  Global symbol table entries include exter-
        nal  subprogram  and  common block names.  Intrinsic functions
        and statement functions are not included.
    A token list is a sequence of tokens representing  the  actual  or
        dummy  argument list of a subprogram, or the list of variables
        in a common block or namelist.  Therefore this  number  repre-
        sents  the  largest  sum  of  COMMON, CALL, NAMELIST and ENTRY
        statements and function invocations for any one  module.   The
        space is recovered at the end of each module.
    This  is  the  largest number of tokens in all the token lists and
        token trees of any one module.  A token tree  is  formed  when
        analyzing  an  expression: each operand is a leaf of the tree,
        and the operators are the nodes.  Therefore this number  is  a
        measure  of  the  maximum  complexity of an individual module.
        For instance a module with many  long  arithmetic  expressions
        will  have  a  high  number.   Note that unlike token text de-
        scribed above, the number of  tokens  is  independent  of  the
        length  of  the variable names or literal constants in the ex-
        pressions.
    This is the sum over all modules of the number of CALL  statements
        and  function  invocations  (except  intrinsic  functions  and
        statement functions).
    This is the sum over all modules of the  number  of  common  block
        declarations.   That is, each declaration of a block in a dif-
        ferent module is counted  separately.   (The  standard  allows
        multiple declarations of a block within the same module; these
        are counted as only one declaration since they are  equivalent
        to a single long declaration.)
    This  is the sum over all modules of the number of array dimension
        and parameter definition text strings saved  for  use  by  the
        /makedcls  option.   The  length  of  the  text strings is not
        counted.  Each dimension of a multidimensional array is count-
        ed separately.
      These  numbers are obviously not the same when project files are
 used in place of the original source  code.   Even  the  numbers  for
 global entities may be different, since some redundant information is
 eliminated in project files.


3 /sixchar
       One of the goals of the ftnchek program is  to  help  users  to
 write  portable  Fortran programs.  One potential source of nonporta-
 bility is the use of variable names that are longer than six  charac-
 ters.   Some compilers just ignore the extra characters.  This behav-
 ior could potentially lead to two different variables  being  consid-
 ered  as the same.  For instance, variables named AVERAGECOST and AV-
 ERAGEPRICE are the same in the first six characters.  If you wish  to
 catch such possible conflicts, use this flag.  Default = no.
      Use the /f77=long-names if you want to list all variables longer
 than six characters, not just those pairs that are the  same  in  the
 first six.
      See also: /f77, /portability.


3 /sort
       Specifies that a sorted list of all modules used in the program
 be printed.  This list is in ''prerequisite'' order, i.e. each module
 is  printed  only  after all the modules from which it is called have
 been printed.  This is also called a ''topological sort'' of the call
 tree.  Each module is listed only once.  Routines that are not in the
 call tree of the main program are omitted.  If there are  any  cycles
 in the call graph (illegal in standard Fortran) they will be detected
 and diagnosed.  Default = no.
      See also: /calltree, /crossref, /reference, /symtab, /vcg.


3 /source=list
       This setting controls certain options about  the  form  of  the
 Fortran source code.  The list consists of keywords separated by com-
 mas or colons.  There are three special keywords: all to turn on  all
 the options, none to turn them all off, and help to print the list of
 all the keywords with a brief explanation of each.  If list is  omit-
 ted,  /source  is equivalent to /source=all, and /nosource is equiva-
 lent to /source=none.
      For compatibility with previous versions of ftnchek,  a  numeric
 form  of  this  setting  is also accepted:  the list is replaced by a
 number which is the sum of the numbers in parentheses beside the key-
 words in the following list.  (The fixed and free options do not have
 numeric values.)  The warning keywords with  their  meanings  are  as
 follows:
    fixed:  Interpret  the source as fixed form (with supported exten-
        sions such as exclamation mark for comments).  Statements must
        be  in columns 7 to 72 (unless the /cols setting has been used
        to change this), and blanks are not significant outside  char-
        acter  context  (but  warned  about under the /pretty option).
        This is the default mode unless the source file  extension  is
        .f90  or  .F90.   this  option  cannot  be given together with
        /source=free.
    free: Interpret the source as free form.  Statements may  be  any-
        where in columns 1 to 132, comments can only begin with an ex-
        clamation mark, and blanks are required in some places such as
        between identifiers and keywords.  This is the default mode if
        the source file extension is .f90 or .F90.  This option cannot
        be given together with /source=fixed or /source=dec-tab
    dec-tab (1): Accept DEC-style tab-formatted source.  A line begin-
        ning with an initial tab will be treated as  a  new  statement
        line unless the character after the tab is a nonzero digit, in
        which case it is treated as a  continuation  line.   The  next
        column  after  the tab or continuation mark is taken as column
        7.  A warning will be given in the case where the  line  is  a
        continuation, if /f77=dec-tab is in effect.
    vms-include  (2): Accept VMS-style INCLUDE statements.  These fol-
        low the normal syntax, but with the following additional  fea-
        tures:  (1)  the file extension, if not given, defaults to the
        same as a normal source file extension;  and  (2)  the  option
        /LIST  or /NOLIST can be appended to the include-file name, to
        control listing of its contents.
    unix-backslash (4): Handle UNIX-style backslash escapes in charac-
        ter strings.  The escape sequence following the backslash will
        be evaluated according to the ANSI standard for strings in  C:
        up  to three digits signify an octal value, an x signifies the
        start of a hexadecimal constant, any of the letters a b f n  r
        t  signify special control codes, and any other character (in-
        cluding newline) signifies the character  itself.   When  this
        source  code  option  is in effect, a warning will be given if
        the /f77=backslash setting is specified.

     The default behavior is to treat the  backslash  like  any  other
 normal  character,  but a warning about portability will be generated
 if the /portability flag is set.  Because of the fact that some  com-
 pilers  treat  the backslash in a nonstandard way, it is possible for
 standard-conforming programs to be non-portable if they use the back-
 slash character in strings.

     Since ftnchek does not do much with the interpreted string, it is
 seldom necessary to use this option.  It is needed in order to  avoid
 spurious  warnings  only  if (a) the program being checked uses back-
 slash to embed an apostrophe or quote mark in a string instead of us-
 ing  the  standard mechanism of doubling the delimiter; (b) the back-
 slash is used to escape the end-of-line in order to continue a string
 across  multiple  source lines; or (c) a PARAMETER definition uses an
 intrinsic string function such as LEN with such a string as argument,
 and that value is later used to define array dimensions, etc.
    param-implicit-type (8): Implicit typing of a parameter by the da-
        ta type of the value assigned.   Some  non-standard  compilers
        may  allow  the data type of the value to override the Fortran
        77 default type of a parameter that is based on the first let-
        ter of the parameter name.  This option only applies to PARAM-
        ETER statements of the standard form which has parentheses.  A
        parameter  that  has been explicitly declared in a type state-
        ment prior to the PARAMETER statement is not affected by  this
        option.   A warning will be given under the /f77=param-implic-
        it-type or /portability=param-implicit-type option.

     Note that this implicit typing is treated as equivalent to an ex-
 plicit  type  declaration  for  the parameter.  Therefore, if you use
 /makedcls=undeclared-only to generate declarations only of undeclared
 variables, these parameters will not be included.
    dec-param-standard-type  (16): Follow the Fortran 77 rule for data
        typing of DEC Fortran style parameters.   These  are  declared
        using  a  nonstandard  form  of  the PARAMETER statement which
        lacks parentheses.  According to DEC Fortran,  parameters  de-
        fined by this form of the statement have their data type given
        by the data type of the value assigned.  Use  this  option  to
        tell  ftnchek  not  to follow this rule but instead to use the
        same rule as for standard PARAMETER statements.   This  option
        does not apply to PARAMETER statements of the standard form.
      By default, all these source code options are turned off, except
 for the vms-include option, which is on by default in  the  VMS  ver-
 sion..
      See also: /f77, /include, /portability.


3 /style=list
        Provides  extra-picky  warnings about obsolescent or old-fash-
 ioned programming constructions.  This option is helpful for  efforts
 to follow a modern programming style.  (Most of the things complained
 about under this option are forbidden in the F subset language.)   By
 default, all warnings are turned off.
      The  list  consists  of  keywords separated by commas or colons.
 There are three special keywords: all to turn  on  all  the  options,
 none to turn them all off, and help to print the list of all the key-
 words with a brief explanation of each.  If list is  omitted,  /style
 is   equivalent   to   /style=all,  and  /nostyle  is  equivalent  to
 /style=none.  The warning keywords with their meanings  are  as  fol-
 lows:
    block-if: Complain about arithmetic IF statement.  Accept block IF
        or logical IF (which controls a single statement).
    construct-name: Complain about unnamed block constructs:  IF,  DO,
        and  SELECT CASE.  Note that if a construct name is present on
        the opening statement of a construct, then it is  required  to
        be  present  on  all other component statements (ELSE, END IF,
        etc.) of the construct.  In that case a missing construct name
        on  those  statements  generates  a syntax error regardless of
        this option.  The purpose of this option is  to  warn  if  the
        construct completely lacks the optional name.
    distinct-do:  Complain  if  two DO loops share a common terminator
        statement.
    do-construct: Complain if terminator of a DO loop is anything oth-
        er than an END DO or CONTINUE statement.  This is the require-
        ment in order for the loop to meet the Fortran  90  definition
        of a do-construct.
    do-enddo:  Complain  if  terminator of a DO loop is anything other
        than an END DO statement.  (This option overrides the  do-con-
        struct option, being even stricter.)
    end-name:  Complain  about  the  absence of the subprogram name on
        structured END statements.
    format-stmt: Complain about the  presence  of  FORMAT  statements.
        Only  the  FORMAT  statements  themselves are flagged, not the
        references to them in I/O lists.
    goto: Complain about the presence of  unconditional,  computed  or
        assigned  GOTO  statements.  Also complain about alternate re-
        turns (but not about labels as subprogram arguments).
    labeled-stmt: Complain about the presence of labels  (numbers)  on
        statements other than FORMAT statements.  (Since FORMAT state-
        ments are arguably convenient and  not  readily  abused,  com-
        plaints  about them are controlled by the separate format-stmt
        keyword.)
    program-stmt: Complain about the absence of a PROGRAM statement at
        the head of the main program.
    structured-end: Complain about the use of a plain END statement to
        end a subprogram, rather than a structured END statement  (END
        PROGRAM, END SUBROUTINE, END FUNCTION, or END BLOCK DATA).
      See also: /f77, /f90, /f95, /pretty, /portability.


3 /symtab
       A symbol table will be printed out for each module, listing all
 identifiers mentioned in the module.  This table gives  the  name  of
 each variable, its datatype, and the number of dimensions for arrays.
 An asterisk (*) indicates  that  the  variable  has  been  implicitly
 typed, rather than being named in an explicit type declaration state-
 ment.  The table also lists all subprograms invoked  by  the  module,
 all COMMON blocks declared, etc.  Default = no.
      Also, for each module, a label table will be printed.  The table
 lists each label defined in the module; the line on which said state-
 ment label is defined; and the statement type (executable, format, or
 specification).  The labels are listed in sequential order.
      Also printed is a table describing the I/O  units  used  by  the
 module, together with information about how they are used: what oper-
 ations are performed, whether the access is sequential or direct, and
 whether the I/O is formatted or unformatted.
      See  also: /calltree, /crossref, /list, /reference, /sort, /vcg.


3 /truncation=list
       Warn about possible truncation (or roundoff) errors.   Most  of
 these  are  related  to integer arithmetic.  By default, all warnings
 are turned on.
      This setting provides detailed control over the  warnings  about
 possible  truncation errors.  The list consists of keywords separated
 by commas or colons.  Since all warnings are on by default, include a
 keyword  prefixed by no- to turn off a particular warning.  There are
 three special keywords: all to turn on all the warnings about trunca-
 tion,  none  to  turn them all off, and help to print the list of all
 the keywords with a brief explanation of each.  If list  is  omitted,
 /truncation  is  equivalent  to /truncation=all, and /notruncation is
 equivalent to /truncation=none.   The  warning  keywords  with  their
 meanings are as follows:
    int-div-exponent:  use of the result of integer division as an ex-
        ponent.  This suggests that a real quotient is  intended.   An
        example would be writing X**(1/3) to evaluate the cube root of
        X. The correct expression is X**(1./3.).
    int-div-real: Conversion of an expression involving an integer di-
        vision to real.  This suggests that a real quotient is intend-
        ed.
    int-div-zero: division in  an  integer  constant  expression  that
        yields a result of zero.
    int-neg-power:  exponentiation of an integer by a negative integer
        (which yields zero unless the base integer is 1 in magnitude).
        This suggests that a real base is intended.
    promotion:  automatic  conversion of a lower precision quantity to
        one of higher precision.  The loss of accuracy for real  vari-
        ables in this process is comparable to the corresponding demo-
        tion.  No warning is given for promotion of integer quantities
        to real since this is ordinarily exact.
    real-do-index:  use of a non-integer DO index in a loop with inte-
        ger bounds.  An integer DO index with real  bounds  is  always
        warned about regardless of this setting.
    real-subscript: use of a non-integer array subscript.
    significant-figures:  overspecifying  a single precision constant.
        This may indicate that a double precision constant was intend-
        ed.
    size-demotion: automatic conversion of a higher precision quantity
        to one of lower precision of the same type.  This warning only
        occurs  when an explicit size is used in declaring the type of
        one or both operands in an assignment.  For example, a warning
        wil  be  issued  where a REAL*8 variable is assigned to a REAL
        variable, if the default wordsize of 4 is in effect.  A  warn-
        ing  is also issued if a long integer is assigned to a shorter
        one, for example, if an INTEGER expression is assigned  to  an
        INTEGER*2 variable.  There is one exception to this last case,
        namely if the right hand side of the  assignment  is  a  small
        literal  constant  (less  than 128).  type-demotion: automatic
        conversion of a higher precision quantity to one of lower pre-
        cision of different type.  This warning includes conversion of
        real quantities to integer, double precision to single  preci-
        sion  real,  and  assignment of a longer character string to a
        shorter one.
      The warnings about promotion and demotion also apply to  complex
 constants, considering the precision to be that of the real or imagi-
 nary part.  Warnings about promotions and demotions  are  given  only
 when  the  conversion  is  done automatically, e.g. in expressions of
 mixed precision or in an assignment statement.   If  intrinsic  func-
 tions  such  as INT are used to perform the conversion, no warning is
 given.
      See also: /portability, /wordsize.


3 /usage=list
       Warn about unused or possible uninitialized  variables,  unused
 common  blocks,  undefined  or unused statement labels, and unused or
 undefined subprograms.  By default, all warnings are turned on.
      This setting provides detailed control over the  warnings  about
 possible  usage  errors.   The list consists of keywords separated by
 commas or colons.  Since all warnings are on by  default,  include  a
 keyword  prefixed by no- to turn off a particular warning.  There are
 three special keywords: all to turn on all the warnings about  usage,
 none to turn them all off, and help to print the list of all the key-
 words with a brief explanation of each.  If list is  omitted,  /usage
 is  equivalent  to  /usage=all,  and  /nousage  is equivalent to /us-
 age=none.  These warnings cover four main categories of objects: sub-
 program dummy arguments, common blocks and variables, subprograms and
 functions, and local variables.  Warnings  include  undefined  items,
 multiply defined items, unused items, etc.  The warning keywords with
 their meanings are as follows:
    arg-alias: a scalar dummy argument is actually the same as another
        and is (or may be) modified.  The Fortran 77 standard (section
        15.9.3.6) prohibits modifying an argument that is  aliased  to
        another.
    arg-array-alias:  a dummy argument which is an array or array ele-
        ment is in the same array as another and  is  modified.   This
        flag  is  similar  to  arg-alias but provides separate control
        over array arguments.  It is harder to tell if aliasing is oc-
        curring  in  the  case of arrays, so if ftnchek gives too many
        false warnings, this flag allows the array-related ones to  be
        turned off without suppressing the warnings for scalars.
    arg-common-alias:  a scalar dummy argument is the same as a common
        variable in the subprogram, and either is modified.   This  is
        also  prohibited by the Fortran 77 standard.  If common check-
        ing is not exact (see the /common setting), it  is  harder  to
        tell  if aliasing is occurring, so the warning is given if the
        variable is anywhere in a common block that is declared by the
        subprogram.
    arg-common-array-alias:  a dummy argument which is an array or ar-
        ray element is in the same array as a common variable, and ei-
        ther  is modified.  If common checking is not exact, the vari-
        able can be anywhere in a common block that is declared by the
        subprogram.
    arg-const-modified:  a  subprogram modifies an argument which is a
        constant or an expression.  Such an action could cause  anoma-
        lous behavior of the program.
    arg-unused:  a dummy argument is declared but never used.  This is
        similar to the var-unused keyword described below, but applies
        only to arguments.
    com-block-unused: a common block is declared but none of the vari-
        ables in it are used by any subprogram.  This warning is  sup-
        pressed if the common strictness setting is 0.
    com-block-volatile:  a common block may lose the definition of its
        contents if common blocks are volatile.  This option only  has
        an  effect if the /common=volatile flag is in effect.  See the
        discussion of the /common setting above.
    com-var-set-unused: a common variable is assigned a value, but its
        value  is  not  used  by any subprogram.  This warning is sup-
        pressed if the common strictness setting is 0.
    com-var-uninitialized: a common variable's value is used  in  some
        subprogram,  but  is not set anywhere.  Unfortunately, ftnchek
        does not do a thorough enough analysis of the calling sequence
        to  know which routines are called before others.  So warnings
        about this type of error will only be given for cases in which
        a  variable  is  used in some routine but not set in any other
        routine.   Checking of individual COMMON variables is done on-
        ly  if  the  /common setting is 3 (variable by variable agree-
        ment).  This warning is suppressed if  the  common  strictness
        setting is 0.
    com-var-unused:  a common variable is declared but not used by any
        subprogram.  This warning is suppressed if the common  strict-
        ness setting is 0.
    do-index-modified:  a  variable  that is the index of a DO loop is
        modified by some statement within the range of the loop.   The
        Standard  permits an active DO variable to be modified only by
        the incrementation mechanism of the DO statement.
    ext-multiply-defined: an external (a subroutine  or  function)  is
        defined  more than once.  Definition of an external means pro-
        viding the body of its source code.
    ext-declared-only: a name is declared in an EXTERNAL statement  in
        some module, but is not defined or used anywhere.
    ext-undefined:  an external is used (invoked) but not defined any-
        where.  This option is equivalent to the /external  flag.   If
        the  subprogram  is  invoked more than once, those invocations
        will still be checked for consistency.
    ext-unused:  an  external  is  defined  (its  subprogram  body  is
        present)  but  it is not used.  A subprogram is considered un-
        used even if it is invoked by some  other  subprogram,  if  it
        cannot  be  called  from any thread of execution starting with
        the main program.  The agreement of the subprogram's arguments
        with  its invocations is still checked even if this warning is
        turned off.  If there is no main program, then this warning is
        issued  only  if the subprogram is not invoked anywhere.  This
        warning is suppressed in library mode, but  library  mode  has
        the additional effect of suppressing argument checking for un-
        used routines.
    label-undefined: a statement refers to a label that has  not  been
        defined.
    label-unused: a statement label is defined, but never referred to.
    var-set-unused: a local variable is assigned  a  value,  but  that
        value is not used.
    var-uninitialized:  a local variable's value may be used before it
        is assigned.  Sometimes ftnchek makes a mistake in  the  warn-
        ings  about local variable usage.  Usually it errs on the side
        of giving a warning where no problem exists, but in rare cases
        it  may  fail  to  warn where the problem does exist.  See the
        section on Bugs for examples.  If variables are  equivalenced,
        the  rule  used by ftnchek is that a reference to any variable
        implies the same reference to all variables it is equivalenced
        to.  For arrays, the rule is that a reference to any array el-
        ement is treated as a reference to all elements of the  array.
    var-unused:  a local variable is declared (for instance, in a type
        declaration) but is not used in the module.  Does not apply to
        dummy  arguments:  warnings  about  them are controlled by the
        keyword arg-unused described above.
      Note: In versions of ftnchek prior to 2.10, the /usage flag took
 a  numeric  argument  instead  of a list of options.  For the sake of
 users who may have written scripts invoking ftnchek in this way,  the
 numeric  form  is still accepted.  The numeric setting is composed of
 three digits.  The first digit  (hundreds  place)  controls  warnings
 about subprograms (functions and subroutines), the second digit (tens
 place) warnings about common blocks and common  variables,,  and  the
 third  digit (ones place) warnings about local variables.  Each digit
 controls warnings according to the convention that  a  1  means  warn
 about  undefined  items  and  variables that are used before set, a 2
 means warn about items that are unused, and a 3 means warn about both
 types.  These numbers are now converted to the appropriate values for
 the above-listed keywords, except for  com-block-volatile,  which  is
 not affected by the numeric argument.
      See also: /common, /declare, /extern, /library.


3 /vcg
        Produce the call graph in the form of a VCG graph description.
 This description is written to a separate file, with the same stem as
 the file containing the main program, and suffix This file is able to
 be given directly to to visualize the call graph.  (If input is  from
 the  standard  input,  then the graph description is sent to standard
 output.)  This switch is equivalent to /calltree=vcg.  Default =  no.
      The  VCG description as created is more complex than it need be.
 VCG allows graphs and nested subgraphs: each subroutine is created as
 a  subgraph  nested  inside its calling routines.  This allows you to
 interactively display subgraphs or summarise them.
      The option for was written by Dr.  Philip  Rubini  of  Cranfield
 University, UK.
      xvcg  is  a graph visualisation tool which runs under the X win-
 dows system.  It is freely available from  ftp.cs.uni-sb.de.  It  was
 written by G. Sander of the University of Saarland, Germany.
      See also: /calltree, /crossref, /reference, /sort.


3 /version
        This  option causes ftnchek to print a line giving the version
 number, release date, and patch level of the program.   If  no  files
 are given, it then exits.  If files are given, the effect of this op-
 tion is to include the patch level (normally omitted) in the  version
 information printed at the start of processing.  Default = no.
      See also: /help.


3 /volatile
       Assume that COMMON blocks are volatile.  Default = no.
      This  flag  is  superseded  by  /common=volatile,  and should no
 longer be used.  It may be eliminated in a future release of ftnchek.
      See also: /common, /usage.


3 /wordsize=num
        Specifies  the default word size to be num bytes.  This is the
 size of logical and single-precision numeric variables that  are  not
 given  explicit  precisions.   (Explicit precisions for non-character
 variables are an extension to the Fortran 77 Standard, and are  given
 by type declarations such as REAL*8 X.)  Double-precision and complex
 variables will be twice this value, and double complex variables four
 times.   Quad-precision constants and intrinsic function results will
 be four times this value.  Note that variables  declared  as  REAL*16
 will  be regarded as quad precision only if the word size is 4 bytes.
 Default = turn-on = 4 bytes.
      The word size value does not matter for  checking  standard-con-
 forming  programs  that  do  not declare explicit precisions for non-
 character variables or store Hollerith data in variables.  This  set-
 ting  also  does  not affect the default size of character variables,
 which is always 1 byte.  Hollerith constants also are assumed to  oc-
 cupy 1 byte per character.
      The  word size is used to determine whether truncation occurs in
 assignment statements, and to catch precision mismatches  in  subpro-
 gram  argument lists and common block lists.  The exact warnings that
 are issued will depend on the status of other flags.  Under both  the
 /portability=mixed-size  and  the /nowordsize flag, any mixing of ex-
 plicit with default precision objects (character expressions not  in-
 cluded) is warned about.  This applies to arithmetic expressions con-
 taining both types of objects, and to subprogram arguments and COMMON
 variables.   Under  control of the /truncation=demotion and promotion
 options, a warning is given for assignment  of  an  expression  to  a
 shorter variable of the same type, or for promotion of a lower preci-
 sion value to higher precision in an arithmetic expression or an  as-
 signment statement.
      Giving  a  word  size  of  0, or equivalently, using /nowordsize
 means that no default value will be assumed.  This is  equivalent  to
 specifying  /portability=mixed-size.   Use it to find cases of mixing
 default and explicit precision, for example to flag places where  RE-
 AL*8 is treated as equivalent to DOUBLE PRECISION.
      See also: /pointersize, /portability, /truncation.


3 /wrap=col
        Controls  the wrapping of error messages.  Long error messages
 that would run past the specified column will be broken up into sepa-
 rate  lines  between the words of the message for better readability.
 If turned off with /nowrap,  each  separate  error  message  will  be
 printed on one line, leaving it up to the display to wrap the message
 or truncate it.  Default = turn-on = 79.


2 Changing_the_defaults
       ftnchek includes two mechanisms for changing the default values
 of  all  options:  by defining environment variables or by creating a
 preferences file.  When ftnchek starts up, it looks in  its  environ-
 ment  for  any  variables  whose  names are composed by prefixing the
 string FTNCHEK_ onto the uppercased version of the option  name.   If
 such  a  variable  is found, its value is used to specify the default
 for the corresponding switch or setting.  In  the  case  of  settings
 (for  example, the /common strictness setting) the value of the envi-
 ronment variable is read as the default setting value.  In  the  case
 of  switches,  the default switch will be taken as true or yes unless
 the environment variable has the value 0 or NO.
      Note that the environment variable name must be constructed with
 the  full-length  option name, which must be in uppercase.  For exam-
 ple, to make ftnchek print a source listing by default, set the envi-
 ronment variable FTNCHEK_LIST to 1 or YES or anything other than 0 or
 NO.  The names FTNCHEK_LIS (not the full option name) or ftnchek_list
 (lower case) would not be recognized.

 The  way to set the environment variables on the VMS system is by us-
 ing the DEFINE command.  For example, to set the default /list switch
 to YES, give the command

          $ DEFINE FTNCHEK_LIST 1
      After  processing any environment variables, ftnchek looks for a
 preferences file containing options and settings.  It will search  in
 the  following order, using only the first file found: (1) .ftnchekrc
 in the current directory, (2) ftnchek.ini in the  current  directory,
 (3)  .ftnchekrc  in the user's home directory, (4) ftnchek.ini in the
 home directory.  If such a file is found, the options defined  in  it
 are used as defaults in place of the built-in defaults and overriding
 any defaults set in the environment..
      Each option or setting in the preferences file must be on a sep-
 arate  line.  They are given in the same form as on the command line,
 except without the initial slash.  The preferences file  can  contain
 blank  lines and comments.  Comments are introduced at any point in a
 line by a space character (blank or tab) or the  '#'  character,  and
 are terminated by the end of the line.
      Command-line  options  override the defaults set in the environ-
 ment or in the preferences file, in  the same way  as  they  override
 the built-in defaults.


2 Project_files
        This  section  contains  detailed  information  on  how to use
 project files most effectively, and how to avoid some pitfalls.
      One can divide the checks ftnchek does into two categories,  lo-
 cal and global.  Local checking is restricted to within a single rou-
 tine, and catches things  like  uninitialized  variables,  unintended
 loss  of  precision  in  arithmetic  expressions,  etc.  This sort of
 checking can be done on each subprogram independently.   Furthermore,
 local checking of a subprogram does not need to be repeated when some
 other subprogram is changed.  Global  checking  catches  things  like
 calling a subroutine with the wrong argument types, or disagreeing in
 common block declarations.  It requires looking at the whole  set  of
 subprograms interacting with each other.
      The  purpose of project files is to allow the local checking and
 global checking steps to be separated.  Assuming that each subprogram
 is in its own source file, you can run ftnchek once on each one to do
 local checking while suppressing global checking.  Then  ftnchek  can
 be run once on all the project files together to do the global check-
 ing.  The sample makefile below shows how to automate this task.  The
 ''.f.prj''  target  updates  a project file for a particular file any
 time the source file changes.   The  information  needed  for  global
 checking is saved in the project file.  The ''check'' target does the
 combined global checking.  Typically ''make check'' would repeat  the
 ''ftnchek  /project''  step only on changed source files, then do the
 global check.  This is obviously a big advantage for large  programs,
 when many subprograms seldom if ever change.
      It  is best when using project files to place each subprogram in
 a separate source file.  If each source file may  contain  more  than
 one  subprogram,   it  complicates  the  definition  of ''local'' and
 ''global'' checking because there is some inter-module checking  that
 is  contained  within a file.  ftnchek tries to do the right thing in
 this case, but there are some complications (described below) due  to
 the  trade-off  between avoiding re-doing cross-checks and preserving
 information about the program's structure.
      Ordinarily, to do the least amount of re-checking, project files
 should  be  created  with  the  /library  flag in effect and trimming
 turned on.  In this mode, the information saved in the  project  file
 consists  of  all subprogram declarations, all subprogram invocations
 not resolved by declarations in the same file, and  one  instance  of
 each  COMMON block declaration.  This is the minimum amount of infor-
 mation needed to check agreement between files.
      If the source file contains more than  one  routine,  there  are
 some  possible problems that can arise from creating the project file
 in library mode, because the calling hierarchy among routines defined
 within  the file is lost.  Also, if the routines in the file make use
 of COMMON blocks that are shared with routines in other files,  there
 will  not be enough information saved for the correct checking of set
 and used status of COMMON blocks and COMMON  variables  according  to
 the  /usage setting.  Therefore if you plan to use project files when
 /usage checking is turned on (which is the default situation), and if
 multiple  routines  in one project file share COMMON blocks with rou-
 tines in other files, the project files should be  created  with  the
 /library  flag  turned off.  In this mode, ftnchek saves, besides the
 information listed above, one invocation of each  subprogram  by  any
 other subprogram in the same file, and all COMMON block declarations.
 This means that the project file will be larger than  necessary,  and
 that  when it is read in, ftnchek may repeat some inter-module checks
 that it already did when the  project  file  was  created.   If  each
 project  file  contains only one module, there is no loss of informa-
 tion in creating the project files in library mode.
      Because of the possible loss of information entailed by creating
 a  project  file  with  the  /library  flag  in effect, whenever that
 project file is read in later, it will be treated as a  library  file
 regardless of the current setting of the /library flag.  On the other
 hand, a project file created with library mode turned off can be read
 in later in either mode.
      The  foregoing  discussion  assumes that the trimming options of
 the /project setting are turned on when the project file is  created.
 This  is  the  normal situation.  The no-trim options of the /project
 setting are provided in case one wants to use the project  files  for
 purposes other than checking the program with ftnchek.  For instance,
 one could write a Perl script to analyze the project files for infor-
 mation  about  how  the different subprograms are called.  You should
 not use the no-trim options to deal with the  issues  of  information
 loss  discussed  above, since they cause more information than neces-
 sary to be stored.  This makes the project files  bigger  and  causes
 ftnchek  to  do more work later when it reads them to check your com-
 plete program.  Ordinarily, you should use  the  /library  option  to
 control  how  much  information  to store for later use by ftnchek in
 checking your program.

































