Xref: utzoo comp.arch:4829 comp.lang.fortran:661 comp.software-eng:561
Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!gatech!bloom-beacon!oberon!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: comp.arch,comp.lang.fortran,comp.software-eng
Subject: Re: Fortran follies
Message-ID: <1731@desint.UUCP>
Date: 15 May 88 00:20:48 GMT
References: <5377@cup.portal.com>
Reply-To: geoff@desint.UUCP (Geoff Kuenning)
Organization: Interrupt Technology Corp., Manhattan Beach, CA
Lines: 23

In article <5377@cup.portal.com> Paul_L_Schauble@cup.portal.com writes:

>      subroutine sub (a, b, n)
>      real a(1), b(1)			<-- note dimensions

Since variable dimensions have been part of standard Fortran for over ten
years, there is little excuse for using this older technique.  However, it
used to be very popular, so I suppose the customer has an argument in
expecting the compiler to support it.  Isn't the vectorizer smart enough
to see that the loop overruns the array?

>      common /one/ a(1)
>      common /two/ space(100 000)
>      common /tre/ alast

This is totally unacceptable.  In particular, I have used Fortran compilers
(actually linkers) that created common in order of declaration, and others
(e.g., DEC, I think) that sorted it into alphabetical order.  This code
would not work on a DEC, since "alast" would precede "space".  The standard
explicitly and loudly prohibits assumptions about the order of common.  In
this case, I think you should tell your customer to read the standard and
stuff his program in a certain dark place.
-- 
	Geoff Kuenning   geoff@ITcorp.com   {uunet,trwrb}!desint!geoff