The only valid answer is vague: "too much is when the stack overflows."
Unless you are in complete control over the implementation of every line of code between the program's entry point and the function in question, you can make no assumptions about how much stack is available. You cannot, for example, guarantee that calling this function will never cause a stack overflow:
The default 8 MiB stack on modern Unixes is quite a lot of room as stacks go, especially to someone like me who's enough of a geezer to remember CPUs with 8-bit stack pointers. The practical reality is that you're unlikely to blow through it without trying. If you do, exceeding the stack limit is usually considered a segmentation violation, and systems with enough memory management to detect it will send a
SIGSEGV when it happens.
You do have a couple of options. First is to not guess how much stack is available and ask the system. Anything conforming to POSIX will have a
getrlimit(2) function that will tell you the upper limit.
RLIMIT_STACK is the specific limit you want. The second is to monitor how much stack your programs are using and make decisions about automatic variables vs. dynamic memory allocation based on that. There are, as far as I know, no standard functions to determine how much of the stack is used, but programs like
valgrind can analyze it for you.