Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!lll-crg!seismo!gatech!akgua!akguc!codas!peora!jer
From: jer@peora.UUCP (J. Eric Roskos)
Newsgroups: net.unix,net.unix-wizards,net.arch,net.lang.c
Subject: Re: get size of malloc'd object
Message-ID: <2222@peora.UUCP>
Date: Sat, 28-Jun-86 23:26:15 EDT
Article-I.D.: peora.2222
Posted: Sat Jun 28 23:26:15 1986
Date-Received: Mon, 30-Jun-86 04:53:03 EDT
References: <165@daisy.UUCP> <334@valid.UUCP> <2206@peora.UUCP> <2081@umcp-cs.UUCP> <2216@peora.UUCP> <14533@ucbvax.BERKELEY.EDU>
Organization: Concurrent Computer Corporation, Orlando, Fl
Lines: 49
Xref: watmath net.unix:8442 net.unix-wizards:18638 net.arch:3616 net.lang.c:9636

>    It seems obvious that the solution to the whole problem is to define a
> structure which contains two fields: the pointer to memory returned by malloc,
> and an int (or long int, or whatever) which contains the size of the block
> requested from malloc.  This is guaranteed to work, as opposed to the many
> alternate implementations that have been proposed and are guaranteed to fail
> on at least some architectures.
>    Note that in a strongly-typed language you would have had to do the right
> thing from the beginning...

Wouldn't malloc() be something of a hole in a strongly-typed language
anyway?  I mean, if you are going to allocate an object in a strongly-typed
language, you should have to allocate an object of a particular type, not
just "a block of memory that is aligned on the worst-case alignment
boundary".

The above "obvious" solution has the shortcoming that either you return a
pointer to the structure (in which case the memory allocator doesn't work
like standard malloc), or you have to have a way to coordinate the structure
with the allocated block of memory: when the user frees a block, you have
to find the structure given only the address of the block -- which is
stored in the structure, but not in the block you're freeing.

From this discussion I have become firmly convinced (well, semi-firmly)
that this reflects a problem in the C language.  Specifically, C does
allow constraints on alignment, which is reasonable, but there isn't any
way to find out anything about alignment from within the language.
The ANSI C folks should look into that.  Maybe there should be an operator
"alignment" that works the same as "sizeof" but gives the alignment required
for a specified type; and some defined constant (like MAXALIGN) that gives
the worst-case alignment.  For example, how can you write a portable
malloc?  After all, that's really what we've been trying to do here.  You
can argue "malloc is sort of part of the language so it is OK for it to
have to have changes made to it when you port it to a different machine,"
(or put "is too close to the hardware" in place of "is part of the
language", or some similar argument) but the problem is, that seems to give
malloc an unduly privileged status.  What if you do want to write your
own malloc?  Malloc really isn't "part of the language," and there's no
reason why it should have to be considered "too close to the hardware"
except inasmuch as there is this problem with C that you have to tell your
program something you've determined from an outside source that couldn't
be found out from within the language itself.  But of course the
compiler knows about alignment requirements, and we have here a 
demonstrated "need to know," only the compiler won't tell you what it
knows because there's nothing in C to let it do so! 

Well, the above is my argument for adding information about alignment
to the C language.
-- 
E. Roskos