Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.c
Subject: Re: C common practice. (what it really is)
Message-ID: <6210:Apr2915:21:5391@kramden.acf.nyu.edu>
Date: 29 Apr 91 15:21:53 GMT
References: <TMB.91Apr26145719@volterra.ai.mit.edu> <1991Apr27.024634.586@convex.com> <TMB.91Apr29014917@volterra.ai.mit.edu>
Organization: IR
Lines: 25

In article <TMB.91Apr29014917@volterra.ai.mit.edu> tmb@ai.mit.edu (Thomas M. Breuel) writes:
> Likewise, a compiler
> can only determine that a function is side-effect free if the
> source code to that function is available at compile time.

Yeah. What Jim's really trying to say (but doing a nauseatingly bad job
of saying) is that such information should be part of the procedure-call
interface. If you declare a function ``pure'' (some compilers allow
this), then the function is not allowed to use global variables or call
impure functions, but any caller can assume that the function will
return the same value for the same inputs. Similarly, if you declare a
function with ``arguments 1 and 2 aren't aliased'', then any caller must
make sure that this is true, but the optimizer will have an easier time
on vector machines.

The interesting issues here are what sort of assertions to allow, how
much the compiler should check, etc. A number of experimental languages
have addressed these issues, more or less successfully.

I think Jim's ignorance of the C standard, C common practice, and
available C compilers has been quite thoroughly demonstrated in this
thread, and I hope my comments here make clear that Jim really isn't
thinking about C at all. So can we stop discussing this in comp.lang.c?

---Dan