Size of stack

[Saginsky]

No description provided.

[Saginsky]

I was wondering if a sensible naive approach would be to allocate a large stack frame for each function under the assumption that the functions our code will be tested on will never need more space than that.

[JaafarRammal]

My personal approach would be to include a counter variable when you enter your function code generation.

The initial value of your counter is based on your operations implementation. If you use the stack for every operation and then clean it, you initialize by the worst case (otherwise setting to 8 works)

Next, at every child context, you increment the counter accordingly at any declaration (based on the type), or suitable stack caller. The child should output into a string variable rather than printing directly (as you haven't declared a header yet)

Finally, you allocate a stack of the size of your counter when initializing your function (aka, your function header), then output the children compilation from the string variable, before closing the function and deallocating accordingly.

This, of course, would only work if your code generation acts recursively with some return context at every node

Update: allocating a large stack frame for every function might result in a stack overflow in case of recursive function calls

[JaafarRammal]

@johnwickerson @ymherklotz (couldn't tag other GTAs for some reason)

About that, I had a small question concerning run-time allocation for arrays. Assume the following independent piece of code:

int allocateQuestion(int a){
     int arr[a];
     for(int i=0; i<a; i++){
          arr[i] = i;
     }
}

The stack allocation of the function allocateQuestion seems to depend on the input a, as it needs to allocate that much memory for the array. Any hints on how to approach that?

I was thinking of linking the size of stack allocation when entering the function definition to the argument a (since the compiler would understand that the array allocation depends on it). But even then, it is one context approach out of many, which doesn't sound pleasant to implement

[johnwickerson]

Variable-length arrays won’t be tested. See: https://github.com/LangProc/langproc-2019-cw/blob/master/c_compiler.md#input

[JaafarRammal]

My bad. Indeed, the spec clears up this issue. Thank you

[JaafarRammal]

@johnwickerson does that include as well Strings (aka char typed arrays)?

From there I assume we will never have to modify a string variable or return a string from a function (since the array size would not be known unless we traverse that array)?

[tobhil98]

Strings are null terminated, so they could in theory vary in length. However, the length of the array would not change.

[JaafarRammal]

Apologies for many questions on this issue 🌵 back on the initial question at the top, can we assume the stack of a scope will never exceed some size or we should implement as it could grow to any size?

[tobhil98]

You should be able to have it grow to any size