You're writing code that you've already been told won't work and been told why it won't work, and are still complaining that it's crashing... That makes it a programmer error. C is unusually freeform for a language -- it will happily chop off its own foot if you tell it to -- and the answer is to not chop off your own foot. If you ask for a 3-gigabyte object on the stack, it will give you a 3-gigabyte object on the stack, even though that may be thousands of times larger than the maximum size your system will let you have and cause crashes whenever you actually try to use anything beyond a certain point.

Use the stack as intended, and it won't crash. Use it not as intended, and you are into the realm of 'undefined behavior'. Pushing the limits is going to tell you more about your system than the language itself... It's not erratic. The results of such strange code are quite predictable in a way -- you know they won't be stable in all compilers and systems. Many compilers won't even compile it, since array dimensions are supposed to be constants, not lvalues, and certainly not function return values cast from floating point!

1) You are allocating enormous things on the stack. This is a no-no. Don't depend on having more than sixteen megs of stack space -- which is a system setting, not a compiler one, so the same executable may crash on some systems but not others! You're trying to allocate entire gigabytes which obviously wont' work everywhere, or even be possible on many systems -- you're approaching the limits of 32-bit segment size. Obviously this is going to be a problem. If you want to allocate large amounts of memory, this is what malloc is for. It can even give you an error code, letting you tell when you asked for impossible amounts instead of just crashing your program.

2) You are dynamically generating the array size. This is also a big no-no. Most compilers won't let you do that at all -- array sizes are supposed to be constant non-lvalues. That gcc lets you get away with it is mostly an accident, and not reliable.

3) I don't think you know enough about the language to be critical of it yet. You're still using floating point functions instead of the built-in bit shift operators to handle bits.