5 Answers
5

These are variable length arrays (VLA), as N is not a constant expression. The const-ness in the parameter only ensures that N is read-only. It doesn't tell the compiler that N is constant expression.

VLAs are allowed in C99 only; in other version of C, and all versions of C++ they're not allowed. However, some compilers provides VLA as compiler-extension feature. If you're compiling with GCC, then try using -pedantic option, it will tell you it is not allowed.

Now why your program gives segfault, probably because of stack-overflow due to large value of N * N:

const function parameter doesn't change anything here, the value is still only known at runtime so you're still relying on a compiler extension. Anyway be it C or C++, the point is- if you need lots of memory, use heap instead (via std::vector).
–
KosJun 18 '12 at 9:17

1

@MartinKristiansen: I edited my answer, saying "The const-ness in the parameter only ensures that N is read-only. It doesn't tell the compiler that N is constant expression."
–
NawazJun 18 '12 at 9:18

@SPIRiT_1984: In fact, it is bad idea to use malloc from the start. Use std::vector when you need dynamic array. Use malloc/new and manage memory yourself, when you've very strong reason to do so.
–
NawazJun 18 '12 at 9:25

It's extremely difficult to detect that the stack is full, and not at all portable. One of the biggest problems is that stack frames are of variable size (especially when using variable-length arrays, which are really just a more standard way of doing what people were doing before with alloca()) so you can't use simple proxies like the number of stack frames.

One of the simplest methods that is mostly portable is to put a variable (probably of type char so that a pointer to it is a char*) at a known depth on the stack and to then measure the distance from that point to a variable (of the same type) in the current stack frame by simple pointer arithmetic. Add in an estimate of how much space you're about to allocate, and you can have a good guess as to wether the stack is about to blow up on you. The problems with this are that you don't know the direction that the stack is growing in (no, they don't all grow in the same direction!) and working out the size of the stack space is itself rather messy (you can try things like system limits, but they're really quite awkward). Plus the hack factor is very high.

The other trick I've seen used on 32-bit Windows only was to try to alloca() sufficient space and handle the system exception that would occur if there was insufficient room.

This code is very non-portable (e.g., don't count on it working on 64-bit Windows) and building with older gcc requires some nasty inline assembler instead! Structured exception handling (which this is a use of) is amongst the blackest of black arts on Windows. (And don't return from inside the __try construct.)

This was all based on the stack checking code that was in the implementation of Tcl 8.4; the code with SEH use was converted to using the first pointer-based method in 8.5, and dropped entirely in 8.6 (which uses a “stackless” engine implementation instead, and so doesn't need this sort of thing nearly so much).
–
Donal FellowsJun 18 '12 at 10:08

BTW, storing the variable-sized arrays on the heap is going to be far more reliable, especially if you can use RAII-techniques to ensure reliable deletion.
–
Donal FellowsJun 18 '12 at 10:11

Malloc does help -- and using malloc was my sollution, but that means that now I have a pointer to keep track of.
–
Martin KristiansenJun 18 '12 at 9:17

Yes, that's true about the pointer, but since it is resided inside single function, there is no problem about that. Just add delete at the end of the function
–
SPIRiT_1984Jun 18 '12 at 9:18

1

If yoy want to allocate arrays dynamically, using std::vector would be my first choice.
–
Bo PerssonJun 18 '12 at 9:22

1

@JoachimPileborg: Keeping track of allocated memory manually is hard in C++, due to the presence of exceptions. Like Kos said, the best solution is to rely on RAII by using a vector.
–
Luc TourailleJun 18 '12 at 11:42

One of the reasons people say it is better to use stack instead of heap memory can be because of the fact that variables allocated on top of the stack will be popped out automatically when you leave the body of the function. For storing big blocks of information it is usual to use heap memory and other data structures like linked lists or trees. Also memories allocated on the stack is limited and much more less than you can allocate in the heap space. I think it is better to manage the memory allocation and releasing more carefully instead of trying to use stack for storing big data.

You can use framework which manage your memory allocations. As well you can use VDL to check your memory leaks and memories which is not released.

but here is the thing, I was developing on a Linux box with some highend hardware, and Spend alot of time figuring out why my code did'nt run on my MacBookPro. The Linux box had no problem with a 4 MB stack alloc, but the OSX box did not like it.
–
Martin KristiansenJun 19 '12 at 13:43