Xref: utzoo comp.unix.wizards:6324 comp.lang.c:6926
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!amdahl!cerebus!wjvax!brett
From: brett@wjvax.UUCP (Brett Galloway)
Newsgroups: comp.unix.wizards,comp.lang.c
Subject: Re: To find out the names of open files in a process
Message-ID: <1210@wjvax.UUCP>
Date: 1 Feb 88 00:00:45 GMT
References: <2346@mandrill.CWRU.Edu> <339@tandem.UUCP> <7124@ncoast.UUCP> <904@thorin.cs.unc.edu> <1427@mips.mips.COM> <2672@bloom-beacon.MIT.EDU>
Reply-To: brett@wjvax.UUCP (Brett Galloway)
Followup-To: comp.lang.c
Organization: Watkins-Johnson Co., San Jose, Calif.
Lines: 33

In article <2672@bloom-beacon.MIT.EDU> eichin@athena.mit.edu (Mark W. Eichin) writes:
>>[why isn't there an msize() routine that returns the actual amount of space
>>allocated by malloc()?]
>In summary: there IS a reason that there isn't an msize() by default,
>it is a constraint upon the allocator which can be overly restrictive
>in certain usage patterns.

I posted the other day another reason for making such a feature (a feature
to return the *actual* malloc()'d size available to the user) available.
I neglected to mention that I was thinking in terms of a variant malloc()
that returned the actual size as well as the character pointer.  I agree that
an after-the-fact msize() routine might be overly expensive.  However, it seems
to me that a variant malloc() that reported what it actually allocated could
be had for free.  I mean a routine like

	char	*mallocsize(size,actual)
	unsigned size;
	unsigned *actual;

(with types ala BSD -- fill in your own types).  If the implementor were
lazy, or forgot to implement it at all, he (or you) could just use

	char	*mallocsize(size,actual)
	unsigned size;
	unsigned *actual;
	{
		*actual = size;
		return(malloc(size));
	}
-- 
-------------
Brett D. Galloway
{ac6,calma,cerebus,isi,isieng,pyramid,tymix}!wjvax!brett