¿Por qué el uso de alloca () no se considera una buena práctica?

alloca()asigna memoria en la pila en lugar de en el montón, como en el caso de malloc(). Entonces, cuando regreso de la rutina, la memoria se libera. Entonces, en realidad esto resuelve mi problema de liberar memoria asignada dinámicamente. La liberación de la memoria asignada malloc()es un gran dolor de cabeza y, si de alguna manera se pierde, conduce a todo tipo de problemas de memoria.

¿Por qué se alloca()desaconseja el uso a pesar de las características anteriores?

La respuesta está ahí en la manpágina (al menos en Linux ):

VALOR DEVUELTO La función alloca () devuelve un puntero al comienzo del espacio asignado. Si la asignación provoca un desbordamiento de la pila, el comportamiento del programa no está definido.

Lo que no quiere decir que nunca debe usarse. Uno de los proyectos de OSS en los que trabajo lo usa ampliamente, y siempre y cuando no esté abusando de él ( allocacon grandes valores), está bien. Una vez que pasa la marca de "unos cientos de bytes", es hora de usar mallocy amigos, en su lugar. Es posible que aún obtenga fallas de asignación, pero al menos tendrá alguna indicación de la falla en lugar de simplemente volar la pila.

Uno de los errores más memorables que tuve fue hacer con una función en línea que usé alloca. Se manifestó como un desbordamiento de la pila (porque se asigna en la pila) en puntos aleatorios de la ejecución del programa.

En el archivo de encabezado:

void DoSomething() {
   wchar_t* pStr = alloca(100);
   //......
}

En el archivo de implementación:

void Process() {
   for (i = 0; i < 1000000; i++) {
     DoSomething();
   }
}

Entonces, lo que sucedió fue la DoSomethingfunción en línea del compilador y todas las asignaciones de pila ocurrían dentro de la Process()función y, por lo tanto, explotaban la pila. En mi defensa (y no fui yo quien descubrió el problema; tuve que ir a llorar a uno de los desarrolladores principales cuando no pude solucionarlo), no fue directo alloca, fue una conversión de cadenas ATL macros

Entonces, la lección es: no utilizar allocaen funciones que cree que podrían estar en línea.

Antigua pregunta, pero nadie mencionó que debería reemplazarse por matrices de longitud variable.

char arr[size];

en vez de

char *arr=alloca(size);

Está en el estándar C99 y existió como extensión del compilador en muchos compiladores.

alloca () es muy útil si no puede usar una variable local estándar porque su tamaño debería determinarse en tiempo de ejecución y puede garantizar absolutamente que el puntero que obtiene de alloca () NUNCA se usará después de que esta función regrese .

Puedes estar bastante seguro si

• no devuelva el puntero ni nada que lo contenga.
• no almacene el puntero en ninguna estructura asignada en el montón
• no permita que ningún otro hilo use el puntero

El peligro real proviene de la posibilidad de que alguien más viole estas condiciones en algún momento posterior. Con eso en mente, es ideal para pasar buffers a funciones que les dan formato de texto :)

Como se señaló en esta publicación de grupos de noticias , hay algunas razones por las cuales el uso allocapuede considerarse difícil y peligroso:

• No todos los compiladores son compatibles alloca.
• Algunos compiladores interpretan el comportamiento previsto de manera allocadiferente, por lo que la portabilidad no está garantizada incluso entre los compiladores que lo admiten.
• Algunas implementaciones tienen errores.

Un problema es que no es estándar, aunque es ampliamente compatible. En igualdad de condiciones, siempre usaría una función estándar en lugar de una extensión de compilador común.

Todavía se desaconseja el uso de alloca, ¿por qué?

No percibo tal consenso. Muchos profesionales fuertes; algunas desventajas:

