Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!clyde.concordia.ca!nstn.ns.ca!cs.dal.ca!silvert
From: silvert@cs.dal.ca (Bill Silvert)
Newsgroups: comp.lang.fortran
Subject: Re: MS-FORTRAN "bug" in string concatenation -- not a bug
Summary: conforms to standard
Message-ID: <1991Feb14.133355.16163@cs.dal.ca>
Date: 14 Feb 91 13:33:55 GMT
References: <2PWGG2@MPLVAX.SRI.COM>
Sender: silvert@cs.dal.ca.UUCP (Bill Silvert)
Reply-To: bill%biomel@cs.dal.ca
Organization: Habitat Ecology Div., Bedford Inst. of Oceanography
Lines: 24

In article <2PWGG2@MPLVAX.SRI.COM> HUESTIS@MPLVAX.SRI.COM (David L. Huestis) writes:
>Under Microsoft FORTRAN the following simple program
>
>       character string*4/'abc'/
>       string = '*'//string
>       write(*,*)string
>       end
>
>produces the output '**bb' while LAHEY and VAX yield '*abc'
>
>Microsoft FORTRAN takes no precautions against the source strings
>overlapping the destination string.

It doesn't have to.  The standard (10.4) states that you cannot
reference the string you are defining on the rhs.  I suspect that
compilers that handle 
>       string = '*'//string
correctly will not give the correct result for
>       string = string//'*'
-- 
William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography
P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2.  Tel. (902)426-1577
UUCP=..!{uunet|watmath}!dalcs!biomel!bill
BITNET=bill%biomel%dalcs@dalac	InterNet=bill%biomel@cs.dal.ca