Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.fortran
Subject: Re: Pseudo-FORTRAN -- f2c for the Macintosh
Message-ID: <6081@goanna.cs.rmit.oz.au>
Date: 3 Jun 91 05:02:41 GMT
References: <1991May30.040829.8696@eplrx7.uucp> <1017@DIALix.oz.au>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 48

In article <1017@DIALix.oz.au>, dent@DIALix.oz.au (Andrew Dent) writes:
> In <1991May30.040829.8696@eplrx7.uucp> leipold@eplrx7.uucp (Walt Leipold) writes:
> The biggest problem I encountered is the way the Mac stores
> integers, which causes major problems with arrays of different cell sizes
> being EQUIVALENCED.

> eg: INTEGER*2 little(2)
>     INTEGER*4 big
>      EQUIVALENCE (little,big)
>     little(1) = 10
>     little(2) = 99

> on VMS & MS-DOS, big would now have the value 6488074
> on Mac: 655459 because the bytes are stored in the opposite order to all
> FORTRAN implementations.

1.  INTEGER*2 and INTEGER*4 are not standard Fortran.  They have
    equivalents (INTEGER(KIND=...)) in Fortran 90, but not in Fortran 66
    nor in Fortran 77.  The Fortran 77 standard makes it very clear
    indeed that there is only *one* standard size of integer, and that
    - LOGICAL, INTEGER, and REAL all occupy exactly one "storage unit"
    - COMPLEX and DOUBLE PRECISION both occupy exactly two "storage units".
    Yes, this does mean that any Fortran compiler which has a mode in
    which REAL is 4 bytes and INTEGER is 2 bytes does not _in_that_mode_
    conform to the standard.

2.  EQUIVALENCE in Fortran 66 and Fortran 77 is just like tagless variant
    records in Pascal.  It is a device for re-using storage for any
    _one_ of several different things, _not_ a device for accessing
    storage several ways at once.  The standard makes it clear that when
    a value is assigned to an equivalenced variable, that variable
    becomes defined, and the variables associated with it become
    UNdefined.  So even if INTEGER*2 and INTEGER*4 were standard
    Fortran, after the assignment little(1) = 10, the value of 'big' is
    undefined and no conforming program could depend on it.

3.  The claim that "all Fortran implementations" use the (extremely
    sensible) "little-endian" byte order that the VAX and the 80*86 use
    is grossly at variance with the facts.  (Indeed, the Fortran 77
    standard very carefully omits EQUIVALENCEing character and non-
    character data precisely in order to conceal whatever relationship
    there may be between storage units and character storage units from
    conforming programs.)  IBM 370s use the same byte order as M680x0s.

-- 
Should you ever intend to dull the wits of a young man and to
incapacitate his brains for any kind of thought whatever, then
you cannot do better than give him Hegel to read.  -- Schopenhauer.