• C99 proporciona matrices de longitud variable, que a menudo se utilizarían preferentemente como la notación más coherente con las matrices de longitud fija y en general intuitiva
• muchos sistemas tienen menos espacio de memoria / dirección general disponible para la pila que para el montón, lo que hace que el programa sea un poco más susceptible al agotamiento de la memoria (a través del desbordamiento de la pila): esto puede verse como algo bueno o malo. Una de las razones por las que la pila no crece automáticamente como lo hace el montón es para evitar que los programas fuera de control tengan el mismo impacto adverso en toda la máquina
• cuando se utiliza en un ámbito más local (como un bucle whileo for) o en varios ámbitos, la memoria se acumula por iteración / ámbito y no se libera hasta que la función finaliza: esto contrasta con las variables normales definidas en el ámbito de una estructura de control (p. ej. for {int i = 0; i < 2; ++i) { X }acumularía la allocamemoria -ed solicitada en X, pero la memoria para una matriz de tamaño fijo se reciclaría por iteración).
• los compiladores modernos generalmente no inlinefuncionan esa llamada alloca, pero si los fuerza alloca, sucederá en el contexto de las personas que llaman (es decir, la pila no se lanzará hasta que la persona que llama regrese)
• Hace mucho tiempo allocapasó de una función / pirateo no portátil a una extensión estandarizada, pero puede persistir cierta percepción negativa
• la duración está vinculada al alcance de la función, que puede o no adaptarse mejor al programador que mallocel control explícito
• tener que usar mallocalienta a pensar en la desasignación: si se administra a través de una función de contenedor (por ejemplo WonderfulObject_DestructorFree(ptr)), entonces la función proporciona un punto para las operaciones de limpieza de implementación (como cerrar descriptores de archivos, liberar punteros internos o hacer algunos registros) sin cambios explícitos en el cliente código: a veces es un buen modelo para adoptar consistentemente
  • en este estilo de programación pseudo-OO, es natural querer algo como WonderfulObject* p = WonderfulObject_AllocConstructor();eso, eso es posible cuando el "constructor" es una función que devuelve mallocmemoria (ya que la memoria permanece asignada después de que la función devuelve el valor que se almacenará p), pero no si el "constructor" usaalloca
    • una versión macro de WonderfulObject_AllocConstructorpodría lograr esto, pero las "macros son malvadas" en el sentido de que pueden entrar en conflicto entre sí y con código no macro y crear sustituciones no deseadas y los consecuentes problemas difíciles de diagnosticar
  • faltan freelas operaciones pueden ser detectados por valgrind, Purificar, etc, pero faltan las llamadas "Destructor" no siempre se pueden detectar en absoluto - un beneficio muy tenue en cuanto a la aplicación de uso previsto; algunas alloca()implementaciones (como las GCC) usan una macro en línea para alloca(), por lo que no es posible la sustitución en tiempo de ejecución de una biblioteca de diagnóstico de uso de memoria de la forma en que es para malloc/ realloc/ free(por ejemplo, cerca eléctrica)
• Algunas implementaciones tienen problemas sutiles: por ejemplo, desde la página de manual de Linux:

  En muchos sistemas, alloca () no se puede usar dentro de la lista de argumentos de una llamada a función, porque el espacio de pila reservado por alloca () aparecería en la pila en el medio del espacio para los argumentos de función.

Sé que esta pregunta está etiquetada con C, pero como programador de C ++ pensé que usaría C ++ para ilustrar la utilidad potencial de alloca: el siguiente código (y aquí en ideone ) crea un vector que rastrea tipos polimórficos de diferentes tamaños que se asignan en pila (con vida útil vinculada al retorno de la función) en lugar del montón asignado.

#include <alloca.h>
#include <iostream>
#include <vector>

struct Base
{
    virtual ~Base() { }
    virtual int to_int() const = 0;
};

struct Integer : Base
{
    Integer(int n) : n_(n) { }
    int to_int() const { return n_; }
    int n_;
};

struct Double : Base
{
    Double(double n) : n_(n) { }
    int to_int() const { return -n_; }
    double n_;
};

inline Base* factory(double d) __attribute__((always_inline));

