Sounds like you should wrap the C alloca interfaces and do your own container either like `UncheckedArray[T]` or like `seq[T]`.
There is nothing fundamentally wrong with growing your stack big on many machines these days, but deployment can be tricky. Limits are often still set up with 1990s era hardware assumptions. And stack size limits are, well, very variable..from 64 KiB to 8 MiB is typical. The original idea was to crash programs with unbounded recursions rather than crash your system from OOM. Like limits on open files, what sorts of leaking/unboundedness errors people make may/may not be what was commonly assumed when the OS was designed and/or the culture of default settings in force today was established. This can honestly just vary among people and prog.langs - some make auto-closing files pretty easy, for example. The limits are sort of a poor man's guard rail for C programmers. For example, it was common to see a soft limit of only 64 open files on many Unix boxes until quite recently, and I would be unsurprised if when this limit was introduced it was considered generous under some rationale like "recursive directory tree walks are _never_ that deep". Re overflow - I usually [configure generous limits](https://forum.nim-lang.org/t/5703#35415). To not rely upon sysadmin configs on Unix, you can probably just unlimit it with `setrlimit` at the start of your program with Nim's `posix.setrlimit`. "Probably" because the sysadmin can have low hard limits...So, you should be careful to handle errors there and error out with a "fix your hard limit this way..." kind of message. In the (probably) rare case that the user has no admin rights or cannot persuade the admin to bump them up, there could be a deployment problem. [It seems possible](https://stackoverflow.com/questions/52437987/port-getrlimits-setrlimit-on-windows) on Windows, but you may need to do some `passC/passL` type mojo or have a special build unless someone has made that part easier in Nim. Anyway, to clarify @mratsim's warning - you don't **_have_** to avoid using lots of stack memory, **_but_** if you do plan on doing that a little extra care like the above ideas will be appreciated by your users.
