Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!usc!orion.oac.uci.edu!uci-ics!rfg
From: rfg@ics.uci.edu (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: multiple destructors
Message-ID: <1989Oct21.182759.13138@paris.ics.uci.edu>
Date: 22 Oct 89 01:27:59 GMT
References: <1989Sep30.190719.3340@polyslo.CalPoly.EDU> <6590273@hplsla.HP.COM> <1989Oct19.022635.123@sdti.com>
Reply-To: Ron Guilmette <rfg@ics.uci.edu>
Organization: University of California, Irvine - Dept of ICS
Lines: 67

In article <1989Oct19.022635.123@sdti.com> wmm@sdti.SDTI.COM (William M. Miller) writes:
>In article <6590273@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
>>//the following [weak] example either uses built-in new or malloc for space.
>>//it uses a dirty trick of initializing a field of foo in new.  is there a 
>>//better way?
>
>It is a dirty trick; worse, it's not a general solution.  I wanted some
>way of determining whether or not a given object was automatic, static,
>or heap-based; my thought was to use operator new() in the way you did,
>setting a flag to reveal the history of the object, but the problem is
>that operator new() is not called for auto and static objects and the
>garbage in auto objects could very well impersonate the flag left by
>operator new() in a heap-based object.

There is (I believe) a simple solution.  On most UNIX systems, the actual
memory areas occupied by automatic (stack) variables, static variables,
and "heap" variables are all different.  If you can get the starting and/or
ending addresses of these memory areas (and you usually can) then a quick
comparison of the address of a given object to these addresses will tell you
which area it is in.

For instance, on many systems, the virtual memory space of each process
looks like this:

		----------------  address 0xffffffff
		|              |
		|    stack     |
		|              |
                |..............|  <- SP
                |      |       |
                |      V       |
                |              |
                |              |
                |              |
                |              |
                |              |
                |      ^       |
                |      |       |
                |..............|  <- sbrk(0)
                |              |
                |    heap      |
                |              |
                |..............|  <- edata
		|              |
                |     .bss     |
                |              |
                |..............|
		|              |
		|    .data     |
                |              |
		|..............|  <- etext
		|              |
		|    .text     |
		|	       |
		----------------   address 0


So if the address of the object in question is less than the address of the
(pseudo) variable edata, then it is a "static" variable.  If it is greater,
but still less than the current value of sbrk(0) then it is a heap variable
(probably allocated via the new() operator).  If it is greater than the current
value of sbrk(0) (or greater than the value currently in your stack pointer
register) using an unsigned comparison then it is an "auto" variable.

Check your man pages for "edata", and "sbrk".

// rfg