Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: comp.lang.c
Subject: Re: foo.text[0] Was: Auto variable with sizeof == 0
Message-ID: <4210@utcsri.UUCP>
Date: Mon, 23-Feb-87 19:47:53 EST
Article-I.D.: utcsri.4210
Posted: Mon Feb 23 19:47:53 1987
Date-Received: Tue, 24-Feb-87 03:38:50 EST
References: <4114@brl-adm.ARPA> <4053@utcsri.UUCP>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 53
Summary: 

In article <632@vu-vlsi.UUCP> colin@vu-vlsi.UUCP (Colin Kelley) writes:
>In article <4157@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes:
>>Well, not quite.... 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.

[...]

>But I contend that it isn't necessary to go to all this work to try to rescue
>those 1-3 wasted bytes!  Even if the memory is that important to you, malloc()
>will probably round the number of bytes up anyway, right?  I'm pretty sure that
>any implementation of malloc() on machine which requires such padding bytes
>will certainly round up to a multiple of this padding size (e.g. malloc() on
>a VAX will round the request up to the nearest multiple of M, where M may be
>as small as 4, but is likely to be a lot larger).

Firstly, the average number of wasted bytes will be unaffected by the
rounding process. (Assuming uniform distribution of size requests over
an interval rather larger than the rounding period etc etc). If you
ask for 81 instead of 80 and it is rounded up to the next 16, you get 96
instead of 80.

I suggested this more for the sake of correctness than for the 3 bytes.
You need n bytes, and you write a simple expression that apparently asks
for n bytes, but actually *asks for* n+N bytes. The fact that N is never
large or negative is not really sufficient justification. At least, this
discrepancy should be documented in the code so that those who maintain
after you will not be misled.

Did you realize that this was happening when you wrote the code? If not,
I contend that you made a design error and got away with it. If you did
realize it, fine, but the weirdness of the effect demands a comment in
the code.

>>>Gnuplot (which we posted a couple weeks ago) uses this technique because it
>>>seemed to be the most portable...
>>Feel like fixing it?
>
>Now hold on here!  You've demonstrated that my program MAY waste several bytes
>on its malloc() calls (and I contend that it probably won't).  How does this
>make it broken?  [It may well be broken in some other respect, but that's
>another story!]

Well, I meant to imply through the phrasing of that remark that I didn't
consider it a big deal. But I think we have each spent more time talking
about it than it would take to 'fix' it.
>
>	-Colin Kelley  ..{cbmvax,pyrnj,bpa}!vu-vlsi!colin

-- 
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg
Have vAX, will hack...