Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!mcnc!rti-sel!dg_rtp!meissner
From: meissner@dg_rtp.UUCP
Newsgroups: comp.lang.c
Subject: Re: foo.text[0] Was: Auto variable with sizeof == 0
Message-ID: <1222@dg_rtp.UUCP>
Date: Fri, 27-Feb-87 07:42:58 EST
Article-I.D.: dg_rtp.1222
Posted: Fri Feb 27 07:42:58 1987
Date-Received: Sun, 1-Mar-87 11:48:40 EST
References: <4114@brl-adm.ARPA> <4053@utcsri.UUCP> <159@batcomputer.tn.cornell.edu> <626@vu-vlsi.UUCP> <4157@utcsri.UUCP>
Reply-To: meissner@dg_rtp.UUCP (Michael Meissner)
Organization: Data General (Languages @ Research Triangle Park, NC.)
Lines: 30

In article <4157@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes:
>In article <159@batcomputer.tn.cornell.edu> braner@batcomputer.UUCP (braner) writes:
> >
> >typedef struct LINE {
> >	struct LINE *nextline;
> >	struct LINE *prevline;
> >	short       size;		/* s.b. int! */
> >	short       used;
> >	char        text[];		/* !!!!!!!!! */
> >}	LINE;
> 
> .... the offset of 'text' within the structure is *not*
> equal to sizeof(LINE)-1, so the above call to malloc is asking for N
> bytes too many, where N is 3 on a vax and 1 on a 68K or PDP-11.
> 
> The problem is that the struct will be padded out after the one-byte
> 'text' array to meet alignment requirements for the pointer fields.
> 'sizeof(LINE)' includes this padding. 

	yea, and malloc will also add anywhere of 0-64 extra bytes in the
memory allocation.  Extreme micro optimizations like this can backfire.

(by micro optimizations, I don't mean optimizations for memory limited
micro's, but extreme efforts here and there to save a byte or a milli-
second) while ignoring the more stubstanal gains to be made by looking
at the program as a whole for improvements.
-- 
	Michael Meissner, Data General	Uucp: ...mcnc!rti-sel!dg_rtp!meissner

It is 11pm, do you know what your sendmail and uucico are doing?