Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #67113

Re: trouble of static working-data-buffers size assumption

From Ken Brody <kenbrody@spamcop.net>
Newsgroups comp.lang.c
Subject Re: trouble of static working-data-buffers size assumption
Date 2015-08-11 11:25 -0400
Organization A noiseless patient Spider
Message-ID <mqd437$m80$1@dont-email.me> (permalink)
References <7654f359-9404-4818-a877-b3a0d5c32d05@googlegroups.com> <b292d473-024c-465c-917e-54bc594ec37b@googlegroups.com> <mqalim$298$1@dont-email.me> <e9706a97-08e4-439c-a228-22645d87f6f0@googlegroups.com>

Show all headers | View raw


On 8/10/2015 2:25 PM, fir wrote:
> W dniu poniedziałek, 10 sierpnia 2015 19:06:10 UTC+2 użytkownik Ken Brody
> napisał:
[...]
>> I usually just use malloc/realloc, and keep track of my current
>> allocation size.  I then have a quick to see if the current buffer is
>> big enough, and realloc if not, storing the new size.  (Sometimes, I'll
>> realloc to X bytes larger than the currently-required amount, to reduce
>> realloc calls and possible memory fragmentation.)
>>
>
> what memopry fragmentation? realloc will give you solid ram chunk, afaik
> no trouble with it..

What happens when you try to realloc the buffer larger, but malloc has 
already allocated the memory immediately following the current buffer?  It 
must get you a new buffer.  Then, when you realloc again for a larger 
buffer, it's possible that the memory immediately following the new buffer 
is also already allocated, so another buffer needs to be returned.  (This is 
probably more noticeable when starting with small buffers, with small 
increments in size.)

You now have chunks of allocated memory with small chunks of now-free 
memory, which may or may not ever get allocated, scattered amongst them.

I didn't mean that realloc() would return a "fragmented" buffer (such as 
disk storage), but rather that the malloc "heap" would become fragmented.

>> No matter how big you make the static buffer, there will be some
>> scenario where it's not large enough.  What do you do then?
>>
> well this leeds me to reallocs.. but in reallity it is some trade-off
> assumptions for reallocs, not 100% clear choice.. though im like to seem
> change to reallocs (last few years i prefered statics and assumptions now
> wonder if to change side)

Well, you still have to handle the case of "I need more memory than the 
static buffer I reserved".

-- 
Kenneth Brody

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

trouble of static working-data-buffers size assumption fir <profesor.fir@gmail.com> - 2015-08-10 07:42 -0700
  Re: trouble of static working-data-buffers size assumption fir <profesor.fir@gmail.com> - 2015-08-10 07:48 -0700
    Re: trouble of static working-data-buffers size assumption Ken Brody <kenbrody@spamcop.net> - 2015-08-10 13:05 -0400
      Re: trouble of static working-data-buffers size assumption fir <profesor.fir@gmail.com> - 2015-08-10 10:21 -0700
        Re: trouble of static working-data-buffers size assumption fir <profesor.fir@gmail.com> - 2015-08-10 10:52 -0700
      Re: trouble of static working-data-buffers size assumption fir <profesor.fir@gmail.com> - 2015-08-10 11:25 -0700
        Re: trouble of static working-data-buffers size assumption Ken Brody <kenbrody@spamcop.net> - 2015-08-11 11:25 -0400
      Re: trouble of static working-data-buffers size assumption Richard Damon <Richard@Damon-Family.org> - 2015-08-10 22:36 -0400
        Re: trouble of static working-data-buffers size assumption Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 22:54 -0700
          Re: trouble of static working-data-buffers size assumption Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-11 13:41 +0100
            Re: trouble of static working-data-buffers size assumption Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-11 08:27 -0700
  Re: trouble of static working-data-buffers size assumption David Brown <david.brown@hesbynett.no> - 2015-08-10 18:22 +0200

csiph-web