Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!husc6!necntc!ima!compilers-sender From: daveb@geac.uucp (David Collier-Brown) Newsgroups: comp.compilers Subject: Re: Pointers in C Message-ID: <1401@ima.ISC.COM> Date: 13 Jul 88 13:39:51 GMT References: <1262@ima.ISC.COM> <2109@hubcap.UUCP> Sender: compilers-sender@ima.ISC.COM Reply-To: daveb@geac.uucp (David Collier-Brown) Organization: The Geac "Global Pessimizer" Department Lines: 69 Approved: compilers@ima.UUCP In article <2109@hubcap.UUCP> mrspock@hubcap.clemson.edu (Steve Benz) writes: [discussion of binding of pointers to arrays/heap] |Nevertheless, I can think of a rather large set of programs that |aren't "valid K&R C programs": All those programs that use varargs. |(At least by the definitions of varargs that I've seen.) Yes, it is hard to make any usefull assumptions about a pointer being used for varargs processing, or for wandering through a core/executable file in a debugger (the other "fun" example I run into often). |> Also, on page 90 of K&R (version 1): |> "You should also note the implications in the declaration that a pointer is |> constrained to point to a particular kind of object." | |I think a C compiler would be very hard pressed to guarantee this sort |of thing, with the cast operation lurking about. The only way to absolutely |guarantee this is to do some unpleasantly complicated typechecking on |every object in memory. In some sense, that's what an optimizing compiler tends to have to do. In tightly-typed languages, there's more information about the use of a pointer (and syntactic sugar), but one can extract the required information from C in many of the common cases, based on the **particular** optimization being applied. Let's look at the example that started this discussion thread: a pointer in a copy routine which, because it can point anywhere, is proposed to invalidate my register history... (I'm assuming that the optimizatio in question is fetch minimization). If the pointer is kept "within bounds" by the copy routine, then we can assume that passing the pointer to the routine has exactly the same effect as a local assignment through the pointer. If the pointer is not being kept within bounds, both the non-optimized copy code and the optimized calling code fails. But it fails in a manner which does not involve the optimization! If a function scribbles on memory, and I'm trying to do fetch-minimization from memory, it doesn't matter if the fetch minimization is rendered incorrect, because the fetch **itself** has been rendered incorrect by the scribbler. You can apply this same kind of argument to a number of common cases of optimization in the presence of errors, to discover which optimizations are independent of/orthogonal to the error... And apply more optimizations than expected on first glance. (In a real sense, you're doing complicated mental typechecking on the operations when you write the optimizer). In my global pessimizer, I assume all registers and all stack entries are invalid at all times, and so generate code which depends only on read-only data in the linkage segment and random numbers in the heap. --dave (whats a correctness?) c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers Ltd., | Computer science loses its 350 Steelcase Road, | memory, if not its mind, Markham, Ontario. | every six months. -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request