inline Base* factory(double d)
{
    if ((double)(int)d != d)
        return new (alloca(sizeof(Double))) Double(d);
    else
        return new (alloca(sizeof(Integer))) Integer(d);
}

int main()
{
    std::vector<Base*> numbers;
    numbers.push_back(factory(29.3));
    numbers.push_back(factory(29));
    numbers.push_back(factory(7.1));
    numbers.push_back(factory(2));
    numbers.push_back(factory(231.0));
    for (std::vector<Base*>::const_iterator i = numbers.begin();
         i != numbers.end(); ++i)
    {
        std::cout << *i << ' ' << (*i)->to_int() << '\n';
        (*i)->~Base();   // optionally / else Undefined Behaviour iff the
                         // program depends on side effects of destructor
    }
}

Todas las otras respuestas son correctas. Sin embargo, si lo que desea asignar alloca()es razonablemente pequeño, creo que es una buena técnica que es más rápida y conveniente que usarla malloc()o no.

En otras palabras, alloca( 0x00ffffff )es peligroso y es probable que cause un desbordamiento, exactamente tanto como char hugeArray[ 0x00ffffff ];es. Sé prudente y razonable y estarás bien.

Muchas respuestas interesantes a esta "vieja" pregunta, incluso algunas respuestas relativamente nuevas, pero no encontré ninguna que mencione esto ...

Cuando se usa correctamente y con cuidado, el uso constante de alloca() (tal vez en toda la aplicación) para manejar pequeñas asignaciones de longitud variable (o VLA C99, donde esté disponible) puede conducir a un crecimiento de pila general más bajo que una implementación equivalente que usa matrices locales de gran tamaño de longitud fija . Por alloca()lo tanto, puede ser bueno para su pila si lo usa con cuidado.

Encontré esa cita en ... OK, hice esa cita. Pero realmente, piénsalo ...

@j_random_hacker tiene mucha razón en sus comentarios bajo otras respuestas: Evitar el uso alloca()a favor de matrices locales de gran tamaño no hace que su programa sea más seguro contra desbordamientos de pila (a menos que su compilador sea lo suficientemente viejo como para permitir la inclusión de funciones que se usan alloca()en ese caso, debería actualización, o a menos que use alloca()bucles internos, en cuyo caso no debería ... usar alloca()bucles internos).

He trabajado en entornos de escritorio / servidor y sistemas integrados. Muchos sistemas embebidos no usan un montón (ni siquiera se vinculan para soportarlo), por razones que incluyen la percepción de que la memoria asignada dinámicamente es mala debido a los riesgos de pérdidas de memoria en una aplicación que nunca siempre se reinicia durante años a la vez, o la justificación más razonable de que la memoria dinámica es peligrosa porque no se puede saber con certeza que una aplicación nunca fragmentará su montón hasta el punto de agotamiento de la memoria falsa. Por lo tanto, los programadores integrados tienen pocas alternativas.

alloca() (o VLA) puede ser la herramienta adecuada para el trabajo.

He visto una y otra vez que un programador crea un búfer asignado por pila "lo suficientemente grande como para manejar cualquier caso posible". En un árbol de llamadas profundamente anidado, el uso repetido de ese patrón (anti -?) Conduce a un uso exagerado de la pila. (Imagine un árbol de llamadas de 20 niveles de profundidad, donde en cada nivel por diferentes razones, la función asigna de forma ciega un búfer de 1024 bytes "solo para estar seguro" cuando generalmente solo usará 16 o menos de ellos, y solo en muy casos raros pueden usar más.) Una alternativa es usaralloca()o VLA y asigne solo la cantidad de espacio de pila que necesite su función, para evitar cargar innecesariamente la pila. Afortunadamente, cuando una función en el árbol de llamadas necesita una asignación más grande de lo normal, otras en el árbol de llamadas todavía usan sus pequeñas asignaciones normales, y el uso general de la pila de aplicaciones es significativamente menor que si cada función sobreasignara ciegamente un búfer local .

