Tater I'm happy you solved the problem 
Anyway I should correct my previous description that refers to an architecture with stack that grows toward higher memory addresses. In reality in IAPX it grows toward lower addresses, so more space you reserve more lowers the address.
I wrote it in a rush, but anyway the concept is absolutely correct 
Your parameters, with return address and stack pointer original value are on one side of frame pointer EBP, local variables on the other. Later I will correct it, now I'm very busy.
No worries... I understood the stack's behaviour and realized you'd made a minor factual error.
It was the behaviour when closing a scope that was of the most concern...
What I now understand is that Pelles C has two sets of behaviours depending if the optimizations are on or off... with something as crucial as stack organization, this was totally unexpected.
Optimizations off ... every variable gets stack space at function entry... which is not cleared until the function exits. This essentially transforms functions with private scopes into standard functions, in terms of stack utilization.
Optimizations on ... scoped stack space is reused ... "big enough for biggest" stack space is released on function exit. This would seem to indicate that private scoping offers no advantage in stack utilization unless you are creating 2 or more private scopes (but still has other advantages).
Like I said... totally unexpected.
Fortunately it is very rare that I get into these "monster functions" (this is perhaps the 4th time in all the years) although I do use private scoping a fair bit. Far as I know this is the first time I've run into this issue and (silly me) trusting the text books really didn't help this time...
Thanks again for helping me sort it out.
