Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!epiwrl!epimass!jbuck
From: jbuck@epimass.UUCP (Joe Buck)
Newsgroups: comp.lang.c
Subject: Re: C and unrestrained optimization
Message-ID: <1047@epimass.UUCP>
Date: Mon, 13-Apr-87 11:07:04 EST
Article-I.D.: epimass.1047
Posted: Mon Apr 13 11:07:04 1987
Date-Received: Sat, 18-Apr-87 18:39:32 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <14680@cca.CCA.COM> <790@xanth.UUCP> <995@wanginst.EDU> <819@xanth.UUCP>
Reply-To: jbuck@epimass.UUCP (Joe Buck)
Distribution: world
Organization: Entropic Processing, Inc., Cupertino, CA
Lines: 21
Keywords: optimization verification validation intuitiveness

In article <819@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes:
>C _must_ still support the needs of the systems programmers, or we suddenly
>lose UNIX(m) and its clones, arguably the most widely ported operating
>system in the world, and thus a valuable property to maintain.  Without
>proposing the mechanism ( I helped design one "language", GKS, and one is
>enough), I propose that _a_ mechanism be provided in standard C to force
>execution of the code exactly as the programmer wrote it, to promote the "easy"
>verification and validation of programs written in the language.  Among other
>purposes, this supports the creation of secure kernals for UNIX.

But Kent, ANSI did listen to you.  Previously in C, you were right,
there was no way to force an order of evaluation other than with use
of parentheses.  ANSI first added unary + so the compiler and atoi
would match (atoi allowed a unary + and C didn't).  Lots of people
had the same complaint you did, so unary + was also given the
property that it forces a particular order of evaluation.  I find the
unary + mechanism somewhat ugly, but not as much as some others find
it.  Why do you think it's inadequate?
-- 
- Joe Buck    {hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck
	      seismo!epiwrl!epimass!jbuck  {pesnta,tymix,apple}!epimass!jbuck