Pero si eliges usar alloca()...

Según otras respuestas en esta página, parece que los VLA deberían ser seguros (no combinan las asignaciones de pila si se invocan desde un bucle), pero si está usando alloca(), tenga cuidado de no usarlo dentro de un bucle y haga asegúrese de que su función no se pueda alinear si existe alguna posibilidad de que se invoque dentro del ciclo de otra función.

Todos ya han señalado lo importante que es el posible comportamiento indefinido de un desbordamiento de pila, pero debo mencionar que el entorno de Windows tiene un gran mecanismo para detectar esto utilizando excepciones estructuradas (SEH) y páginas de protección. Dado que la pila solo crece según sea necesario, estas páginas de protección residen en áreas que no están asignadas. Si los asigna a ellos (desbordando la pila), se genera una excepción.

Puede detectar esta excepción SEH y llamar a _resetstkoflw para restablecer la pila y continuar felizmente. No es ideal, pero es otro mecanismo para al menos saber que algo ha salido mal cuando las cosas golpean al ventilador. * nix podría tener algo similar de lo que no estoy al tanto.

Recomiendo limitar su tamaño máximo de asignación envolviendo alloca y rastreándolo internamente. Si usted fuera realmente duro al respecto, podría lanzar algunos centinelas de alcance en la parte superior de su función para rastrear cualquier asignación de asignación en el alcance de la función y verificar la sanidad contra la cantidad máxima permitida para su proyecto.

Además, además de no permitir pérdidas de memoria, alloca no causa fragmentación de memoria, lo cual es bastante importante. No creo que alloca sea una mala práctica si la usas de manera inteligente, lo cual es básicamente cierto para todo. :-)

alloca () es agradable y eficiente ... pero también está profundamente roto.

• comportamiento de alcance roto (alcance de función en lugar de alcance de bloque)
• el uso inconsistente con malloc (el puntero asignado por alloca () no debe liberarse, de ahora en adelante debe rastrear de dónde provienen los punteros para liberar () solo aquellos que obtuvo con malloc () )
• mal comportamiento cuando también usa inlining (el alcance a veces va a la función de la persona que llama dependiendo de si la persona que llama está en línea o no).
• sin verificación de límite de pila
• comportamiento indefinido en caso de falla (no devuelve NULL como malloc ... y qué significa falla ya que no verifica los límites de la pila de todos modos ...)
• no estándar ansi

En la mayoría de los casos, puede reemplazarlo utilizando variables locales y tamaños mayores. Si se usa para objetos grandes, ponerlos en el montón suele ser una idea más segura.

Si realmente lo necesita C, puede usar VLA (sin vla en C ++, muy mal). Son mucho mejores que alloca () con respecto al comportamiento del alcance y la consistencia. Como lo veo, los VLA son un tipo de alloca () hecho a la derecha.

Por supuesto, una estructura local o matriz que utiliza un espacio importante del espacio necesario es aún mejor, y si no tiene una asignación de montón tan importante utilizando malloc simple () probablemente sea sensato. No veo ningún caso de uso sensato en el que realmente necesites alloca () o VLA.

Este es el por qué:

char x;
char *y=malloc(1);
char *z=alloca(&x-y);
*z = 1;

No es que alguien escriba este código, pero el argumento de tamaño que está pasando allocacasi seguramente proviene de algún tipo de entrada, que podría apuntar maliciosamente a que su programa llegue a allocaalgo tan grande como eso. Después de todo, si el tamaño no se basa en la entrada o no tiene la posibilidad de ser grande, ¿por qué no declaraste un búfer local pequeño de tamaño fijo?

Prácticamente todo el código que usa allocay / o C99 vlas tiene errores graves que provocarán bloqueos (si tiene suerte) o un compromiso de privilegios (si no tiene tanta suerte).

