Is it too much to allocate 16kb on the stack?

I need to instantiate a char[16384] buffer before calling a c function. After the fu开发者_JAVA技巧nction returns I will read some parts of it and discard it.

Is it ok to allocate it on the stack or should I use the heap?

EDIT: I'll add some information. The code will run on several platforms, from PC to iPhone, where I guess the stack space will not be so big, but I have no idea about that.

It's hard to give a definitive yes or no to this question because the answer is highly dependent on your environment and at what point in the program the function which allocates the memory is invoked.

Personally though if I saw this in a code review I'd raise a red flag. That's a lot of memory to be using for a stack based buffer. It may work today in the very specific place you're using it but what about tomorrow when you're called with a much bigger stack below you? Or when the customer hits a scenario you didn't consider?

But like I said it's scenario dependent and it may be just fine for your specific scenario. There's simply not enough detail in your question to say yes or no

Unless you're programming for embedded systems, code which might be running from a thread other than the main thread, or code which is called recursively, I would say 16k is well within the reasonable size you can allocate on the stack.

As for threads, if you're using POSIX threads and want your program to be portable, you can use the pthread_attr_setstacksize interface to specify the amount of stack space your thread needs, and then as long as you know the calling patterns and over-estimate by a good margin in choosing the size, you can be sure it will be safe.

Depends entirely on your OS and process definitions. Better allocate it from the heap by malloc and check the result (which may fail). Allocating failure on stack may cause stack corruption, which you won't be able to catch at run time.

If you're using C++ (since the question has that tag) use a vector<char> buffer(16384) - that way you get automatic deallocation, but the large buffer gets allocated on the heap.

The only potential drawback is that the buffer will be default initialized. There's a small chance that that might be something you can't afford (though it'll probably be of no consequence).

I'd say it depends upon the intended lifetime of the buffer.

If the intention is for the buffer to exist only in the scope of the creating function and the functions it calls, then stack-based is an excellent mechanism to avoid memory leaks.

If the intention is for the buffer to be long-lived, outliving the scope of the creating function, then I would malloc(3) the buffer.

My pthread_attr_setstacksize(3) says to look in pthread_create(3) for details on default stack size; sadly, all I have on my system is the POSIX-provided pthread_create(3posix) manpage, which lacks these details; but my recollection is that default stack size is so large that most people who want to know how to set their stack size want to shrink it, so they can run more threads in a given amount of memory. :)

if your code is not used by multiple threads AND it is not re-entrant... then I would just do one malloc at program initialization for that buffer. You will have less of a worry about architecture issues surrounding stack size. You definitely don't want to do a malloc/free per call.