Path: utzoo!attcan!uunet!lll-winken!arisia!quintus!ok From: ok@quintus.uucp (Richard A. O'Keefe) Newsgroups: comp.lang.fortran Subject: Re: Fortran vs C for computations Message-ID: <373@quintus.UUCP> Date: 9 Sep 88 09:52:02 GMT References: <368@quintus.UUCP> <3341@lanl.gov> Sender: news@quintus.UUCP Reply-To: ok@quintus.UUCP (Richard A. O'Keefe) Organization: Quintus Computer Systems, Inc. Lines: 33 In article <3341@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <368@quintus.UUCP>, by ok@quintus.uucp (Richard A. O'Keefe): >> Sorry, this proof won't go through. [counterexamples] > >You are mixing the hypothetical with specific cases. But it's precisely the specific EXISTING cases which determine what is CURRENTLY portable or not. If it is fair enough to cite nasty machines to support a claim that languages should not have floating-point exception handling as a standard part, then it is fair enough for me to cite existing Fortran and C libraries to support a claim that what C and Fortran can (*now*) do "portably" "with the aid libraries" is not the same. I think that ADA shows the way: the language has a standard means of catching exceptions *IF* they are signalled and a standard means of suppressing them *IF* they can be suppressed. The present situation, where I have access to about a dozen different kinds of machines (all of which support both Fortran and C), and all of which are capable of detecting and reporting floating-point exceptions, but there is no single thing I can put in a Fortran program to exploit this common capability, is *not* acceptable. We could have something like CALL HANDLE(exception, handler, oldhandler, ierror) where ierror would be set to a suitable value if the implementation was not able to catch that kind of error. For example, CALL HANDLE('OVERFLOW', MYOVHD, OLDHD, IERROR) IF (IERROR .NE. 0) STOP 'CAN''T CATCH OVERFLOWS' Good heavens, if we were to accept the "some machines don't want to do it" argument, we wouldn't have floating-point arithmetic, and then where would Fortran be?