No creo que nadie haya mencionado esto: el uso de alloca en una función obstaculizará o deshabilitará algunas optimizaciones que de otro modo podrían aplicarse en la función, ya que el compilador no puede conocer el tamaño del marco de la pila de la función.

Por ejemplo, una optimización común por parte de los compiladores de C es eliminar el uso del puntero de cuadro dentro de una función; en su lugar, los accesos de cuadro se hacen en relación con el puntero de pila; entonces hay un registro más para uso general. Pero si se llama a alloca dentro de la función, la diferencia entre sp y fp será desconocida para parte de la función, por lo que esta optimización no se puede hacer.

Dada la rareza de su uso, y su estado sombrío como función estándar, los diseñadores del compilador posiblemente deshabiliten cualquier optimización que pueda causar problemas con alloca, si tomaría más que un poco de esfuerzo para que funcione con alloca.

ACTUALIZACIÓN: Dado que se han agregado matrices locales de longitud variable a C, y dado que presentan problemas de generación de código muy similares para el compilador como alloca, veo que la 'rareza de uso y el estado sombreado' no se aplica al mecanismo subyacente; pero aún sospecharía que el uso de alloca o VLA tiende a comprometer la generación de código dentro de una función que los usa. Agradecería cualquier comentario de los diseñadores del compilador.

Un escollo con allocaeso es que lo longjmprebobina.

Es decir, si guarda un contexto con setjmp, a continuación, allocaalgo de memoria, a continuación, longjmpal contexto, es posible que pierda la allocamemoria. El puntero de la pila vuelve a estar donde estaba y, por lo tanto, la memoria ya no está reservada; si llama a una función o hace otra alloca, golpeará el original alloca.

Para aclarar, a lo que me refiero específicamente aquí es a una situación en la que longjmpno vuelve de la función donde allocatuvo lugar. Más bien, una función guarda contexto con setjmp; luego asigna memoria con allocay finalmente tiene lugar un longjmp en ese contexto. La allocamemoria de esa función no está completamente liberada; solo toda la memoria que asignó desde el setjmp. Por supuesto, estoy hablando de un comportamiento observado; no se documenta tal requisito de ninguno allocaque yo sepa.

El enfoque en la documentación generalmente está en el concepto de que la allocamemoria está asociada con la activación de una función , no con ningún bloque; que las invocaciones múltiples de allocasolo toman más memoria de pila que se libera cuando la función termina. No tan; la memoria está realmente asociada con el contexto del procedimiento. Cuando el contexto se restaura con longjmp, también lo es el allocaestado anterior . Es una consecuencia del registro del puntero de pila en sí mismo utilizado para la asignación, y también (necesariamente) guardado y restaurado en el jmp_buf.

Por cierto, esto, si funciona de esa manera, proporciona un mecanismo plausible para liberar deliberadamente la memoria que se le asignó alloca.

Me he encontrado con esto como la causa raíz de un error.

Un lugar donde alloca()es especialmente peligroso que malloc()el núcleo: el núcleo de un sistema operativo típico tiene un espacio de pila de tamaño fijo codificado en uno de sus encabezados; No es tan flexible como la pila de una aplicación. Hacer una llamada a alloca()un tamaño injustificado puede hacer que el núcleo se bloquee. Ciertos compiladores advierten el uso de alloca()(e incluso VLA para ese caso) bajo ciertas opciones que deberían activarse al compilar un código de kernel; aquí, es mejor asignar memoria en el montón que no está fijada por un límite codificado.

Si accidentalmente escribe más allá del bloque asignado con alloca(debido a un desbordamiento del búfer, por ejemplo), sobrescribirá la dirección de retorno de su función, porque esa se encuentra "arriba" en la pila, es decir, después de su bloque asignado.

La consecuencia de esto es doble:

1. El programa se bloqueará espectacularmente y será imposible saber por qué o dónde se bloqueó (la pila probablemente se desenrollará en una dirección aleatoria debido al puntero de marco sobrescrito).

