Fortran - Re: What would it take to have no undefined behavior in Fortran ?

Author

Re: What would it take to have no undefined behavior in Fortran ?

Craig Powers

2007-06-28, 7:08 pm

analyst41@hotmail.com wrote:
> The simulation professor's post showed that even "dirty" things like
> integer overflow have practical uses and that programmers may have
> legitimate reasons to deliberately code for such things. From what I
> understand, the language spec says nothing as to what the output
> should be on integer overflow.
>
> Would the spec have to expand essentially infinitely to make sure that
> every program that compiles should produce identical output for the
> same input on all platforms it may run on (or (abort at exactly the
> same point)?

What's your perspective on things that are impossible for the compiler
to test? Are you trying to reduce the number of things that are legal
but unspecified, or are you trying to force the compiler to only accept
100% legal code? The latter case is impossible (cf the halting
problem), and IIUC that is the primary reason why undefined behavior exists.

James Giles

2007-06-28, 7:08 pm

Craig Powers wrote:
....
> What's your perspective on things that are impossible for the compiler
> to test? Are you trying to reduce the number of things that are legal
> but unspecified, or are you trying to force the compiler to only
> accept 100% legal code? The latter case is impossible (cf the halting
> problem), and IIUC that is the primary reason why undefined behavior
> exists.

Well, no. It's a hard distinction to make for a pragmatic mind,
but undefined is not the same as undecidable. In fact, what
made the halting problem important (and shocking, to some)
was that it was *not* a result of something important being left
undefined. It arose in a *very* well defined formal model
of computing. It's similar to Gödel's undecidable propositions
in number theory. In fact, it's now recognized as a well defined
property of formal systems that if they're sufficiently complex
they'll have properties that are formally undecidable. Yes,
I said *well*defined*.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Brooks Moses

2007-06-28, 10:06 pm

Craig Powers wrote:
> analyst41@hotmail.com wrote:
>
> What's your perspective on things that are impossible for the compiler
> to test? Are you trying to reduce the number of things that are legal
> but unspecified, or are you trying to force the compiler to only accept
> 100% legal code? The latter case is impossible (cf the halting
> problem), and IIUC that is the primary reason why undefined behavior exists.

I was reading a rather interesting article about that the other day, and
I've still got the link: http://cdsmith.twu.net/types.html.

To apply a point from that article: You've got the halting problem
slightly wrong. It is certainly possible to (for example) write a
verifier that will only accept algorithms which will halt. What is
impossible is writing a compiler that will do that and will also accept
_all_ of the algorithms which halt.

The correlation to language specifications is that, yes, you _can_
define a language where the compiler only accepts correct programs, and
nothing else -- that is, you can define a language which has no
undefined behavior. The tradeoff is that, if you do that, the compiler
will necessarily reject some programs that would have been correct if
they were allowed. And some of those might be programs that do
interesting things that you can't do in other ways that the
no-undefined-behavior compiler accepts.

It's probably not even all that hard to define a subset of Fortran that
has no undefined behavior. Just check a lot of the things that can be
checked, and throw errors for anything that could possibly go wrong and
you don't check. My guess is that you can get most of the way there
with F plus strict out-of-range checks on all arithmetic results, but
you might have to ditch external I/O too.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Dan Nagle

2007-06-28, 10:06 pm

Hello,

Brooks Moses wrote:

<snip>

> It's probably not even all that hard to define a subset of Fortran that
> has no undefined behavior. Just check a lot of the things that can be
> checked, and throw errors for anything that could possibly go wrong and
> you don't check. My guess is that you can get most of the way there
> with F plus strict out-of-range checks on all arithmetic results, but
> you might have to ditch external I/O too.

The annex in the draft 08 standard detailing undefined behavior
was added as a result of the activities of the OWG-V committee.
The annex gets substantial additions with every meeting,
it's harder than it appears to be to write. The annex includes
some entries that say "paragraph such-and-such lists a whole bunch
of stuff we don't try to describe" in addition to entries
listing specific items.

--

Dan Nagle
Purple Sage Computing Solutions, Inc.

Sponsored Links