Path: utzoo!utgpu!water!watmath!djfiander
From: djfiander@watmath.waterloo.edu (David Fiander)
Newsgroups: comp.unix.wizards
Subject: Finding size of a malloc()ed block (was: Finding names of open files)
Message-ID: <16713@watmath.waterloo.edu>
Date: 4 Feb 88 15:23:56 GMT
References: <2346@mandrill.CWRU.Edu> <339@tandem.UUCP> <7124@ncoast.UUCP> <1427@mips.mips.COM> <461@minya.UUCP>
Reply-To: djfiander@watmath.waterloo.edu (David Fiander)
Organization: U. of Waterloo, Ontario
Lines: 30

In article <461@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
:: : this kind of reminds me of someone who asked how to get the size of a malloc'ed block.
:: : The answer?  "Remember how much you asked for, dimwit!"
:: 
:: Actually, if free() is going to be able to deallocate the space, the
:: dimwit malloc() ought to be salting the size away somewhere, since
:: free doesn't depend on the dimwit programmer telling it how big the
:: block is.
:Of course, a good design would always pass a size along with a pointer.
:Sure, and when you are writing your library sprintf() routine, do you
:want to go out and modify all the calls in all the software in the world
:so that there's a size parameter?  I mean, sprintf() is specified and 
:cast in a huge chunk of concrete by now.  It doesn't include a size field.
:How is a competent software engineer to guarantee that it doesn't overflow
:the caller's array?

The only problem with this is that I usually call sprintf() with a statically
allocated array and, the last time I looked, they _don't_ have sizes associated
with them.  It would be nice to be able to find out the size of a malloc()ed 
block, but first we have to be able to figure out if the pointer we have
actually points at something from malloc().

-- 
It was one of themselves, one of their own prophets, who said,
"Cretans were never anything but liars, dangerous animals and lazy": and
that is a true statment.
	- Titus 1:12

UUCP  : {allegra,ihnp4,decvax,utzoo,clyde}!watmath!djfiander
CSNET : djfiander%watmath@waterloo.CSNET