2. Hace que el desbordamiento del búfer sea muchas veces más peligroso, ya que un usuario malintencionado puede crear una carga útil especial que se colocará en la pila y, por lo tanto, puede terminar ejecutándose.

Por el contrario, si escribe más allá de un bloque en el montón, "simplemente" se daña el montón. El programa probablemente terminará inesperadamente pero desenrollará la pila correctamente, reduciendo así la posibilidad de ejecución de código malicioso.

Lamentablemente, lo verdaderamente increíble alloca()falta en el tcc casi increíble. Gcc tiene alloca().

1. Siembra la semilla de su propia destrucción. Con retorno como el destructor.

2. Al igual malloc()que devuelve un puntero no válido en caso de error que segfault en los sistemas modernos con una MMU (y con suerte reiniciará los que no lo tengan).

3. A diferencia de las variables automáticas, puede especificar el tamaño en tiempo de ejecución.

Funciona bien con recursividad. Puede usar variables estáticas para lograr algo similar a la recursividad de cola y usar solo algunas otras para pasar información a cada iteración.

Si presiona demasiado, tiene la seguridad de una falla predeterminada (si tiene una MMU).

Tenga en cuenta que malloc()no ofrece más, ya que devuelve NULL (que también será predeterminado si se asigna) cuando el sistema no tiene memoria. Es decir, todo lo que puede hacer es rescatar o simplemente tratar de asignarlo de cualquier manera.

Para usarlo malloc()uso globales y les asigno NULL. Si el puntero no es NULL, lo libero antes de usarlo malloc().

También puede usar realloc()como caso general si desea copiar cualquier dato existente. Debe comprobar el puntero antes de determinar si va a copiar o concatenar después de realloc().

3.2.5.2 Ventajas de alloca

Los procesos solo tienen una cantidad limitada de espacio de pila disponible, mucho menos que la cantidad de memoria disponible malloc().

Al usarlo alloca(), aumenta dramáticamente sus posibilidades de obtener un error de desbordamiento de pila (si tiene suerte, o un bloqueo inexplicable si no lo tiene)

No es muy bonito, pero si el rendimiento realmente importa, puede preasignar algo de espacio en la pila.

Si ya tiene el tamaño máximo de la memoria que bloquea su necesidad y desea mantener las comprobaciones de desbordamiento, puede hacer algo como:

void f()
{
    char array_on_stack[ MAX_BYTES_TO_ALLOCATE ];
    SomeType *p = (SomeType *)array;

    (...)
}

La función alloca es excelente y todos los detractores simplemente están difundiendo FUD.

void foo()
{
    int x = 50000; 
    char array[x];
    char *parray = (char *)alloca(x);
}

Array y parray son EXACTAMENTE iguales con EXACTAMENTE los mismos riesgos. Decir que uno es mejor que otro es una opción sintáctica, no técnica.

En cuanto a la elección de las variables de pila frente a las variables de montón, hay MUCHAS ventajas para los programas de ejecución prolongada que usan pila sobre montón para variables con vidas dentro del alcance. Evita la fragmentación del montón y puede evitar aumentar su espacio de proceso con espacio de montón no utilizado (inutilizable). No necesitas limpiarlo. Puede controlar la asignación de la pila en el proceso.

¿Por qué es esto malo?

En realidad, no se garantiza que alloca use la pila. De hecho, la implementación gcc-2.95 de alloca asigna memoria del montón usando el propio malloc. Además, esa implementación tiene errores, puede provocar una pérdida de memoria y un comportamiento inesperado si lo llama dentro de un bloque con un uso adicional de goto. No, para decir que nunca deberías usarlo, pero algunas veces alloca conduce a más sobrecarga de la que libera de ti.

En mi humilde opinión, alloca se considera una mala práctica porque todo el mundo tiene miedo de agotar el límite de tamaño de la pila.

Aprendí mucho leyendo este hilo y algunos otros enlaces:

