British Computer Society - Fortran Specialist Group

 Minutes of Meeting held at BCS Headquarters on Monday, 8th September 1980

Present:     G. L. Harding (Chairman)        ECMWF

D. Anderson                      St. Thomas' Hospital

P. A. Clarke                     Rothamsted Experimental Station

P. Craggs                        Hydrographic Dept., Taunton

J. L. Dyke                       Huntingdon Research Centre

D. A. Franklin                   Logica Ltd.

D. J. Holmes                     Rolls Royce Ltd., Bristol

J. Larmouth                      Salford University

C. Lazou                         University of London Computer Centre

D. H. Marwick                    Heriot-Watt University

J. D. Murchland                  35 Rectory Park, Sanderstead, Surrey

D. T. Muxworthy                  Edinburgh University

K. Normington                    Coventry Polytechnic

M. Nunn                          CCTA

G. O'Llions                      Shell International

N. Price                         Shell International

L. van Raalte                    M.O.D.

J. D. Wilson (Secretary)         Leicester University

1. Minutes of Previous Meeting [27 May 1980]

        The minutes were approved.

2. Matters arising

        Contrary to the statement at the end of section 4.1, it appears that ANSI

have initiated a participation fee of $100 per annum for principal and alternate

and $50 per annum for observers. It was agreed that the Fortran Specialist Group

would pay for one copy of the X3J3 minutes. The minutes and any other X3J3

literature available will be kept by D. Muxworthy: a list of all documents held

will be maintained by the group secretary.

3. X3J3 Activities

        A. Wilson sent his apologies for not being able to attend to report on the

recent X3J3 meeting. B. Meek expects to attend the Fort Lauderdale meeting,

13th-17th October 1980.

        J. Murchland said he felt X3J3 should address the weaknesses and shortcomings

of FORTRAN 77 with a view to revising it before defining a new FORTRAN 8X standard.

The main items of concern were:

- no INTEGER*4 etc. facility

- lack of a generalised DO loop

- lack of NAMELIST

- zero-trip DO

The last item can be dealt with by a compiler option but there is no standard way

of communicating with the compiler.

        D. Franklin was concerned that there was no acknowledgement of analogue -

digital conversion requirements in the language.

        J. Murchland agreed to collect together problems encountered with FORTRAN 77

compilers with a view to submitting an article for SIGPLAN Notices.

        A list of new language features recently provisionally adopted by X3J3

was given in the latest edition of FOR-WORD. It includes the following:

- variable-length Character Type

- Intrinsic Functions for Character handling

- global "COMMON" declaration

- generalised precision attribute

- variable array subscripts within declared range

4. Other Fortran Group Activities

4.1 ISO Fortran Experts Meeting ( - Amsterdam October 20th-23rd 1980)

        The U.K. delegation is expected to be A. Clarke, J. Reid, D. Muxworthy

and L. Schoenfelder (1 day). Anyone else interested is asked to get in touch

with D. Muxworthy. The items of particular interest to the U.K. are:

- significant blanks

- core-plus-modules, mechanism and interfaces

- error handling and structure of the core

- numerical precision

- Completeness or Conformity Module Proposal

J. Murchland pointed out that IEEE have published a very detailed and specific

proposal for numerical precision in the January 1980 edition of the IEEE Computer

Society's Journal "Computing". This is quite different from either Reid's or

Smith's proposal but is based on new hardware.

Completeness/Conformity Module

        A. Clarke discussed a number of prepared questions and answers on the Module.

A modified version is given in Appendix A. J. Larmouth questioned the desirability

of a separate module rather than going through the FORTRAN 77 text and filling in

the gaps.

4.2 Fortran Forum

        In view of the fact that the Dutch Group are holding a Fortran Forum on

Friday 24th October 1980 and the difficulty in arranging a British Forum on

a suitable date, it has been decided simply to arrange the next Fortran

Specialist Group meeting for Monday 27th October 1980. This will be mainly

to report and discuss the ISO meeting and it is hoped a number of X3J3 members

will be present. A detailed agenda and notice will be published in the Computer


5. BCS Business

