🚀 go-pugleaf

In article <4jol6e$1rr@solutions.solon.com>,
J. Kanze <kanze@gabi-soft.fr> wrote:
>In article <4jmcnr$lr2@solutions.solon.com> stanr@tiac.net (Stan
>Ryckman) writes:

[snip]

>|> Or, if you don't need reentrant or resursive code, you can do:
>|> 	static void *tmp = NULL;
>|> 	static size_t tmp_sz = 0;
>
>|> 	if (sz > tmp_sz) {
>|> 	    .... use realloc here .... you get the idea ....
>
>I wish I'd have thought of this when I actually encountered the problem.
>In the real case, the original author of the function had used multiple
>returns, and I had a bit of a job finding all of the places where I had
>to insert the `free'.  (The original code simply overwrote the rest of
>the stack if sz were larger than EXPECTEDMAXSIZE.  Which sort of
>explains why I was looking at it in the first place:-).)

When I first "invented" this it was the same problem... something
on the stack (i.e., "auto") sized at EXPECTEDMAXSIZE, written
by a junior programmer because the data could *NEVER* be larger.
Of course, things changed, and the data became larger (but, to
make things more fun, only about once per day in a continuous
data stream), and I inherited the problem of fixing the mysterious
occasional crashes.

The old moral:  *never* trust your inputs.

[more snipped]

>Better yet: unless memory is really tight, have it double the size.
>This will set a fairly reasonable upper bound on the number of reallocs
>you will have to do.

Not necessarily better.  If you're at 40% of your machine's
physical memory, doubling could be a real performance killer.
With my suggestion (add some amount to the size and realloc)
you will rapidly reach the max if the sizes arrive "randomly".
Any strategy here would involve knowing something about your
target system, I think, but probably something like
11*(sz+C)/10 where C is much less than the physical memory
on your computer would be safer (even a few hundred realloc calls
rather than a dozen or so shouldn't matter, if the calls
occur with an "unlucky" distribution of sz values).

Cheers,
Stan.

ps - Your article was posted as a "sibling" article to mine
rather than a "child".  Your news posting software may be
doing something incorrect with references (specifically,
dropping one.)
--
Stan Ryckman  (stanr@tiac.net)