Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc!uxc.cso.uiuc.edu!uxd.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert
From: hirchert@uxe.cso.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: DO loops, anyone? - Apologies!
Message-ID: <50500109@uxe.cso.uiuc.edu>
Date: 20 Mar 89 16:15:00 GMT
References: <459@orange19.qtp.ufl.edu>
Lines: 47
Nf-ID: #R:orange19.qtp.ufl.edu:459:uxe.cso.uiuc.edu:50500109:000:2487
Nf-From: uxe.cso.uiuc.edu!hirchert    Mar 20 10:15:00 1989


Steven R Weintraub (steve@oakhill.UUCP) writes:
>If you read my articles, you will see I repeatedly state this is
>officially illegal.

My news feed has been a bit sporadic lately, so I may have missed you earlier
postings.  The posting to which I replied did not acknowledge that the code
was not standard conforming.  If it had, I probably woudln't have bothered
posting myself.

>                     You claim that since this code is illegal
>whatever the customer gets, he deserves.  Since there is no definition,
>there is no defined behavior.

This is an overstatement of my position.  I believe
. that people writing standard-conforming programs deserve correct behavior,
. that people knowingly trying to port nonstandard code deserve the problems
  that they are likely to encounter, and
. that people inadvertantly violate the standard deserve help as much help as
  can practically be given in finding these violations.
This latter point is a "quality of implementation" issue.  I would label a
processor that doesn't provide such help as "of low quality" or even as "junk"
but not as "wrong" or generating "bad code", since these latter terms imply
(to me, at least) a failure to handle correct programs correctly.

>(paragraph about assumed behavior deleted)

>The assumed behavior does not include creating an infinitie loop,
>causing the internal loop to run if it was to be skipped, or
>executing the last statement twice.  And if you generate something
>that does any of these, it is wrong.

You have to be careful about these "assumed behavior" arguments.  People
make lots of incorrect assumptions.  For example, many people assume you
can pass a double precision actual argument to a single precision dummy
argument and that this will "work" because the first half of a double precision
value looks like a single precision number with approximately the same value.
On many machine, this will work, but on many others (including machines with
IEEE floating point arithmetic) the result will be just as disastrous as the
loop examples we have been discussing.  I would not call these latter machines
"wrong" because they failed to match the assumed behavior (which was utterly
unambiguous).  I _would_ give credit for a higher quality implementation to
processors that can identify such cases where the actual behavior is not
in agreement with the programmer's expectations.

Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications