Hacker News Reader

Comment by jpfr | Hacker News Reader

All C compilers I know either have VLA or alloca. In one of my projects, a bit of macro magic uses either VLA or alloca to generate a temporary array. Works great! I don't have further requirements here.

Please explain what you mean by "safe" in this context.

View on HN

I mean a way to control for stack overflow. I would like to allocate very large images as VLA, where the size is only known at runtime. If I malloc a too large image, the systems asks for more memory or malloc fails. If I declare a VLA too large, it fails silently in an unrelated part of my program due to stack corruption.

Correct implementations use stack probing (access one word for every page in the allocation) to guarantee that a stack overflow happens immediately rather than resulting in stack corruption.

Alright, but that doesn't really solve anything, does it? It just makes the problem easier to debug.

What's the problem, that the stack is capable of being overflowed? How do you expect the C compiler to fix that?

The stack is not a concept belonging to the C language definition, it is just an implementation choice made by some compiler vendors (all that I know of). The semantics for VLA are clear and very useful. I would certainly not expect that the memory for VLA is implemented on the same stack as the function call stack. My complain for C programming (what I called its "tragedy") is that no compiler provides a mechanism for safely using all available memory via VLA.

Edit: you may answer: "use alloca then". But the syntax for alloca is not that convenient, and the semantics are very different. A common use for VLA is to declare a temporary array inside the body of a loop, this is not possible with alloca.

What platform are you on that cannot detect a stack overflow?

I do not know how to do it on any platform.

My problem is this:

    void f(int n)
    {
            float t[n];
            // what do I write here to check if everything is OK ?
            ...
    }

Modern gcc handles this very well actually. Here: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html

And yet due to several security exploits VLAs are now forbidden in Linux kernel.

Stack probing isn't useful in places with fixed length stacks like Linux kernel.

I used to work on a (now defunct) RTOS whose C runtime didn't support alloca. Functions were all compiled down to a portable bytecode representation that had to statically declare the stack usage, so there was no way to have a function with variable stack size. Not having a real alloca was occasionally an issue for porting C code to it (but less annoying than not having fork()).

Reply on news.ycombinator.com