1

What is the difference between defining an array of a length that is definied before runtime (depends on command line arguments) with array[size] and using malloc()? array[i] leads to the data put on the stack, malloc() uses the heap[see this stackoverflow]

So with large Data I can run into stackoverflows, but on a new machine a total of 30 chars and ints should not be problematic (Stack is around 1MB on windows according to this).

So I am probably missing something obvious.

As far as I understand, when defined in main(),the two should be the same:

Example 1

int size; // depends on some logic
char array[size];

Example 2

int size; // depends on some logic
array= (char *)malloc(size * sizeof(char));
free(array); // later after use

But when I use the array inside of functions and hand it over as a pointer (func(char* array)) or as an array (funct(char array[])), sometimes the gdb-debugger let's me know that the function gets handed corrupted data in #1 , using malloc() fixed the issue.

Is array[i], not okay to use when it is not determined at compile time? Is it some scoping issue? This answer has a comment suggesting such a thing, but I don't quite understand if that applies here.

I am using C99.

Sourav Ghosh
  • 133,132
  • 16
  • 183
  • 261
Nivatius
  • 260
  • 1
  • 13
  • 1
    Note that the arry is no longer valid once the enclosing scope (function, block) is left. As long as you pass the reference 'down', that is to functions you call inside the scope all is well, but as soon as you try to pass it as a return value of your function the reference is no longer valis. – Mario The Spoon Jan 20 '20 at 08:25
  • @MarioTheSpoon exactling what I am thinking, that is why I said the array is defined in main. it only gets handed down. this is why I am confused. I don't return the value of the array in that function. – Nivatius Jan 20 '20 at 08:28
  • 4
    Can you show a [mcve]? – Sourav Ghosh Jan 20 '20 at 08:29
  • @SouravGhosh So far I failed to even reproduce it. Under Linux the error does not appear at all, I will try win10 again and update the question. – Nivatius Jan 20 '20 at 08:37
  • You need to post more complete code and more information (e.g. exact gdb message, value of size, etc.). Assuming that VLA is supported there is nothing wrong with the code/info posted. – Support Ukraine Jan 20 '20 at 08:37
  • As other have said, you should produce a [mre]. You can have a look at this answer that I wrote some time ago: https://stackoverflow.com/a/58163652/6699433 Maybe it's a dup – klutt Jan 20 '20 at 09:07

1 Answers1

0

The main difference is that arrays declared with a fixed size are stack allocated (and references to it or its elements are valid only within its scope) while mallocd arrays are heap allocated.

Stack allocation means that variables are stored directly to the memory. Access to this memory is usually very fast as and it's allocation is done during compilation.

On the other hand, variables allocated on the heap have their memory allocated at runtime and - while accessing this memory is slower - your only limit is the size of virtual memory.

Have a look here:

https://gribblelab.org/CBootCamp/7_Memory_Stack_vs_Heap.html

Dr.Kameleon
  • 22,532
  • 20
  • 115
  • 223
  • 4
    Care to explain why access to that memory is slower? The only thing I can think of is locality of reference, but that depends on many more factors IMHP Also I would word the runtime/ compile time allocation differenlty since it is always allocated during runtime (How else could we run into an StackOverflow) – Mario The Spoon Jan 20 '20 at 08:38
  • @MarioTheSpoon https://stackoverflow.com/questions/2264969/why-is-memory-allocation-on-heap-much-slower-than-on-stack – Dr.Kameleon Jan 20 '20 at 08:42
  • 3
    @Dr.Kameleon Allocation is (slightly) slower but **accessing memory is uniform** (at least on every common machines). – Jean-Baptiste Yunès Jan 20 '20 at 08:50
  • @Jean-BaptisteYunès my thinking also - so the answer should be re-worded to allocation and not access – Mario The Spoon Jan 20 '20 at 08:53
  • 1
    @MarioTheSpoon He refers to the fact that accessing the heap can be made only through indirection (pointer). Alas this is not a good reason to say heap is slower...because registers, low-level caches, etc, may hide the whole. – Jean-Baptiste Yunès Jan 20 '20 at 08:54
  • 2
    "it's allocation is done during compilation" this seems obviously wrong when talking about VLA because their size is not know at compile-time. It even sounds wrong even for any variable with automatic storage. If everything were know at compile time, stack overflows would hardly ever occur. – Bktero Jan 20 '20 at 08:55
  • @MarioTheSpoon Possibly because of the speed difference between a SRAM and a DRAM. It's said that [a stack is always located in first-level cache](https://stackoverflow.com/questions/37749269/is-the-stack-in-a-cache). Heap might be located in DRAM. – KaiserKatze Jan 20 '20 at 11:02
  • I just took a look at the reference site provided by @Dr.Kameleon, where it reads "Heap memory is slightly slower to be read from and written to, because one has to use pointers to access memory on the heap. We will talk about pointers shortly." – KaiserKatze Jan 20 '20 at 11:05
  • @KaiserKatze cache/ nocache yes, but thi was what I meant with locality of reference - and there also heap can be cached due to frequent use. So the more correct statement should be that this will most likely occur for first time or infrequent accesses. I think that just putting it as it is written in the answer is misleading – Mario The Spoon Jan 20 '20 at 12:08
  • 2
    @KaiserKatze Stack allocations more often than not will indeed be cache-hot and paged-in, but even a stack access following a large VLA allocation might cause a page fault and/or a cache miss. Access to heap memory might be more likely to cause a page fault and/or a cache miss, but once it's paged in and cached, access to it is as fast access to stack memory. At the hardware level, there's (on common architectures) no difference between stack memory and heap memory--they're just different places within the same memory. – Petr Skocik Jan 20 '20 at 12:14