Is it theoretically possible to dynamically grow array size in stack memory?
Yes, it is certainly possible. It really depends if you want it enough to pay the price in terms of complication.

First of all, I would strongly recommend that your array should have negative indices: a[-1], a[-2], and so on. This will be good because the stack grows downwards, and if you adopt this convention then you will not need to move all your existing array elements down to the new array position every time you enlarge the array.

After that, it is really a linguistic question. In assembler you can obviously do it, because you can do anything in assembler. Whenever you want your array to be n bytes bigger, just subtract n from the stack pointer.

In C there is often a function - disapproved of by all respectable computer scientists and therefore very useful when it is useful - called alloca or _alloca - which allocates n bytes of data on the stack and returns a pointer to the new allocation. I would be very surprised if two consecutive alloca calls did not just allocate contiguous stack space, so although there isn't a realloca function, you could effectively simulate its behaviour.

Where life gets interesting is when the compiler decides to use the stack for its own purposes: for instance, it might precompute the arguments for several function calls and push them all onto the stack before calling any of the functions. Usually such compilers notice a call to alloca and disable optimisations in the function that uses it - this is one of the reasons for disapproving of alloca.

The main difficulty you would run into would be that, if you wanted your array indices to be "the right way up" - a[0], a[1], a[2] and so on - then every reallocation would require data to be moved, which is a bore. And you can't write your own function in C to do this (that is, both the extra stack allocation and the data movement) because when you call a function, you usually push a return address onto the stack, so the stack-based array is (as you showed in your pictures) blocked by that extra piece of data and can't be enlarged. You would have to write a special realloca function in assembler which pops the return address and keeps it safe; subtracts an appropriate amount from the stack pointer; pushes the return address again; and then does the necessary memory movement. It would actually be quite fun to implement, though not at all portable because different systems will use the stack in different ways in a function call.



Is it used? Yes, I have used alloca for things I know to be small, because I love not having to rampage all over the heap and I love not having to deallocate. But your more elaborate scheme - I haven't heard of anyone who has done it.

Except in assembler - where one can do a beautiful merge sort by using the stack to store data.