• /unix/63742/what-is-automatic-stack-expansion
• Límite de asignación de pila para programas en una máquina Linux de 32 bits
• ulimit -s

Uso alloca principalmente para hacer que mis archivos C simples sean compilables en msvc y gcc sin ningún cambio, estilo C89, sin #ifdef _MSC_VER, etc.

Gracias ! Este hilo me hizo registrarme en este sitio :)

En mi opinión, alloca (), donde esté disponible, debe usarse solo de manera restringida. Al igual que el uso de "goto", un gran número de personas razonables tienen una fuerte aversión no solo por el uso, sino también por la existencia de alloca ().

Para uso incrustado, donde se conoce el tamaño de la pila y se pueden imponer límites por convención y análisis sobre el tamaño de la asignación, y donde el compilador no se puede actualizar para admitir C99 +, el uso de alloca () está bien, y he estado conocido por usarlo.

Cuando esté disponible, los VLA pueden tener algunas ventajas sobre alloca (): el compilador puede generar comprobaciones de límite de pila que capturarán el acceso fuera de los límites cuando se usa el acceso de estilo de matriz (no sé si algún compilador hace esto, pero puede hacer), y el análisis del código puede determinar si las expresiones de acceso a la matriz están correctamente delimitadas. Tenga en cuenta que, en algunos entornos de programación, como automoción, equipos médicos y aviónica, este análisis debe realizarse incluso para matrices de tamaño fijo, tanto automáticas (en la pila) como de asignación estática (global o local).

En las arquitecturas que almacenan datos y direcciones de retorno / punteros de trama en la pila (por lo que sé, eso es todo), cualquier variable asignada a la pila puede ser peligrosa porque la dirección de la variable puede tomarse y los valores de entrada no verificados pueden permitir todo tipo de travesuras.

La portabilidad es menos preocupante en el espacio incrustado, sin embargo, es un buen argumento contra el uso de alloca () fuera de circunstancias cuidadosamente controladas.

Fuera del espacio incrustado, he usado alloca () principalmente dentro de las funciones de registro y formateo para mayor eficiencia, y en un escáner léxico no recursivo, donde las estructuras temporales (asignadas usando alloca () se crean durante la tokenización y clasificación, luego persiste object (asignado a través de malloc ()) se rellena antes de que regrese la función. El uso de alloca () para las estructuras temporales más pequeñas reduce en gran medida la fragmentación cuando se asigna el objeto persistente.

La mayoría de las respuestas aquí en gran medida pierden el punto: hay una razón por la cual usar _alloca() es potencialmente peor que simplemente almacenar objetos grandes en la pila.

La principal diferencia entre el almacenamiento automático y _alloca() el último es que tiene un problema adicional (grave): el compilador no controla el bloque asignado, por lo que el compilador no puede optimizarlo ni reciclarlo.

Comparar:

while (condition) {
    char buffer[0x100]; // Chill.
    /* ... */
}

con:

while (condition) {
    char* buffer = _alloca(0x100); // Bad!
    /* ... */
}

El problema con este último debería ser obvio.

No creo que nadie haya mencionado esto, pero alloca también tiene algunos problemas de seguridad graves que no necesariamente están presentes con malloc (aunque estos problemas también surgen con cualquier matriz basada en pila, dinámica o no). Dado que la memoria está asignada en la pila, los desbordamientos / desbordamientos del búfer tienen consecuencias mucho más graves que con solo malloc.

En particular, la dirección de retorno de una función se almacena en la pila. Si este valor se corrompe, se puede hacer que su código vaya a cualquier región ejecutable de la memoria. Los compiladores hacen todo lo posible para dificultar esto (en particular al aleatorizar el diseño de la dirección). Sin embargo, esto es claramente peor que un desbordamiento de pila, ya que el mejor de los casos es un SEGFAULT si el valor de retorno está dañado, pero también podría comenzar a ejecutar una memoria aleatoria o, en el peor de los casos, alguna región de memoria que comprometa la seguridad de su programa. .