5.1   BCS 80 (incorporating Datafair) will be held on lst-3rd July 1981 at the

Institute of Education, London. A call for papers has been made; Abstracts

by 21st November 1980; full paper (5000 words approx.) by 14th February 1981.

Details may be obtained from G. Harding.

1982 is the 25th anniversary of the BCS. Jubilee celebrations are being

organised. The AGM on 14th October 1982 will be combined with a technical

conference on the theme "The next 25 years".

5.2   The Algorithmic Languages Group has been re-formed to represent Algol 60,

Algol 68, Pascal and ADA. Several members of the Fortran Specialist Group

objected to this title which, it was felt, should thereby include Fortran!

6. Any Other Business

  (i)   IBM have announced a new compiler which will support FORTRAN 77.

 (ii)   A complete index to FORTRAN 77 has been published as a NPL Report -

        details from J. Murchland.

7. Next Meeting

        The next meeting will take place on Tuesday 28th October 1980 at the

BCS Headquarters (see 4.2 above).

N.B. The meeting was originally arranged for Monday 27th October but has

been changed to avoid a clash with a meeting in Oxford.


Draft Question-Answer notes about Conformity Module proposal

Q1.   Does the Conformity Module prevent a supplier from extending Fortran as

      he pleases?

A1.   No, it does not. The Conformity Module is an optional module. If the

user does not request its invocation, then the Fortran system may be

exactly the same as current implementations, i.e. standard Fortran plus

supplier extensions.

If the user does invoke the Conformity Module then it is likely that this

would prevent some extensions.

Q2.   Is the Conformity Module much of an overhead?

A2.   No. Most of the features in the Conformity Module already exist in most

implementations. The efficiency of Fortran should not be affected


Q3.   Does the Conformity Module trap all non-standard occurrences (or all non-

standard status conditions)?

A3.   No. It is currently impractical to do this for reasons of efficiency etc.

The proposal will include two lists, GREEN and RED: Items on the GREEN list

will be trapped and handled, items on the RED list may or may not be included

depending on the consensus view of the standards committee - some implementors

may have difficulty implementing these, many items almost certainly will not

be included because of efficiency reasons or because they are outside the

scope of current processors or because they require re-design of some core-

Fortran feature. The long-term aim of the conformity module proposal is

to be able to trap as many non-standard status conditions as possible but

this will not happen overnight.

Q4.   Will the Conformity Module put restrictions on implementation methods

e.g. in the way statements must be passed or whether statements must be

compiled or interpreted?

A4.   It may cause some restrictions, but it is hoped that the features included in

the GREEN list will cause very few.

Q5.   Will the Conformity Module hinder the future development of Fortran?

A5.   No. It may help it. By making it easier for users to ensure their programs

are standard conforming, it will contribute to upwards compatibility of

programs. It will also highlight those features of Fortran which have been

designed without regard to safety and perhaps stimulate some improvement.

Q6.   Can a supplier extend the Conformity Module?

A6.   Yes. It's just the same as any other module in this respect. At the next

revision of the standard suppliers extensions may find their way into the

standard Conformity Module. Because of the restrictive nature of the

Conformity Module, extensions could only take the form of additional restrictions

Q7.   Is the Conformity Module a debug package.

A7.   No, not primarily. The main aim is to ensure conformity and safety. Debugging

may become slightly easier where a program is being developed on several

different machines at one time - because of greater consistency between

the processors. In general, debugging facilities in current processors

need not be changed.

Q8.   Can a program be standard conforming without the Conformity Module?

A8.   Yes it can. A standard conforming program.need only conform to the

Core-Fortran specifications.

Q9.   Could the majority of implementors agree on the content and actually

implement this module?

A9.   Yes. The items on the GREEN list have been implemented by a majority of

implementors already. If there are any serious problems with an item on

the GREEN list, it could be removed from the list. The GREEN list will

still contain a substantial number of items on which a consensus exists.

A. Clarke




  (Edited version of notes taken by J. Murchland

of a discussion by J. Larmouth, Salford University)

1. The NBS Study

        The United States National Bureau of Standards placed a contract with

Salford University for a a portability study of Fortran 77. The study has

