QNX got this right. No strings in the kernel. Everything is either fixed-length or in user space. A privileged program in user space deals with filenames and such.
Do you have a source for that claim? The C11 standard notes that memory associated with a variable length array can be "squandered" by a longjmp, as far as I understand that shouldn't happen with stack allocation.
Most implementations may use stack allocation, leading to the stackoverflow problems described in the article. However as far as I can tell the standard doesn't require this.
In C89 the ability to pass multi-dimensional arrays to functions was not very useful, since the inner dimensions could not vary at runtime. Fixing this was the main point of the VLA feature, at least for people who work on array data. It would be even more useful, had they supported strided arrays...
If you want string-handling on the heap, you probably also want some sort of a malloc implementation, so you can handle allocation requests that are less than one page, but that's just an algorithm that sits on top of the page allocator.
You don't want to overuse it, though. Page allocation can fail, and more interestingly, it can require blocking - maybe you're not out of memory, exactly, but you've got dirty buffers that need to be flushed to disk (or worse, to NFS). If you're handling a system call from a userspace program, blocking is probably fine. But the kernel runs in more contexts than that. One problem is that the code that handles flushing dirty buffers, and any code that it calls, cannot block; otherwise, you might deadlock, because you're trying to allocate a new page so you can finish free a page. (And in the case of NFS, that includes basically all of the socket code in the kernel.) You also don't want to block inside interrupt handlers, even if the thing the interrupt handler is doing is putting some data on a queue and letting a kernel thread pick it up. Those buffers need to be allocated in advance, or at least come from a special pool of ready-to-use pages that can always be allocated without blocking.
In a kernel that supports swap, you can choose to swap out basically anything to make more room, but that has its own deadlock problem too. Code used by any disk handler (and any filesystem, if you support swap files) cannot allocate memory that can be swapped out; otherwise you might not be able to swap that memory back in. One common approach, which Linux takes, is to say that memory allocated by the kernel simply cannot swap. But that means that you can't allocate too much inside the kernel. NT actually has a swappable kernel pool, and the infamous IRQL_NOT_LESS_OR_EQUAL blue screen means that a kernel driver tried to access data that was swapped out in a context where it wasn't allowed to swap.
Here's the Linux kernel's documentation on its various allocation options:
https://www.kernel.org/doc/html/latest/core-api/memory-alloc...
https://www.kernel.org/doc/html/latest/core-api/mm-api.html#...
Yes. It used to be possible to crash the Linux kernel by doing lots of random I/O, as with a database, along with lots of sequential I/O, and running out of memory so that paging started. This would result in a need to get a page of memory for the kernel when a lock was set that prevented releasing an I/O buffering page. Haven't seen that in years, so I assume it got fixed.
Where they work just fine.