3

For example, if I allocate more memory space then needed on a C string is there a way to return back the unused memory? Or is this automatically done?

char *x = malloc(256);
strcpy(x, "Hello World");
// return back unused x memory allocation
lostAtSeaJoshua
  • 1,695
  • 2
  • 21
  • 34
  • 5
    @Arvnid!!! That doesn't exist in [tag:c]. And if you do in *c++*, you invoke undefined behavior, because `delete` is used when you allocate with `new`. And in this case it would be `x = new[256];` and then also `delete x;` is wrong, and it would be `delete[] x;`. – Iharob Al Asimi Feb 04 '18 at 01:01
  • BWT: `char *x = strdup("Hello World");` or at least `char *x = malloc(12); if (x != NULL) strcpy(x, "Hello World");`. – Iharob Al Asimi Feb 04 '18 at 01:03
  • If you know that you are going to use only 12 bytes, then why don't you use `malloc(12)` instead of 256? – Pablo Feb 04 '18 at 01:04
  • Completing @Pablo's comment, you should use `malloc()` precisely when you don't know how much memory to allocate until runtime. So when you know, you should now *exactly* how much. – Iharob Al Asimi Feb 04 '18 at 01:10
  • @IharobAlAsimi what if the memory space is not known at compile time? For example in a program for user input or reading a file and dealing with unknown string size. – lostAtSeaJoshua Feb 04 '18 at 01:58
  • @lostAtSeaJoshua User input should be constrained to some size. Example: 1024 for a name. Unbounded user input is a security risk. – chux - Reinstate Monica Feb 04 '18 at 03:48

2 Answers2

7

You can call realloc to change the size of an allocation; this can be used to make it bigger or smaller.

The computer would have no basis for automatically making your allocation smaller.

Scott Hunter
  • 48,888
  • 12
  • 60
  • 101
2

It's not automatically done. That's both, the nice and horrible thing about manual memory management.

You would need to explicitly call free(x); to release the memory back to the operating system. And it's a pain to keep track of your malloc()/free() pairs, but it pays off because you have fine grained control over the memory your program uses.

If you want to allocate just the exact amount of memory, then you should. Normally when you call malloc() you don't know the allocation size at compile time, so normally you would allocate the exact amount of memory.

If you want a grow/shrink memory buffer you should take into consideration the fact that malloc() is a expensive call. So you would normally allocate enough — a good estimate of how much you need — memory and then shrink it when you know that it wont grow more, or grow it if you estimated too little.

Iharob Al Asimi
  • 52,653
  • 6
  • 59
  • 97
  • What's the nice part? – Scott Hunter Feb 04 '18 at 01:06
  • @ScottHunter You have fine control over the memory allocation of your program. If you are careful, and use the right tools you will be able to write memory efficient code without any bugs. – Iharob Al Asimi Feb 04 '18 at 01:08
  • I'd call that more "useful" than "nice," but YMMV. – Scott Hunter Feb 04 '18 at 01:09
  • 2
    @IharobAlAsimi Your mileage may vary while looking for YMMV. – chux - Reinstate Monica Feb 04 '18 at 03:50
  • @IharobAlAsimi Beginner here. How do you know that `malloc()` is an expensive call? Is there a list somewhere with this information? Or did you make a program to test how long it takes? – user56202 Feb 21 '22 at 19:57
  • @user56202 Please take a look at this https://stackoverflow.com/a/24057744. You can also google it. There would be a lot of posts regarding this. Of course, when I say expensive, I do not mean that it will make a program slow or imply that. But if you need to frequently increase some buffer, do it in big chunks so that you don't need to keep calling `malloc()` for that. It is a strategy that is very frequently used. – Iharob Al Asimi Feb 22 '22 at 20:12