taken a year, is largely complete, and will be published at least as a NBS

Software Engineering Handbook - contact J. Larmouth for details. (Of course

part of the impetus for placing the study was Dr. Larmouth's double article,

'Serious Fortran', Software - Practice and Experience 3 (1973) 87-107 and


        Excluded from the study were:

- the Fortran 77 language per se,

- Fortran 66 compatibility,

- the Fortran 77 subset.

        It was concerned with:

- bugs in F77 compilers, that is standard conforming F77 programs

  that a particular compiler won't accept,

- identifying, and rejecting, extensions made to the F77 language,

- establishing rules which ensure portability.

        The study looked at 10 individual compilers, 3 originating in the UK and

7 in the USA. (The IBM compiler, which has only just been announced, was not

included.) The individual compilers will not be identified in the final report.

It should be noted that many of the bugs found will be corrected by the suppliers

        At this time there is a test suite for the Fortran 77 subset, but not for

F77 itself.

2. Bugs found and their avoidance

        The study developed ten or so short programs which, between them, defeated

every compiler.

        Some of these bugs arise from the difficulty in distinguishing between

character and non-character arguments to subprograms. In F77, a character

argument must be passed as an address and a length. Ambiguities may arise if

non-character arguments are not also accompanied by a length-like quantity to

identify them clearly. This problem is severe for one-pass compilers.

        The examples are omitted in the notes below, and only the rule for avoiding

the trouble is given.

        (i)     Never put intrinsic functions in a TYPE statement.

        (ii)    One-pass compilers have difficulty sorting out subprogram arguments of

                type character. Users should declare all subprograms invoked by a

                subprogram in an External statement - this is also very good for


        (iii)   Problems arise with the file specifiers in OPEN statements for files

                which are already open or preconnected. The only remedy is to segregate

                OPENs so that they can be readily changed.

        (iv)    Right and left tabulations in Formats can give difficulty.

                (Remember that F77 does not specify that blanks are inserted by

                tabulation.) Users should avoid tabulations beyond the end of the


        (v)     In list-directed input/output, character constants extending over

                more than one line don't always work. Users should avoid this.

        (vi)    Some compilers won't accept a Parameter value with an exponent:

                A = 3.7**6. Users must simply avoid this.

        (vii)   For characters it is essential to use ASCII and not ISO-7(UK).

                This affects $#£ and ¢. Never use ISO-7(UK)!

        (viii)  Users should avoid overlapping Complex values by means of EQUIVALENCE.

        (ix)    Boundary alignment problems (different size of reals, integers etc.)

                are inescapable and users should prevent them in the usual ways.

                (Common Blocks restricted to one type only or variables in Common

                Blocks in order by decreasing size or numbers of variables of particular

                size or array dimensions made a multiple of 2 or 4 to ensure alignment.)

        (x)     Value and Reference Calls


        A = 4.0

        CALL FRED((A),A)          -- (A) to make expression

        END and so pass value


        C = 5.0

        PRINT *,B                 -- should give 4.0 not 5.0


                Don't be clever! Use another variable.

        Al = A

        CALL FRED(Al,A)

        (xi)     Users must be aware that concatenations of substrings may overflow

                (or appear to the compiler to overflow) the maximum allowed string

                size in the particular compiler.

3. Extensions offered by compilers which are not Fortran 77

        (i)     Mixing characters and integers in storage.

        (ii)    Integer*n

        (iii)   Only one Implicit statement and only one Type statement for a variable,

                and in the correct order (declaration before use).

        (iv)    Use distinct names for Common Blocks and for Parameters.

        (v)     Alternate returns from function subprograms are not part of Fortran 77

                and should not be used.

        (vi)    Do not:

                - use the extra keywords most compilers provide in OPENs,

                - allow more than one program to read the same file at the same time,

                - overlap Character assignments or Formats and Reads,

                - output prompts to a terminal by non-standard I/O statements,

                - use Namelist,

                - use Encode or Decode,

                - include a newline in list-directed input data within a complex


        (vii)   Avoid recursion.

        (viii)  Make no use of extended range of DOs.

        (ix)    Do not use Hollerith data. (Compilers will accept either the new

                character datatype or Hollerith, but get very confused with both.)

        (x)     Call Exit or Return must not be employed in a main program.

        (xi)    Do not call a subprogram with an array argument which is declared

                as a scalar variable within the subprogram.

        (xii)   Intrinsic functions must not be employed in Parameters.

4. General Portability Rules

        (i)     Don't exceed 255 characters in a string. (255 is the lowest value

                amongst the 10 compilers examined.)

        (ii)    Use only those intrinsic functions specified in the Fortran 77


        (iii)   In each function subprogram ensure that a value is always assigned

                to the function name (so that it is never left undefined).

        (iv)    Never allow undefined values to be copied. (For example don't read

                part of a vector and then, in another subroutine, copy the whole of

                it. This restriction reflects modern hardware, which may detect

                reference to an undefined variable.) It may be necessary to initialize

                all variables!

        (v)     Beware of side effects from function evaluation. Must F be called twice

                in A = F(X)+F(X) (for example, when F is a random number generator)?

                Even A = B*F(X) is borderline (if a zero value of B is detected and

                the multiplication skipped). A safe procedure is a simple assignment


        (vi)    Specify all floating-point constants with the largest number of digits

                which could ever be relevant on any machine and in double precision.

                (Fortran 77 allows this, but note that the subset does not.)

        (vii)   Use parentheses freely to ensure that exactly the numerical result

                desired is obtained.

        (viii)  Provision of check-output which program must produce, character by

                character, is difficult (owing to the freedom which the standard allows

                in overflowed fields).

        (ix)    Don't assign a real value to a double precision variable in a Data


        (x)     Intrinsic and External declarations should be used freely. Declare

                every subprogram as External (to avoid a clash with an idiosyncratic

                intrinsic function which would silently replace it).

        (xi)    Use SAVE in every routine.

        (xii)   Don't make use of lists in Assigned G0 TOs.

        (xiii)  Do-loops on a real variable have an uncertain number of repetitions

                unless the upper limit is adjusted by an appropriate rounding constant

                (for an increasing loop add half the increment).

        (xiv)   Avoid ENDFILE,STATUS=UNKNOWN. Avoid an INQUIRE after an ERR= .

                Avoid any reliance on ERR= for detecting the output of numbers which

                are too large (print as ***...*).

        (xv)    Trap errors on NEW by first deleting. Always use REWIND at start, and

                in an OPEN always specify the blank significance option (Blank = ) .

        (xvi)   Similarly, always specify SP or SS in Formats and don't rely on the


        (xvii)  Don't try to be clever (unless essential).

        (xviii) Don't use the + printer control character in formats to obtain

                overprinting (this still has no uniform significance).

        (xix)   Don't assume that the DELETE keyword actually deletes a file from the

                file system. (It may only detach it from the job, and hence it isn't

                possible to write a private operating and file system in FORTRAN 77.)

        (xx)    Never use lower case characters, even in Comments.

        (xxi)   Use LLT not .LT. etc. for characters.

        (xxii)  Don't use the CHAR or ICHAR functions (except on the way, via a table,

                to ASCII values).

        (xxiii) Parametrize all unit numbers.

        (xxiv)  It may be practical to use an Include/Insert facility, even though it

                is not standard. It was present in all compilers examined, and remember

                that Parameters are not global to the whole program, but only local to

                the subprogram in which they occur.

        (xxv)   Parametrize all program parameters. This new facility of F77 works and

                should be employed to the full.

        (xxvi)  Provide complete boundary alignment (as mentioned earlier).

        (xxvii) Don't use the IFIX, IDINT, FLOAT, SINGL, AMAX0, MAX2 etc. functions,

                which are likely to be deleted in the forthcoming Fortran 8x.

       (xxviii) Similarly, use C for comment, not *.

        (xxix)  Watch out for illegal definitions of the form F(A,A) when the arguments

                must be different variables.

        (xxx)   Do not rely on shortcut evaluation of logical expressions in IFs.

                For example

                     IF (X.EQ.0 OR. A.LE.W/X) ...

                must be split into separate IFs.