Stack based allocation not recommended?

Question

The libmemcached documentation has this note:

You may wish to avoid using memcached_create(3) or memcached_clone(3) with a stack based allocation. The most common issues related to ABI safety involve heap allocated structures.

How do I have to understand it? Stands in this case ABI for Application Binary Interface? I would like to provide the pointer to the struct for memcached_clone() from a variable in the local function scope. Is it safe?

Example - is this code OK?

foo()
{
   memcached_st clone_memc;

   memcached_clone(&clone_memc, master_memc);

   // some memcache function calls (get/set)
   ...

   memcached_free(&clone_memc);
}

score 0 · Accepted Answer · answered Mar 30 '15 at 12:38

Yes, ABI stands for application binary interface.
I can think of three reasons to avoid stack allocations. In ascending order of relevance:

Stack smashing on overflow may be more straightforward to exploit than heap overflow.
Lifetime of allocation ends when the scope of the creating function is left, not keeping this in mind this is a fairly common error for C beginners.
Stack size limits are generally rather small (~8kb), allocating significant amounts of storage on the stack may overflow it.

That far it does not affect me.This question was asked because I am using memcached in MySQL UDF and once getting used to C++ it is a pain to write in pure C — Peter VARGA, Apr 01 '15 at 16:08

Stack based allocation not recommended?

1 Answers1