Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.atnf.csiro.au/computing/software/miriad/progguide/node49.html
Дата изменения: Unknown
Дата индексирования: Tue Feb 5 09:25:16 2013
Кодировка:
Поисковые слова: http www.astronet.ru

Making Flint Quieter

Flint assumes that the programmer follows a fairly strict programming convention. If the programmer does not, then Flint can produce a voluminous number of warning messages. There are a number of switches which help quieten Flint to manageable proportions.

-c

Allow interwoven continuation and comment lines. Normally Flint generates warnings about this (even though it is standard FORTRAN) An unpleasant side effect of allowing interwoven comment and continuation lines is that comments are not copied to the listing file.

-d

Do not warn when variables are not explicitly declared. Normally Flint insists that all variables must be explicitly declared with a `REAL', `INTEGER', etc, statement.

-f

Do not generate warnings about lines greater than 72 characters long or with an odd number of quotes. When checking if a line is greater than 72 characters, Flint interprets tabs as if the equivalent number of spaces had been typed (the VMS compiler treats a tab as a single character, rather than as multiple spaces).

-h

By default, Flint does not understand hollerith data. The -h flag instructs Flint to recognize hollerith data as integers.

-j

Do not check if a variable has been initialized before being used. If a variable is not in a DATA, COMMON, PARAMETER or SAVE statement, and if it is not a dummy subroutine argument, then Flint normally attempts to check that the variable is initialized before it is used. It does this by checking that it is assigned to at a earlier line in the routine than where it is first used. This is not necessarily correct in routines with EQUIVALENCE statements, a maze of gotos, or which have conditional blocks within loops. Applying this same rule to subroutine arguments provides Flint with a technique for determining subroutine argument intent. Disabling initialization checking will also disable these intent-determining rules, and so should eliminate spurious warnings about inconsistent subroutine argument intent.

-k

Suppress warnings about common blocks with possible alignment problems.

-r

Do not warn about seemingly redundant variables. Redundant variables are those that are assigned to but never otherwise used. A common source of most messages is when a value returned by a subroutine is never used. For example, Flint will complain if you ignore values returned in an array used by a subroutine for scratch storage, or if values returned by a general subroutine are ignored in specific cases.

-s

Load definitions of FORTRAN-IV and specific intrinsic functions. By default, Flint only knows about the standard FORTRAN-77 generic intrinsic functions (e.g. COS, REAL, MAX). It does not know specific function names or obsolete FORTRAN-IV functions (e.g. DCOS, FLOAT, AMAX0). The `s' flag causes Flint to load the definitions of these as well.

-u

Do not generate a warning about variables which do not seem to be used. By default Flint produces such a warning for local variables (but not COMMON or PARAMETER variables).

-x

Allow extended subroutine and variable names. By default Flint warns if subroutine or variable names are longer than 8 characters, or if they contain underline or dollar characters. Using this flag allows names of arbitrary length, with dollar and underline characters.