Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!lll-winken!aunro!alberta!mts.ucs.UAlberta.CA!Al_Dunbar From: userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) Newsgroups: comp.lang.fortran Subject: Re: Is this a "feature"? Message-ID: Date: 25 May 91 17:01:32 GMT References: <1991May23.160841.402@ac.dal.ca> Organization: MTS Univ of Alberta Lines: 40 In article <1991May23.160841.402@ac.dal.ca>, scrutton@ac.dal.ca writes: >I saw the super competent answers to the COMMON block initialization >question and hope someone can give me a hand with a couple of my own. > >I'd like to find out if the SAVE statement existed in FORTRAN IV (66). >I've come across some old (stylistically) code which doesn't use the >statement and depends on static allocation. Every compiler I've tried >will let you get away with referencing local variables assigned in >previous calls to that routine so it's either a standard `feature' or >part of the standard. Not necessarily either. I believe that the standard has always said that: 1) it is incorrect to reference a variable before defining it (i.e. giving it a value), and 2) variables local to a program unit are to be assumed undefined on entry (unless SAVE is anavailable option). If you choose to write code that is non standard conforming, you cannot rely on a compiler to give a warning, as the standard itself does not enforce many such requirements on a conforming compiler. A compiler that lets such things as you describe happen might be providing the same as an extension, but only if it is explicitly declared as an extension. Because it works sometimes might not mean it will work in all cases. > >I've also run across a DECODE statement which appears to be a precursor >to the (what's it called...) I/O using character variables as file units. >Is this yet another 66ism? VMS sure didn't like it but I thought 77 was >upward compatible with 66. I believe that DECODE and ENCODE were IBM extensions to the language. They might have been copied by other compiler producers, but that doesn't make them standard features, and does not force all developers to comply. -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "I disclaim disclaimers" CANADA | -------------------+-------------------------------------------