Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!pwa-b!mmintl!franka From: franka@mmintl.UUCP (Frank Adams) Newsgroups: net.unix,net.lang.c Subject: Re: get size of malloc'd object Message-ID: <1601@mmintl.UUCP> Date: Tue, 24-Jun-86 09:56:16 EDT Article-I.D.: mmintl.1601 Posted: Tue Jun 24 09:56:16 1986 Date-Received: Fri, 27-Jun-86 04:00:51 EDT References: <165@daisy.UUCP> <334@valid.UUCP> <2206@peora.UUCP> <2081@umcp-cs.UUCP> <2216@peora.UUCP> Reply-To: franka@mmintl.UUCP (Frank Adams) Organization: Multimate International, E. Hartford, CT Lines: 31 Xref: linus net.unix:7703 net.lang.c:8781 In article <2216@peora.UUCP> jer@peora.UUCP writes: ~>determine alignment by difference between consecutive malloc'ed objects >you're not guaranteed that the two consecutive mallocs will give >consecutive blocks of memory -- they certainly won't be likely to after >some other mallocs and frees have been done. It's hard to see a situation >where the initial allocations wouldn't be consecutive, but it's not >guaranteed, and that's sufficient reason to have doubts. (1) If you are using the "buddy system"[1] for storage allocation, and the total storage available is not a power of two, initial allocations might well not be consecutive. (2) Some version of malloc have header information about the allocated block immediately before the block. For such versions, the distance between blocks always includes at least one such header. (3) Storage may be allocated and freed in the process of starting the program, before your code gets control. (4) Storage for all programs may be allocated from a single heap, so that other tasks would have done malloc's and free's before (or even between) yours. In short, this is completely unreliable. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108 [1] For a description of the buddy system, see Knuth, _The_Art_of_Computer _Programming,_vol._1,_Fundamental_Algorithms_.