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.arch,net.lang.c Subject: Re: get size of malloc'd object Message-ID: <1635@mmintl.UUCP> Date: Wed, 9-Jul-86 03:35:55 EDT Article-I.D.: mmintl.1635 Posted: Wed Jul 9 03:35:55 1986 Date-Received: Fri, 11-Jul-86 22:06:14 EDT References: <165@daisy.UUCP> <334@valid.UUCP> <2206@peora.UUCP> Reply-To: franka@mmintl.UUCP (Frank Adams) Organization: Multimate International, E. Hartford, CT Lines: 28 Xref: linus net.unix:7845 net.arch:3350 net.lang.c:8949 In article <2233@peora.UUCP> jer@peora.UUCP writes: >[Frank Adams] >> Depends on what you mean by "portable". Certainly, it is possible to use >> this number in an implementation-dependent way; but there are natural and >> non-implementation-dependent ways to use the information. E.g., if one is >> allocating character strings and one of them grows, one can try to fit the >> expanded string into the allocated size, and only reallocate (and reset all >> the pointers to the data) if it won't fit. > >Well, actually it depends on some other factors, just fairly abstract ones >(and thus debatable). According to the System V manual, "Malloc returns a >pointer to a block of at least _size_ bytes suitably aligned for any use." > >The problem is that, unless the definition is constrained more, it makes >it impossible to prove a program that uses the "actual size allocated" >correct. So constrain the definition more. It isn't written in stone. I dare say that there is no system in existence that would fail under the assumption that the actual size allocated fits in a long -- probably none would fail assuming an int. Compared to the total task of dealing with the C environment in such a way that correctness proofs become possible, this is a very tiny issue, easily dealt with. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108