pa@appmag.com (Pierre Asselin) (03/21/91)
This simplified fragment violates the standard by passing reals to a
routine that expects integers.
program wrong
real rin, rout
rin= 0.577215665 ! or whatever...
call icopy(rin, rout)
write(6,*) rout
end
subroutine icopy(iin, iout)
integer iin, iout
iout= iin
return
end
Seems fairly innocuous, though. Q: are there implementations
where it would fail ?
--Pierre Asselin, R&D, Applied Magnetics Corp. I speak for me.
3003jalp@ucsbuxa.ucsb.edu (appmag.com doesn't work yet)wsb@boise.Eng.Sun.COM (Walt Brainerd) (03/21/91)
In article <1991Mar20.195732.15376@appmag.com>, pa@appmag.com (Pierre Asselin) writes: > This simplified fragment violates the standard by passing reals to a > routine that expects integers. > > real rin, rout > call icopy(rin, rout) > . . . > subroutine icopy(iin, iout) > integer iin, iout > > Seems fairly innocuous, though. Q: are there implementations > where it would fail ? > Yes. The Burroughs linkers on their old large systems B6700-B7900, etc. used to catch this. I don't know what they do now about such things, but I think the trend is to do more checking of this sort along with global oprimization, so I would not recommend doing this (or anything else nonstandard) unless you really need to. -- Walt Brainerd Sun Microsystems, Inc. wsb@eng.sun.com MS MTV 5-40 Mountain View, CA 94043 415/336-5991
tj@Alliant.COM (Tom Jaskiewicz) (03/21/91)
In article <1991Mar20.195732.15376@appmag.com> pa@appmag.com (Pierre Asselin) writes: }This simplified fragment violates the standard by passing reals to a }routine that expects integers. } } program wrong } real rin, rout } rin= 0.577215665 ! or whatever... } call icopy(rin, rout) } write(6,*) rout } end } } subroutine icopy(iin, iout) } integer iin, iout } iout= iin } return } end } }Seems fairly innocuous, though. Q: are there implementations }where it would fail ? Yes. It been 10 years since I've used one, but there is at least one Fortran implementation that uses 16 bit INTEGER's and 32 bit REAL's. (this in itself violates Fortran-77). -- ########################################################################## # The doctrine of nonresistance against arbitrary power, and oppression is # absurd, slavish, and destructive of the good and happiness of mankind. # -- Article 10, Part First, Constitution of New Hampshire
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (03/21/91)
In article <1991Mar20.195732.15376@appmag.com>, pa@appmag.com (Pierre Asselin) writes: > program wrong > real rin, rout > rin = 0.577215665 ! or whatever... > call icopy(rin, rout) > write(6,*) rout > end > subroutine icopy(iin, iout) > integer iin, iout > iout = iin > return > end > > Seems fairly innocuous, though. Q: are there implementations > where it would fail? Yes. 1. I know it's non-Standard, but there are several compilers where the default size for integer is INTEGER*2. 2. On the B6700, integers and floats used the same representation, but integer assignments forced the result to integer form, just in case. The code for icopy would be something like VALC (3,2) ; fetch value of IIN IRND ; round to integer NAME (3,3) ; fetch address of IOUT STOD ; store (I _know_ the details are wrong. Concentrate on the idea.) This would result in the value 1.0 being stored in ROUT. 3. I don't know whether the Symbolics Fortran compiler did this, but it _could_ have: on a tagged machine where integers and floats have different tags, one would expect the compiler to plant code to check that IIN has an "integer" tag. -- Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.
cochran@spam.rtp.dg.com (Dave Cochran) (03/21/91)
In article <1991Mar20.195732.15376@appmag.com>, pa@appmag.com (Pierre Asselin) writes: |> This simplified fragment violates the standard by passing reals to a |> routine that expects integers. |> |> program wrong |> real rin, rout |> rin= 0.577215665 ! or whatever... |> call icopy(rin, rout) |> write(6,*) rout |> end |> |> subroutine icopy(iin, iout) |> integer iin, iout |> iout= iin |> return |> end |> |> Seems fairly innocuous, though. Q: are there implementations |> where it would fail ? |> Oh yes. In Green Hills F77 for the Motorola 88000, it would die with a bus error because the reals will default to real*4, with a 32 bit alignment, and the integers will default to int*2, with a 16 bit alignment. I see this all the time. -- +------------------------------------------------------+ |Dave Cochran (cochran@spam.rtp.dg.com) | |Data General Corporation, Research Triangle Park, NC | +------------------------------------------------------+ |"Outside of a dog, a book is man's best friend. | | Inside of a dog it's too dark to read." -Groucho Marx| +------------------------------------------------------+
mac@cis.ksu.edu (Myron A. Calhoun) (03/21/91)
tj@Alliant.COM (Tom Jaskiewicz) writes: >In article <1991Mar20.195732.15376@appmag.com> pa@appmag.com (Pierre Asselin) writes: >>This simplified fragment violates the standard by passing reals to a >>routine that expects integers. [program deleted for brevity] >>Seems fairly innocuous, though. Q: are there implementations >>where it would fail ? >Yes. It been 10 years since I've used one, but there is at least one >Fortran implementation that uses 16 bit INTEGER's and 32 bit REAL's. >(this in itself violates Fortran-77). Well, DOUBLE PRECISION and INTEGER do NOT violate the standard, and they would fail, too. So would a similar program which asked the subroutine to copy an array with a single assignment statement. And for the same reason: the subroutine does not automagically know the LENGTH of the parameters, only the address of their first part. --Myron. --Myron. -- # Myron A. Calhoun, Ph.D. E.E.; Associate Professor (913) 539-4448 home # INTERNET: mac@cis.ksu.edu (129.130.10.2) 532-6350 work # UUCP: ...rutgers!ksuvax1!harry!mac 532-7353 fax # AT&T Mail: attmail!ksuvax1!mac W0PBV @ K0VAY.KS.USA.NA
hrubin@pop.stat.purdue.edu (Herman Rubin) (03/21/91)
In article <10146@exodus.Eng.Sun.COM>, wsb@boise.Eng.Sun.COM (Walt Brainerd) writes: > In article <1991Mar20.195732.15376@appmag.com>, pa@appmag.com (Pierre Asselin) writes: > > This simplified fragment violates the standard by passing reals to a > > routine that expects integers. > > real rin, rout > > call icopy(rin, rout) > . . . > > subroutine icopy(iin, iout) > > integer iin, iout > > Seems fairly innocuous, though. Q: are there implementations > > where it would fail ? > Yes. > The Burroughs linkers on their old large systems B6700-B7900, etc. > used to catch this. I don't know what they do now about such > things, but I think the trend is to do more checking of this > sort along with global oprimization, so I would not recommend > doing this (or anything else nonstandard) unless you really > need to. I have, using Fortran, deliberately set up subroutines which "cheated" on types. How else would one read multiple precision reals in or out? I do not consider converting them to decimal for output, or reading in decimal input, as reasonable; I wanted to be sure that the numbers were exactly the machine numbers, and I see no good reason to do unnecessary conversions. There are also cases in which I have deliberately done boolean operations on "real" numbers. The language designer, etc., who does not allow someone to deliberately cheat on the types is doing a great disservice to computing. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
wsb@boise.Eng.Sun.COM (Walt Brainerd) (03/22/91)
In article <4554@alliant.Alliant.COM>, tj@Alliant.COM (Tom Jaskiewicz) writes: > > Yes. It been 10 years since I've used one, but there is at least one > Fortran implementation that uses 16 bit INTEGER's and 32 bit REAL's. > (this in itself violates Fortran-77). > This is NOT, by itself, a violation of the Fortran 77 standard; the standard says nothing about how values are stored. It DOES say how equivalence and common (for example) must work, so if those things don't work correctly, the implementation is not correct. But testing if some kind of illegal "cheating" on types (such as using mismatched arguments or assigning a value to a real and using an equivalenced integer) works is not a legitimate way to determine this. (BTW, I would say that if 16-bit integers and 32-bit reals are the only ones available, an implementation would have a very difficult time making equivalence and common work correctly.) -- Walt Brainerd Sun Microsystems, Inc. wsb@eng.sun.com MS MTV 5-40 Mountain View, CA 94043 415/336-5991
wsb@boise.Eng.Sun.COM (Walt Brainerd) (03/22/91)
In article <8421@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes: > > I have, using Fortran, deliberately set up subroutines which > "cheated" on types. How else would one read multiple precision > reals in or out? I do not consider converting them to decimal > for output, or reading in decimal input, as reasonable; I wanted > to be sure that the numbers were exactly the machine numbers, and > I see no good reason to do unnecessary conversions. > There isn't enough info here to really understand what the problem is, but it sounds like this is exactly what unformatted I/O is for. > There are also cases in which I have deliberately done boolean > operations on "real" numbers. The language designer, etc., who > does not allow someone to deliberately cheat on the types is doing > a great disservice to computing. This could generate several hundred pages of comments on the philosophy of language design and computing, but I'll try to be briefer than that. If the "language designers" referenced above are the people on a standards committee, then I disagree strongly. The main purpose of a standard is to provide portability. Things that permit cheating are not (and should not be) in a standard because they are not portable. I did neglect to point out that, in spite of this philosophy, there is a TRANSFER function in Fortran 90 that converts "type" only without changing the bits, so this allows cheating of all kinds, but perhaps the instances will be a bit more self documenting. For example, the value of TRANSFER (X, I) is an integer with the same bits in it as the real X (assuming X is real and I is integer). Also, other intrinsics that manipulate the parts of a real number (e.g., SET_EXPONENT) should cut down the number of cases where "cheating" is necessary. If the "language designer" is your local friendly vendor, then if users want nonportable features, vendors will provide them, and use of these features, as always, tends to lock you in to one vendor, one architecture, one compiler, ... Sometimes they are necessary and sometimes they are convenient. The users must judge. But putting such stuff in a standard is definitely a DISSERVICE to computing (IMHO). -- Walt Brainerd Sun Microsystems, Inc. wsb@eng.sun.com MS MTV 5-40 Mountain View, CA 94043 415/336-5991
ftower@ncar.ucar.EDU (Francis Tower) (03/22/91)
Yes there are implementations where this will fail. I've used a compiler which did static checking of the data descriptors and number of arguments at compile time. ERRORs like this I like. Kept me from making some stupid faults.
shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) (03/22/91)
In article <8421@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: >I have, using Fortran, deliberately set up subroutines which >"cheated" on types. How else would one read multiple precision >reals in or out?.... Another application: suppose in a large program you want to write your own routing routines to do IO, which will write to one or more files, and/or the screen, etc., depending on the setting of various control variables. You might want to pass a format string plus a variable or two to the routine. But the variable's type might vary from invocation to invocation. If you can't cheat on types, I don't think you can do this in Fortran. But if you can declare the variable as an INTEGER, but actually pass a REAL, with an appropriate format string, this is easily done. Admittedly, you can't pass a DOUBLE PRECISION variable, and you still might need different routines for passing one, two, three, etc., variables, but still life would be much more complicated if the compiler didn't let you lie about INTEGER/REAL. -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************** Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@cunixf.cc.columbia.edu(Internet) shenkin@cunixf(Bitnet) ***"In scenic New York... where the third world is only a subway ride away."***
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (03/22/91)
In article <1991Mar20.195732.15376@appmag.com>, pa@appmag.com (Pierre Asselin) writes: >This simplified fragment violates the standard by passing reals to a >routine that expects integers. > > program wrong > real rin, rout > rin= 0.577215665 ! or whatever... > call icopy(rin, rout) > write(6,*) rout > end > > subroutine icopy(iin, iout) > integer iin, iout > iout= iin > return > end > >Seems fairly innocuous, though. Q: are there implementations >where it would fail ? > Fail to do what? Compile? Do what _you_ think it should do, which is hard to determine since you have written a non- conforming program (i.e. the standard says it is wrong, but does not dictate what it should do). -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "I disclaim disclaimers" CANADA | -------------------+-------------------------------------------
schan@minnie.cs.su.OZ.AU (Stephen Chan) (03/22/91)
Does anyone have a list of error messages produced by f77 during compile-time. Bascially, I'm after a list of error messages and their respective meanings. Any help appreciated.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (03/22/91)
In article <1991Mar21.201340.3271@cunixf.cc.columbia.edu>, shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes: > Another application: suppose in a large program you want to write your > own routing routines to do IO, which will write to one or more files, and/or > the screen, etc., depending on the setting of various control variables. You > might want to pass a format string plus a variable or two to the routine. > But the variable's type might vary from invocation to invocation. If you can't > cheat on types, I don't think you can do this in Fortran. You can't do it *that* *way*. But you can do the routing! All you have to do is write to a character variable, and pass the already-formatted text to the routing routines. Let's face it, type cheating or no type cheating, there is no way you can pass an implied-DO as a subroutine parameter, so you aren't going to be able to do a thorough job of mimicking WRITE anyway. The 4.4BSD <stdio.h> routines and Turbo Pascal and Quintus Prolog and Pop and many many Lisp implementations and dozens of other systems provide a way for users to define their own streams by providing record transfer procedure. The record transfer procedures don't need to "cheat", because they are only ever given and only ever deliver character arrays/ strings. There is no reason why a Fortran implementation could not give you *as an non-standard extension* a way of opening a logical unit with record transfer going through specified user-provided routines. -- Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.
hrubin@pop.stat.purdue.edu (Herman Rubin) (03/22/91)
In article <10208@exodus.Eng.Sun.COM>, wsb@boise.Eng.Sun.COM (Walt Brainerd) writes: > In article <8421@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes: > > I have, using Fortran, deliberately set up subroutines which > > "cheated" on types. How else would one read multiple precision > > reals in or out? I do not consider converting them to decimal > > for output, or reading in decimal input, as reasonable; I wanted > > to be sure that the numbers were exactly the machine numbers, and > > I see no good reason to do unnecessary conversions. > There isn't enough info here to really understand what the problem is, > but it sounds like this is exactly what unformatted I/O is for. Yes and no. Try doing it from one machine to another. There are other situations in which there are real problems. > > There are also cases in which I have deliberately done boolean > > operations on "real" numbers. The language designer, etc., who > > does not allow someone to deliberately cheat on the types is doing > > a great disservice to computing. > This could generate several hundred pages of comments on the > philosophy of language design and computing, but I'll try to be > briefer than that. If the "language designers" referenced above > are the people on a standards committee, then I disagree strongly. > The main purpose of a standard is to provide portability. Things > that permit cheating are not (and should not be) in a standard > because they are not portable. I did neglect to point out that, > in spite of this philosophy, there is a TRANSFER function in > Fortran 90 that converts "type" only without changing the bits, > so this allows cheating of all kinds, but perhaps the instances > will be a bit more self documenting. For example, the value of What good is portability if it makes doing sensible things on the computer very difficult? This IS the situation with all of the HLLs. Until we understand computing far more than we do now, we cannot produce even a good language. Fortran was originally a language for casual programming, and not intended for producing system subroutines. Neither it, nor any other language I know, is suited for the generation of efficient numerical procedures. In addition, even simple operations should be programmed differently on different machines. If vector operations are not in the language, good code for adding two vectors and storing the result is not portable in HLLs. If some of the vectors are short vectors in registers, I do not know how to do a decent job on most computers using any HLL. These are important considerations which the language designers do not seem to be able to understand. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
cet1@cl.cam.ac.uk (C.E. Thompson) (03/26/91)
In article <4554@alliant.Alliant.COM> tj@Alliant.COM (Tom Jaskiewicz) writes: >In article <1991Mar20.195732.15376@appmag.com> pa@appmag.com (Pierre Asselin) writes: >}This simplified fragment violates the standard by passing reals to a >}routine that expects integers. >} >} program wrong >} real rin, rout >} rin= 0.577215665 ! or whatever... >} call icopy(rin, rout) >} write(6,*) rout >} end >} >} subroutine icopy(iin, iout) >} integer iin, iout >} iout= iin >} return >} end >} >}Seems fairly innocuous, though. Q: are there implementations >}where it would fail ? > >Yes. It been 10 years since I've used one, but there is at least one >Fortran implementation that uses 16 bit INTEGER's and 32 bit REAL's. >(this in itself violates Fortran-77). > From the mists of time: on TITAN (and other Atlas-1 and Atlas-2 Fortran implementations as well, I expect) integers were halfwords (24 bits) while reals were words (48 bits). The above code would not have worked. This implementation long preceded the Fortran 77 rules on storage units. However, in some cases it was compatible with them: for example, an INTEGER array and a REAL array with the same number of elements that were EQUIVALENCEd or overlaid in COMMON would correspond 1:1 (half the space in the INTEGER array was "wasted"). Copying the INTEGER array element by element to another such INTEGER/REAL pair would not have the effect of copying the REAL array (only half the bits would be moved), and there is nothing in the Fortran 77 standard to say that it should. Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk
tom@itc.univie.ac.at (Tom Kovar) (03/29/91)
In article <1991Mar20.195732.15376@appmag.com> pa@appmag.com (Pierre Asselin) writes: }This simplified fragment violates the standard by passing reals to a }routine that expects integers. } } program wrong } real rin, rout } rin= 0.577215665 ! or whatever... } call icopy(rin, rout) } write(6,*) rout } end } } subroutine icopy(iin, iout) } integer iin, iout } iout= iin } return } end } }Seems fairly innocuous, though. Q: are there implementations }where it would fail ? > >From the mists of time: on TITAN (and other Atlas-1 and Atlas-2 Fortran >implementations as well, I expect) integers were halfwords (24 bits) while >reals were words (48 bits). The above code would not have worked. > >This implementation long preceded the Fortran 77 rules on storage units. >However, in some cases it was compatible with them: for example, an INTEGER >array and a REAL array with the same number of elements that were >EQUIVALENCEd or overlaid in COMMON would correspond 1:1 (half the space >in the INTEGER array was "wasted"). Copying the INTEGER array element by >element to another such INTEGER/REAL pair would not have the effect of >copying the REAL array (only half the bits would be moved), and there is >nothing in the Fortran 77 standard to say that it should. Another wonderfull thing - on old Telefunken TR440 (or something like that) using a 48 bit word, I think 2 bits were passed within the word, identifying the kind of the argument... So you would have been caught... :-) Tom Kovar
hirchert@ncsa.uiuc.edu (Kurt Hirchert) (03/29/91)
In article <1991Mar20.195732.15376@appmag.com> pa@appmag.com (Pierre Asselin) writes: >This simplified fragment violates the standard by passing reals to a >routine that expects integers. > > program wrong > real rin, rout > rin= 0.577215665 ! or whatever... > call icopy(rin, rout) > write(6,*) rout > end > > subroutine icopy(iin, iout) > integer iin, iout > iout= iin > return > end > >Seems fairly innocuous, though. Q: are there implementations >where it would fail ? One of the early FORTRAN implementations for the IBM 360 line used decimal arithmetic rather than binary arithmetic for integer variables and computation. In that implementation, the above program would have died with a machine interrupt because the "integer" iout would have contained bit patterns that were not valid decimal digits. As a general rule, it is dangerous to use techniques based on the effects of the implementation of a language's features rather on the features themselves. No matter how logical it may seem to implement those features in that particular way, somewhere out there you will find a machine in which the implementation does not have the property you exploited. (an obvious corollary to Murphy's law) -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
vsnyder@jato.jpl.nasa.gov (Van Snyder) (03/29/91)
In article <1991Mar25.163447.10166@cl.cam.ac.uk> cet1@cl.cam.ac.uk (C.E. Thompson) writes: >In article <4554@alliant.Alliant.COM> tj@Alliant.COM (Tom Jaskiewicz) writes: >>In article <1991Mar20.195732.15376@appmag.com> pa@appmag.com (Pierre Asselin) writes: >>}This simplified fragment violates the standard by passing reals to a >>}routine that expects integers. >>} >>} program wrong >>} real rin, rout >>} rin= 0.577215665 ! or whatever... >>} call icopy(rin, rout) >>} write(6,*) rout >>} end >>} >>} subroutine icopy(iin, iout) >>} integer iin, iout >>} iout= iin >>} return >>} end >>} >>}Seems fairly innocuous, though. Q: are there implementations >>}where it would fail ? >> >>Yes. It been 10 years since I've used one, but there is at least one >>Fortran implementation that uses 16 bit INTEGER's and 32 bit REAL's. >>(this in itself violates Fortran-77). >> > >From the mists of time: on TITAN (and other Atlas-1 and Atlas-2 Fortran >implementations as well, I expect) integers were halfwords (24 bits) while >reals were words (48 bits). The above code would not have worked... [stuff > deleted] Also from the mists of time: I think on CDC 6600/7600, an integer was represented using only the fraction of a floating point number, with the exponent zero. If a number with zero exponent was acted upon by a floating point instruction, or a number with non-zero exponent was acted upon by an integer instruction, interrupts happened. But I may have this wrong. -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp
roth@oasys.dt.navy.mil (Pete Roth) (04/02/91)
In article <1991Mar29.014537.23918@jato.jpl.nasa.gov> vsnyder@jato.jpl.nasa.gov (Van Snyder) writes: > [ deleted ] >Also from the mists of time: I think on CDC 6600/7600, an integer was >represented using only the fraction of a floating point number, with the >exponent zero. If a number with zero exponent was acted upon by a floating >point instruction, or a number with non-zero exponent was acted upon by an >integer instruction, interrupts happened. But I may have this wrong. > Facts are correct, but the code in question WOULD work correctly. BUT: we Fortraners are forever moving ancient code from machine to machine. When do YOU give up on code and rewrite from scratch? - - - - - - - - - - - - - - - - - - - - - - - - - - Peter N Roth roth@dtoa1.dt.navy.mil Objects in this office are closer than they appear.