Path: utzoo!attcan!uunet!ncrlnk!ncrcae!ece-csc!ncsuvx!gatech!bloom-beacon!spdcc!ima!think!barmar From: barmar@think.COM (Barry Margolin) Newsgroups: comp.lang.c Subject: Re: Out of range pointers Message-ID: <28227@think.UUCP> Date: 21 Sep 88 19:00:21 GMT References: <867@osupyr.mast.ohio-state.edu> <3200@geac.UUCP> <1430@ficc.uu.net> <1988Sep15.145026.20325@ateng.uucp> <16041@ism780c.isc.com Sender: news@think.UUCP Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge, MA Lines: 31 In article <33547@XAIT.XEROX.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes: >However it would be very nice if there were a library routine that would >tell you whether a pointer was legal or not. One problem with this is that on the segmented machines it is the act of computing such a pointer that is invalid, not the pointer itself. For example, if P is a pointer that happens to point to offset 0 in a segment, *computing* P-1 will cause a fault. So, what you need is a routine that tells you whether a particular offset from a pointer is legal; something like: if (valid_pointer_offset (P, sizeof(*P), -1)) P--; Also, in order for this to work on machines with linear address spaces, all pointers would have to carry around the location and size of the objects to which they point. This is done in Symbolics C, since pointers are actually implemented as two Lisp objects, an array and an offset into the array, and array objects contain their size, which is checked by the microcode/hardware array-indexing operations. Each call to malloc returns a new array, and each stack frame can be treated as an array (this means that it won't detect overflowing from one local array into another in the same frame, but nothing's perfect). Expecting C implementations on conventional architectures to do this is too much. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar