Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Bug in Green Hills compiler
Message-ID: <6883@brl-smoke.ARPA>
Date: 20 Dec 87 00:21:32 GMT
References: <482@cresswell.quintus.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23
Keywords: i[a] not understood

In article <482@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>BTW: now that the ANSI C committee have decided to flout centuries
>of mathematical tradition and make (X+Y) different from X+Y, what
>does this do to E1[E2]?

First of all, you appear to be under some misunderstanding.
(X+Y) is no more different from X+Y under the new rule than it ever was.
The only "flouting of mathematical tradition" is that done by the hardware,
which instead of working with abstract mathematical symbols uses imperfect
representations of numeric values.  Overflow and loss of precision were by
no means invented by X3J11; we just had to figure out how to cope with them.

The meaning of E1[E2] is unaffected by the new non-regrouping rule.
It is still equivalent to E2[E1].

It is certainly true, as you said, that straightforward reasoning about
a program can go seriously wrong, but not for the reason you stated.
The real problem is that, although program source notation resembles
mathematical notation, it is NOT the same thing and does NOT have the
same properties.  Assumptions to the contrary are what leads one astray.

There are methodologies for correct reasoning about programs; the names
Dijkstra and Hoare come to mind.