Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU
From: MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU
Newsgroups: comp.lang.c
Subject: Undelivered mail
Message-ID: <12264@brl-adm.ARPA>
Date: 12 Mar 88 05:19:30 GMT
Sender: news@brl-adm.ARPA
Lines: 55

Subject:  Re: nasty evil pointers

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C@BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6417
          for SXJVK@ALASKA; Fri, 11 Mar 88 19:47 AST
Received: by UWAVM (Mailer X1.25) id 4265; Fri, 11 Mar 88 20:41:06 PST
Date:         Thu, 10 Mar 88 00:46:25 GMT
Reply-To:     Info-C@BRL.ARPA
Sender:       Info-C List <INFO-C@NDSUVM1>
From:         Dave White <backstro@silver.bacs.indiana.EDU>
Subject:      Re: nasty evil pointers
Comments: To: info-c@brl-smoke.arpa
To:           Vic Kapella <SXJVK@ALASKA>

In article <13100003@bucc2> brian@bucc2.UUCP writes:
>
>It would be nice if we could check every pointer as
>it was used...
>
>
>If pointer
>pointed, say, into the operating system or the text space, the function
>would print a message and exit(). Otherwise it would return.
>
>Without source to the compiler it could
>be a major project. Does anybody know a way this could be done, perhaps with
>something like lex?
>
Lattice C 3.0 (and, I suppose, more recent versions) allow the size of
the stack and the size of the heap to be specified at runtime -- one
uses an argument of the form
   =ssize/heapsize
which the runtime startup routine digests before calling main().
Given such a beast, Lattice can provide isxxxx() functions that
determine whether a passed pointer points within an expected space.
However, the programmer must call them explicitly.

This makes it possible to determine when a wild pointer endangers the
machine.  It has the disadvantage that the proper heapsize might need to
be fudged, as well as the stacksize....  developing code for 8086's anf
friends is painful enough...

The sanest way to do what you want automatically is to build it into the
compiler itself.  Because compilers frequently call internal functions not made
available to the user, and because of the difficulty of cases like the
one you mention, it just isn't practical to write a pre-processor for
this -- you'd be halfway to rewriting the compiler!
>---
>  When the going gets weird, the weird turn pro.
No, they just bring out an Optimizing Turbo 5.0 version :-)
--
backstro@silver.bacs.indiana.edu