hsbrown@lemmy.Princeton.EDU (Scott Brown) (03/02/91)
What is wrong with the following program? program test integer k k=1 write(*,k) 1 format('here is line 1') end I have two FORTRAN books that suggest the write(*,k) statement should work. I have two FORTRAN compilers that give a bus error. Any ideas would be appreciated. Scott Brown (hsbrown@lemmy.princeton.edu)
mcqueen@acf3.NYU.EDU (David McQueen) (03/03/91)
/* acf3:comp.lang.fortran / hsbrown@lemmy.Princeton.EDU (Scott Brown) / 6:05 pm Mar 1, 1991 */ > What is wrong with the following program? > program test > integer k > k=1 > write(*,k) > > 1 format('here is line 1') > end > > > > I have two FORTRAN books that suggest the write(*,k) > statement should work. I have two FORTRAN compilers > that give a bus error. Any ideas would be appreciated. > Scott Brown > (hsbrown@lemmy.princeton.edu) If you replace the line k=1 with assign 1 to k it works just fine in f77 on a Sun 3/50. If you try to replace the 1 in the assign statement with a variable, the compiler complains. --Dave McQueen /* ---------- */
userDHAL@mts.ucs.UAlberta.CA (David Halliwell) (03/06/91)
In article <6769@idunno.Princeton.EDU>, hsbrown@lemmy.Princeton.EDU (Scott Brown) writes: >What is wrong with the following program? > program test > integer k > k=1 > write(*,k) > > 1 format('here is line 1') > end > > > >I have two FORTRAN books that suggest the write(*,k) >statement should work. I have two FORTRAN compilers >that give a bus error. Any ideas would be appreciated. Try: ASSIGN 1 TO K instead of K=1 The trick is you are not trying to store an arithmetic value in a variable. You are trying to associate a label (of the FORMAT statement) with the variable. The ASSIGN statement is what you use to do this. Hope this helps! (and is correct!) Dave Halliwell
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (03/06/91)
In article <6769@idunno.Princeton.EDU>, hsbrown@lemmy.Princeton.EDU (Scott Brown) writes: >What is wrong with the following program? > program test > integer k > k=1 > write(*,k) > > 1 format('here is line 1') > end > > > >I have two FORTRAN books that suggest the write(*,k) >statement should work. I have two FORTRAN compilers >that give a bus error. Any ideas would be appreciated. Sell your two books, or read them more carefully; this is not standard Fortran. When a variable appears as a format specifier, it supplies an address at which should be found a format specification in the form of a string literal. The only way I know to get an integer variable to store a statement number is with the ASSIGNED GOTO; even then the docs/standard warn severely against referencing in any other way a variable used for this purpose. -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "I disclaim disclaimers" CANADA | -------------------+-------------------------------------------
usenet@bellcore.bellcore.com (Poster of News) (03/07/91)
>>What is wrong with the following program? >> program test >> integer k >> k=1 >> write(*,k) >> >> 1 format('here is line 1') >> end >> >> >> >>I have two FORTRAN books that suggest the write(*,k) >>statement should work. I have two FORTRAN compilers >>that give a bus error. Any ideas would be appreciated. > I used the parameter statement and got the program to run. parameter(k=1) Dan Heyman dph@bellcore.bellcore.com
seymour@milton.u.washington.edu (Richard Seymour) (03/07/91)
on ASSIGN versus = (or Parameter) In article <1991Mar6.183820.8807@bellcore.bellcore.com> dph@breeze.UUCP (Daniel P Heyman) writes: >>> integer k >>> k=1 >>> write(1,k) >>> 1 format('here is line 1') >>> end >I used the parameter statement and got the program to run. > parameter(k=1) This is all probably quite system-dependant (the standard says what it looks like at the source level, it doesn't state what goes on behind the curtain (except for array storage)) back in the old days (before compilers got too smart) i used to try: ASSIGN 1 to K TYPE *,K and (depending upon the system) i'd sometimes get "1", other times i'd get the physical/virtual address of statement 1 in the code. (DEC's PDP-11 RSX-11M Fortran 4-Plus did the latter) --dick
LJM@SLACVM.SLAC.STANFORD.EDU (Len Moss) (03/07/91)
In article <RN.213@mts.ucs.UAlberta.CA>, userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) says: > >In article <6769@idunno.Princeton.EDU>, hsbrown@lemmy.Princeton.EDU (Scott >Brown) writes: >>What is wrong with the following program? >> program test >> integer k >> k=1 >> write(*,k) >> >> 1 format('here is line 1') >> end [Stuff omitted.] >Sell your two books, or read them more carefully; this is not >standard Fortran. When a variable appears as a format specifier, >it supplies an address at which should be found a format >specification in the form of a string literal. The only way I >know to get an integer variable to store a statement number is >with the ASSIGNED GOTO; even then the docs/standard warn severely >against referencing in any other way a variable used for this >purpose. Which standard for Fortran do you mean? Indeed, in Fortran 66 an INTEGER variable mentioned in an ASSIGN statement could not be referenced in any statement other than an assigned GOTO until it was redefined; and any type of array (but not a scalar variable) containing leading Hollerith data defining a valid format specification could be used in a formatted input/output statement in place of the reference to a statement label. However, as others have already noted, Fortran 77 permits the ASSIGN statement to assign the statement label of a FORMAT statement to an INTEGER variable which may then be used in a formatted input/output statement as the format identifier (the relevant parts of X3.9-1978 are page 12-8, lines 10-13 and page 10-2, lines 17-46). Dynamic formats in Fortran 77 are handled via the CHARACTER data type. Strictly speaking, Hollerith data was deleted from the language by the 77 standard, so the use of non-CHARACTER arrays as format identifiers is prohibited. However, Appendix C of X3.9-1978 contains recommendations for implementing Hollerith as an extension for those processors concerned about Fortran 66 compatibility. (This is roughly equivalent to the notion of an "obsolescent feature" in Fortran 90, especially since Hollerith is completely absent from Fortran 90.) These recommendations include the use of arrays containing Hollerith data as format identifiers, just as in Fortran 66. Note that there is no ambiguity for INTEGERs: when used as a format identifier, an INTEGER variable (i.e., scalar) can only contain an ASSIGNed statement label, and an INTEGER array can only contain a Hollerith format specification. -- Leonard J. Moss <ljm@slacvm.slac.stanford.edu> | My views don't necessarily Stanford Linear Accelerator Center, Bin 97 | reflect those of SLAC, Stanford, CA 94309 | Stanford or the DOE
maine@altair.dfrf.nasa.gov (Richard Maine) (03/07/91)
On 6 Mar 91 21:08:36 GMT, moshkovi@sanandreas.ecn.purdue.edu (Gennady Moshkovich) said: Gennady> userDHAL@mts.ucs.UAlberta.CA (David Halliwell) writes: >In article <6769@idunno.Princeton.EDU>, hsbrown@lemmy.Princeton.EDU (Scott Brown) writes: >>What is wrong with the following program? >> program test >> integer k >> k=1 >> write(*,k) >> >> 1 format('here is line 1') >> end >> > Try: > ASSIGN 1 TO K > instead of > K=1 > Gennady> This will not work on UNIX or DOS. Gennady> Instead do it with parameter statements Gennady> parameter(k=1) Gennady> ....... Gennady> I checked, it works. The ASSIGN had *better* work with the assign, as that is perfectly standard F77 (except for the lower case and possibly the lack of a carriage control character in the format, niether point was at issue here). On the other hand, the use of the parameter statement for this purpose is non-standard. I just checked on my Sun3 with SunOS 4.1.1 and fortran 1.3.1. The form with assign worked fine, as expected. I didn't bother to test the non-standard form using parameter, as I didn't care. Now I'd agree that usage of assign is "poor" style. I never once have used assign in my f77 code. As pointed out by other posters, the preferred way of handling such issues in f77 involves character variables as formats. However, poor style or not, the assign is standard, should work on any standard-conforming compiler, and does on at least the Sun compiler I just checked. -- -- Richard Maine maine@altair.dfrf.nasa.gov
ddh@hare.cdc.com (Dan Horsfall) (03/07/91)
In article <MAINE.91Mar6170041@ra.dfrf.nasa.gov> maine@altair.dfrf.nasa.gov (Richard Maine) writes: [ ... previous stuff on use of assign for format identifier ... ] > > Now I'd agree that usage of assign is "poor" style. I never once > have used assign in my f77 code. As pointed out by other posters, > the preferred way of handling such issues in f77 involves character > variables as formats. However, poor style or not, the assign is > standard, should work on any standard-conforming compiler, and > does on at least the Sun compiler I just checked. > -- > Richard Maine > maine@altair.dfrf.nasa.gov I can't quite go this far with Richard. Granted, this use of assign is "infrequently" (OK, almost never) used, but that doesn't make it poor style. Given the long code sequences that some compilers generate for I/O statements, I much prefer IF( condition ) ASSIGN 901 TO IFMT ELSE ASSIGN 902 TO IFMT ENDIF WRITE( LU, IFMT ) iolist over IF( condition ) WRITE( LU, 901 ) iolist ELSE WRITE( LU, 902 ) iolist ENDIF and might venture so far as to suggest that such usage could even justify (enough disclaimers?) the standardization of this syntax. [ Don't bother flaming: I know that it _could_ be done with character variables, arrays, subscripts, or what-have-you. On the systems on which I have reviewed the generated object code, ASSIGN generally produces a <load address> and <store> sequence, used without further massaging at WRITE time; this is almost always less code than subscripting into a character array. ] -- Horse + Control Data Corporation Dan Horsfall +1-612-482-4622 + 4201 Lexington Ave North Internet ddh@dash.udev.cdc.com + Arden Hills MN 55126 USA
LJM@SLACVM.SLAC.STANFORD.EDU (Len Moss) (03/08/91)
In article <31132@shamash.cdc.com>, ddh@hare.cdc.com (Dan Horsfall) says: > >In article <MAINE.91Mar6170041@ra.dfrf.nasa.gov> > maine@altair.dfrf.nasa.gov (Richard Maine) writes: > >[ ... previous stuff on use of assign for format identifier ... ] > >> >> Now I'd agree that usage of assign is "poor" style... [ ... stuff on fact that ASSIGN is part of Fortran 77 standard ... ] >> -- >> Richard Maine >> maine@altair.dfrf.nasa.gov > >I can't quite go this far with Richard. Granted, this use of assign >is "infrequently" (OK, almost never) used, but that doesn't make it >poor style. >generate for I/O statements, I much prefer [ ... stuff on convenience and efficiency of ASSIGN ... ] I don't know why Mr. Maine considers ASSIGN poor style, but the reason I object to it is that it confuses what should be two entirely separate data types, namely INTEGER and "statement label". > Dan Horsfall +1-612-482-4622 + 4201 Lexington Ave North > Internet ddh@dash.udev.cdc.com + Arden Hills MN 55126 USA -- Leonard J. Moss <ljm@slacvm.slac.stanford.edu> | My views don't necessarily Stanford Linear Accelerator Center, Bin 97 | reflect those of SLAC, Stanford, CA 94309 | Stanford or the DOE
vsnyder@jato.jpl.nasa.gov (Van Snyder) (03/08/91)
In article <1991Mar6.183820.8807@bellcore.bellcore.com> dph@breeze.UUCP (Daniel P Heyman) writes: >>>What is wrong with the following program? >>> program test >>> integer k >>> k=1 >>> write(*,k) >>> >>> 1 format('here is line 1') >>> end >>> >>>I have two FORTRAN books that suggest the write(*,k) >>>statement should work. I have two FORTRAN compilers >>>that give a bus error. Any ideas would be appreciated. >> >I used the parameter statement and got the program to run. > parameter(k=1) >Dan Heyman dph@bellcore.bellcore.com I think your compiler doesn't compile the language specified by X3.9-1978. See page 12-8, lines 10-14. Then read page 10-2, lines 34-36. For your convenience I quote them here: ... (2) An integer variable name that has been assigned the statement label of a FORMAT statement... Execution of a statement label assignment statement [ASSIGN statement] is *the only way* that a variable may be defined with a statement label value. (my comment in [], and my emphasis in **). Parameter statements can associate names to constant expressions (6.7). Constant expressions can be "arithmetic constant expression (6.1.3), a character constant expression (6.2.3), or a logical constant expression (6.4.4)." If you track those down, you'll find nothing about statement labels. Regards. Van -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp