Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.lang.c
Subject: Re: extensible arrays
Message-ID: <5627@mimsy.UUCP>
Date: Sat, 28-Feb-87 20:30:51 EST
Article-I.D.: mimsy.5627
Posted: Sat Feb 28 20:30:51 1987
Date-Received: Sun, 1-Mar-87 17:49:08 EST
References: <4114@brl-adm.ARPA> <4053@utcsri.UUCP> <1222@dg_rtp.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 31

Following much ado about extensible arrays inside structures, e.g.,

	struct string {
		int	s_len;		/* actual length */
		int	s_space;	/* space allocated */
		char	s_text[0];	/* really longer */
	};

	...
	/* alloc is a malloc front end that aborts on failure */
	s = (struct string *) alloc(sizeof (*s) + length);
	s->s_len = length;
	s->s_space = length;
	...

in article <1222@dg_rtp.UUCP> meissner@dg_rtp.UUCP (Michael Meissner) writes:
>yea, and malloc will also add anywhere of 0-64 extra bytes in the
>memory allocation.  Extreme micro optimizations like this can backfire.

True, but it is worth pointing out that if your malloc has a constant
rounding, this wins; and even if it has a variable rounding, if the
rounding is proportionate to the size of the object being allocated
and the overhead plus rouding for the `normalised' structure (here
2*sizeof(int) + sizeof(char *)) is larger than the average rounding
for the extensible version, the extensible version still wins.  It
may even be possible to determine this at run time, and self-configure.

(It is also worth pointing out that this takes a lot of effort.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu