Pourquoi l'utilisation d'alloca () n'est-elle pas considérée comme une bonne pratique?

alloca()alloue de la mémoire sur la pile plutôt que sur le tas, comme dans le cas de malloc(). Donc, quand je reviens de la routine, la mémoire est libérée. Donc, en fait, cela résout mon problème de libération de mémoire allouée dynamiquement. La libération de la mémoire allouée malloc()est un casse-tête majeur et si elle est manquée, elle entraîne toutes sortes de problèmes de mémoire.

Pourquoi est-il alloca()déconseillé malgré les fonctionnalités ci-dessus?

La réponse est juste là dans la manpage (au moins sous Linux ):

VALEUR RENVOYÉE La fonction alloca () renvoie un pointeur sur le début de l'espace alloué. Si l'allocation entraîne un débordement de pile, le comportement du programme n'est pas défini.

Ce qui ne veut pas dire qu'il ne devrait jamais être utilisé. L'un des projets OSS sur lequel je travaille l'utilise largement, et tant que vous n'en abusez pas (avec allocades valeurs énormes), ça va. Une fois que vous avez dépassé la marque "quelques centaines d'octets", il est temps d'utiliser à la place des mallocamis. Vous pouvez toujours obtenir des échecs d'allocation, mais au moins vous aurez une indication de l'échec au lieu de simplement faire exploser la pile.

L'un des bugs les plus mémorables que j'ai eu a été de faire avec une fonction en ligne utilisée alloca. Il s'est manifesté comme un débordement de pile (car il alloue sur la pile) à des points aléatoires de l'exécution du programme.

Dans le fichier d'en-tête:

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

Dans le fichier d'implémentation:

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

Donc, ce qui s'est passé était la DoSomethingfonction en ligne du compilateur et toutes les allocations de pile se passaient à l'intérieur de la Process()fonction et faisaient ainsi exploser la pile. Pour ma défense (et ce n'est pas moi qui ai trouvé le problème; j'ai dû aller crier à l'un des développeurs seniors quand je n'ai pas pu le réparer), ce n'était pas simple alloca, c'était une conversion de chaîne ATL macros.

La leçon est donc - ne pas utiliser allocadans des fonctions qui, selon vous, pourraient être intégrées.

Vieille question mais personne n'a mentionné qu'elle devrait être remplacée par des tableaux de longueur variable.

char arr[size];

au lieu de

char *arr=alloca(size);

C'est dans la norme C99 et existait comme extension de compilateur dans de nombreux compilateurs.

alloca () est très utile si vous ne pouvez pas utiliser une variable locale standard car sa taille doit être déterminée lors de l'exécution et vous pouvez absolument garantir que le pointeur que vous obtenez de alloca () ne sera JAMAIS utilisé après le retour de cette fonction .

Vous pouvez être assez en sécurité si vous

• ne renvoyez pas le pointeur ou tout ce qui le contient.
• ne stocke pas le pointeur dans une structure allouée sur le tas
• ne laissez aucun autre thread utiliser le pointeur

Le vrai danger vient de la possibilité que quelqu'un d'autre viole ces conditions un peu plus tard. Dans cet esprit, il est idéal pour passer des tampons aux fonctions qui mettent en forme du texte dedans :)

Comme indiqué dans cette publication de groupe de discussion , il existe plusieurs raisons pour lesquelles l'utilisation allocapeut être considérée comme difficile et dangereuse:

• Tous les compilateurs ne prennent pas en charge alloca.
• Certains compilateurs interprètent allocadifféremment le comportement souhaité , de sorte que la portabilité n'est pas garantie même entre les compilateurs qui le prennent en charge.
• Certaines implémentations sont boguées.

Un problème est qu'il n'est pas standard, bien qu'il soit largement pris en charge. Toutes choses étant égales par ailleurs, j'utiliserais toujours une fonction standard plutôt qu'une extension de compilateur commune.

l'utilisation d'allocations est déconseillée, pourquoi?

Je ne perçois pas un tel consensus. Beaucoup de pros solides; quelques inconvénients:

• C99 fournit des tableaux de longueur variable, qui seraient souvent utilisés de préférence car la notation est plus cohérente avec les tableaux de longueur fixe et intuitive dans l'ensemble
• de nombreux systèmes ont moins de mémoire / espace d'adressage global disponible pour la pile que pour le tas, ce qui rend le programme légèrement plus sensible à l'épuisement de la mémoire (par le débordement de la pile): cela peut être considéré comme une bonne ou une mauvaise chose - une L'une des raisons pour lesquelles la pile n'augmente pas automatiquement comme le tas est d'empêcher les programmes incontrôlés d'avoir autant d'impact négatif sur l'ensemble de la machine
• lorsqu'elle est utilisée dans une étendue plus locale (comme une boucle whileou for) ou dans plusieurs étendues, la mémoire s'accumule par itération / étendue et n'est libérée que lorsque la fonction se termine: cela contraste avec les variables normales définies dans l'étendue d'une structure de contrôle (par ex. for {int i = 0; i < 2; ++i) { X }accumulerait la allocamémoire demandée en X, mais la mémoire d'un tableau de taille fixe serait recyclée par itération).
• les compilateurs modernes ne font généralement pas inlinefonctionner cet appel alloca, mais si vous les forcez, cela allocase produira dans le contexte des appelants (c'est-à-dire que la pile ne sera pas libérée avant le retour de l'appelant)
• il y a longtemps est passé allocad'une fonctionnalité / piratage non portable à une extension standardisée, mais une perception négative peut persister
• la durée de vie est liée à la portée de la fonction, qui peut ou non convenir au programmeur mieux que mallocle contrôle explicite de
• avoir à utiliser mallocencourage à penser à la désallocation - si elle est gérée via une fonction wrapper (par exemple WonderfulObject_DestructorFree(ptr)), la fonction fournit un point pour les opérations de nettoyage de l'implémentation (comme la fermeture des descripteurs de fichiers, la libération de pointeurs internes ou la journalisation) sans modifications explicites du client code: parfois c'est un joli modèle à adopter systématiquement
  • dans ce style de programmation pseudo-OO, il est naturel de vouloir quelque chose comme WonderfulObject* p = WonderfulObject_AllocConstructor();- c'est possible lorsque le "constructeur" est une fonction renvoyant de la mallocmémoire (car la mémoire reste allouée après que la fonction retourne la valeur à stocker p), mais pas si le "constructeur" utilisealloca
    • une version macro de WonderfulObject_AllocConstructorpourrait y parvenir, mais «les macros sont mauvaises» en ce sens qu'elles peuvent entrer en conflit les unes avec les autres et avec du code non macro et créer des substitutions involontaires et des problèmes difficiles à diagnostiquer en conséquence
  • les freeopérations manquantes peuvent être détectées par ValGrind, Purify, etc., mais les appels «destructeurs» manquants ne peuvent pas toujours être détectés du tout - un avantage très ténu en termes d'application de l'utilisation prévue; certaines alloca()implémentations (telles que GCC) utilisent une macro intégrée pour alloca(), donc la substitution au moment de l'exécution d'une bibliothèque de diagnostic d'utilisation de la mémoire n'est pas possible de la même manière que pour malloc/ realloc/ free(par exemple une clôture électrique)
• certaines implémentations ont des problèmes subtils: par exemple, à partir de la page de manuel Linux:

  Sur de nombreux systèmes, alloca () ne peut pas être utilisé dans la liste des arguments d'un appel de fonction, car l'espace de pile réservé par alloca () apparaîtrait sur la pile au milieu de l'espace pour les arguments de fonction.

Je sais que cette question est étiquetée C, mais en tant que programmeur C ++, j'ai pensé utiliser C ++ pour illustrer l'utilité potentielle de alloca: le code ci-dessous (et ici à ideone ) crée un vecteur de suivi de types polymorphes de tailles différentes qui sont alloués par pile (avec durée de vie liée au retour de la fonction) plutôt que le tas alloué.

#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
    }
}

Toutes les autres réponses sont correctes. Cependant, si la chose que vous souhaitez allouer en utilisant alloca()est raisonnablement petite, je pense que c'est une bonne technique qui est plus rapide et plus pratique que l'utilisation malloc()ou autre.

En d'autres termes, alloca( 0x00ffffff )est dangereux et susceptible de provoquer un débordement, exactement autant quechar hugeArray[ 0x00ffffff ]; est. Soyez prudent et raisonnable et tout ira bien.

Beaucoup de réponses intéressantes à cette "vieille" question, même des réponses relativement nouvelles, mais je n'en ai trouvé aucune qui mentionne cela ....

Lorsqu'elle est utilisée correctement et avec soin, l'utilisation cohérente de alloca() (peut-être à l'échelle de l'application) pour gérer de petites allocations de longueur variable (ou VLA C99, le cas échéant) peut entraîner une croissance globale de la pile inférieure à une implémentation autrement équivalente utilisant des tableaux locaux surdimensionnés de longueur fixe . Cela alloca()peut donc être bon pour votre pile si vous l'utilisez avec précaution.

J'ai trouvé cette citation dans ... OK, j'ai fait cette citation. Mais vraiment, pensez-y ...

@j_random_hacker a tout à fait raison dans ses commentaires sous d'autres réponses: éviter d'utiliser alloca()en faveur de tableaux locaux surdimensionnés ne rend pas votre programme plus sûr contre les débordements de pile (à moins que votre compilateur soit assez vieux pour permettre l'inclusion de fonctions qui utilisent, alloca()auquel cas vous devriez mise à niveau, ou à moins que vous n'utilisiez des alloca()boucles internes, auquel cas vous ne devriez pas ... utiliser des alloca()boucles internes).

J'ai travaillé sur des environnements de bureau / serveur et des systèmes embarqués. Beaucoup de systèmes embarqués n'utilisent pas du tout de tas (ils ne lient même pas en support), pour des raisons qui incluent la perception que la mémoire allouée dynamiquement est mauvaise en raison des risques de fuites de mémoire sur une application qui ne redémarre jamais pendant des années à la fois, ou la justification plus raisonnable que la mémoire dynamique est dangereuse car on ne peut pas savoir avec certitude qu'une application ne fragmentera jamais son tas au point d'épuisement de la fausse mémoire. Les programmeurs intégrés se retrouvent donc avec peu d'alternatives.

alloca() (ou VLA) peut être le bon outil pour le travail.

J'ai vu maintes et maintes fois où un programmeur fait un tampon alloué à la pile "assez grand pour gérer n'importe quel cas possible". Dans un arbre d'appels profondément imbriqué, l'utilisation répétée de ce modèle (anti-?) Conduit à une utilisation exagérée de la pile. (Imaginez un arbre d'appels de 20 niveaux de profondeur, où à chaque niveau pour différentes raisons, la fonction suralloue aveuglément un tampon de 1024 octets "juste pour être sûr" alors qu'en général, elle n'en utilisera que 16 ou moins, et seulement les cas rares peuvent en utiliser davantage.) Une alternative consiste à utiliseralloca()ou VLA et allouez uniquement autant d'espace de pile que votre fonction a besoin, pour éviter de surcharger inutilement la pile. Espérons que lorsqu'une fonction dans l'arborescence des appels nécessite une allocation plus grande que la normale, d'autres dans l'arborescence des appels utilisent toujours leurs petites allocations normales, et l'utilisation globale de la pile d'applications est nettement inférieure à celle si chaque fonction surallouait aveuglément un tampon local. .

Mais si vous choisissez d'utiliser alloca()...

Sur la base d'autres réponses sur cette page, il semble que les VLA devraient être sûrs (ils ne composent pas les allocations de pile s'ils sont appelés à partir d'une boucle), mais si vous utilisez alloca(), veillez à ne pas l'utiliser à l'intérieur d'une boucle et faites assurez- vous que votre fonction ne peut pas être alignée s'il y a une chance qu'elle puisse être appelée dans la boucle d'une autre fonction.

Tout le monde a déjà souligné la grande chose qui est le comportement non défini potentiel d'un débordement de pile, mais je dois mentionner que l'environnement Windows a un excellent mécanisme pour le détecter en utilisant des exceptions structurées (SEH) et des pages de garde. Étant donné que la pile ne s'agrandit que si nécessaire, ces pages de garde résident dans des zones non allouées. Si vous les allouez (en débordant la pile), une exception est levée.

Vous pouvez intercepter cette exception SEH et appeler _resetstkoflw pour réinitialiser la pile et continuer votre joyeux chemin. Ce n'est pas idéal, mais c'est un autre mécanisme pour au moins savoir que quelque chose a mal tourné lorsque le truc frappe le ventilateur. * nix pourrait avoir quelque chose de similaire que je ne connais pas.

Je recommande de limiter la taille maximale de votre allocation en enveloppant alloca et en la suivant en interne. Si vous étiez vraiment inconditionnel à ce sujet, vous pouvez lancer des sentinelles de portée en haut de votre fonction pour suivre les allocations d'allocations dans la portée de la fonction et vérifier la validité par rapport au montant maximum autorisé pour votre projet.

De plus, en plus de ne pas autoriser les fuites de mémoire, alloca ne provoque pas de fragmentation de la mémoire, ce qui est assez important. Je ne pense pas que l'alloca soit une mauvaise pratique si vous l'utilisez intelligemment, ce qui est fondamentalement vrai pour tout. :-)

alloca () est agréable et efficace ... mais il est également profondément cassé.

• comportement de portée cassé (portée de fonction au lieu de portée de bloc)
• utilisation incompatible avec malloc (le pointeur alloué () ne doit pas être libéré, vous devez désormais suivre d'où viennent les pointeurs vers free () uniquement ceux que vous avez obtenus avec malloc () )
• mauvais comportement lorsque vous utilisez également l'inlining (la portée va parfois à la fonction d'appelant selon que l'appelé est en ligne ou non).
• pas de vérification des limites de la pile
• comportement indéfini en cas d'échec (ne renvoie pas NULL comme malloc ... et que signifie l'échec car il ne vérifie pas les limites de la pile de toute façon ...)
• pas la norme ansi

Dans la plupart des cas, vous pouvez le remplacer en utilisant des variables locales et une taille majorante. S'il est utilisé pour de gros objets, les mettre sur le tas est généralement une idée plus sûre.

Si vous en avez vraiment besoin C vous pouvez utiliser VLA (pas de vla en C ++, dommage). Ils sont bien meilleurs que alloca () en ce qui concerne le comportement et la cohérence des portées. Comme je le vois, les VLA sont une sorte d' alloca () bien fait.

Bien sûr, une structure ou un tableau local utilisant un majorant de l'espace nécessaire est encore mieux, et si vous n'avez pas une telle allocation de tas majorant en utilisant plain malloc () est probablement sain. Je ne vois aucun cas d'utilisation sensé où vous avez vraiment vraiment besoin d' alloca () ou de VLA.

Voici pourquoi:

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

Ce n'est pas que quelqu'un écrive ce code, mais l'argument de taille allocaauquel vous passez provient presque certainement d'une sorte d'entrée, qui pourrait viser malicieusement à obtenir votre programmealloca quelque chose d'énorme comme ça. Après tout, si la taille n'est pas basée sur l'entrée ou n'a pas la possibilité d'être grande, pourquoi n'avez-vous pas simplement déclaré un petit tampon local de taille fixe?

Pratiquement tout le code utilisant allocaet / ou vlas C99 comporte de graves bogues qui entraîneront des plantages (si vous avez de la chance) ou des compromis de privilèges (si vous n'êtes pas aussi chanceux).

Je ne pense pas que quiconque ait mentionné cela: l'utilisation d'alloca dans une fonction gênera ou désactivera certaines optimisations qui pourraient autrement être appliquées dans la fonction, car le compilateur ne peut pas connaître la taille du cadre de pile de la fonction.

Par exemple, une optimisation courante par les compilateurs C consiste à éliminer l'utilisation du pointeur de trame dans une fonction, les accès aux trames sont effectués par rapport au pointeur de pile à la place; il y a donc un autre registre à usage général. Mais si alloca est appelé dans la fonction, la différence entre sp et fp sera inconnue pour une partie de la fonction, donc cette optimisation ne peut pas être effectuée.

Compte tenu de la rareté de son utilisation et de son statut louche en tant que fonction standard, les concepteurs de compilateurs désactivent très probablement toute optimisation qui pourrait causer des problèmes avec alloca, si cela prendrait plus qu'un petit effort pour le faire fonctionner avec alloca.

MISE À JOUR: Étant donné que des tableaux locaux de longueur variable ont été ajoutés à C et que ceux-ci présentent des problèmes de génération de code très similaires au compilateur en tant qu'alloca, je vois que la `` rareté d'utilisation et le statut ombragé '' ne s'appliquent pas au mécanisme sous-jacent; mais je soupçonnerais toujours que l'utilisation de alloca ou VLA tend à compromettre la génération de code au sein d'une fonction qui les utilise. Je serais heureux de recevoir les commentaires des concepteurs de compilateurs.

Un écueil allocaest quelongjmp cela rembobine.

Autrement dit, si vous enregistrez un contexte avec setjmp, puis de la allocamémoire, puis longjmpdans le contexte, vous risquez de perdre la allocamémoire. Le pointeur de pile est de retour où il était et donc la mémoire n'est plus réservée; si vous appelez une fonction ou en faites une autre alloca, vous encombrerez l'original alloca.

Pour clarifier, ce à quoi je fais spécifiquement référence ici est une situation dans laquelle longjmpil ne revient pas de la fonction où il a allocaeu lieu! Au contraire, une fonction enregistre le contexte avec setjmp; alloue ensuite de la mémoire avec allocaet enfin un longjmp a lieu dans ce contexte. La allocamémoire de cette fonction n'est pas entièrement libérée; juste toute la mémoire qu'il a allouée depuis le setjmp. Bien sûr, je parle d'un comportement observé; aucune exigence de ce genre n'est documentée à allocama connaissance.

Dans la documentation, l'accent est généralement mis sur le concept selon lequel la allocamémoire est associée à une activation de fonction , et non à un bloc; que plusieurs invocations de allocasimplement saisir plus de mémoire de pile qui est tout libéré lorsque la fonction se termine. Pas si; la mémoire est en fait associée au contexte de la procédure. Lorsque le contexte est restauré avec longjmp, il en est de même de l' allocaétat antérieur . C'est une conséquence du registre du pointeur de pile lui-même utilisé pour l'allocation, et également (nécessairement) enregistré et restauré dans le jmp_buf.

Soit dit en passant, cela, s'il fonctionne de cette façon, fournit un mécanisme plausible pour libérer délibérément la mémoire allouée avec alloca.

J'ai rencontré cela comme la cause première d'un bug.

Un endroit où alloca()est particulièrement dangereux que malloc()le noyau - le noyau d'un système d'exploitation typique a un espace de pile de taille fixe codé en dur dans l'un de ses en-têtes; il n'est pas aussi flexible que la pile d'une application. Faire un appel à alloca()avec une taille non garantie peut entraîner le plantage du noyau. Certains compilateurs avertissent l'utilisation de alloca()(et même des VLA d'ailleurs) sous certaines options qui doivent être activées lors de la compilation d'un code de noyau - ici, il est préférable d'allouer de la mémoire dans le tas qui n'est pas fixée par une limite codée en dur.

Si vous écrivez accidentellement au-delà du bloc alloué avec alloca(en raison d'un débordement de tampon par exemple), alors vous écraserez l' adresse de retour de votre fonction, car celle-ci est située "au-dessus" de la pile, c'est- à- dire après votre bloc alloué.

La conséquence en est double:

1. Le programme se bloquera de façon spectaculaire et il sera impossible de dire pourquoi ou où il s'est bloqué (la pile se déroulera très probablement vers une adresse aléatoire en raison du pointeur de trame écrasé).

2. Cela rend le débordement de tampon beaucoup plus dangereux, car un utilisateur malveillant peut créer une charge utile spéciale qui serait placée sur la pile et peut donc être exécutée.

En revanche, si vous écrivez au-delà d'un bloc sur le tas, vous obtenez «juste» une corruption de tas. Le programme se terminera probablement de façon inattendue mais déroulera la pile correctement, réduisant ainsi les risques d'exécution de code malveillant.

Malheureusement, le vraiment génial alloca()manque dans le tcc presque génial. Gcc a alloca().

1. Il sème la graine de sa propre destruction. Avec retour comme destructeur.

2. Comme malloc()s'il retourne un pointeur invalide en cas d'échec qui se produira par défaut sur les systèmes modernes avec une MMU (et, espérons-le, redémarrera ceux qui n'en ont pas).

3. Contrairement aux variables automatiques, vous pouvez spécifier la taille au moment de l'exécution.

Cela fonctionne bien avec la récursivité. Vous pouvez utiliser des variables statiques pour obtenir quelque chose de similaire à la récursivité de queue et utiliser seulement quelques autres informations de passage à chaque itération.

Si vous poussez trop profondément, vous êtes assuré d'un défaut de segmentation (si vous avez une MMU).

Notez qu'il malloc()n'en offre pas plus car il retourne NULL (qui sera également un défaut de segmentation s'il est attribué) lorsque le système est à court de mémoire. C'est-à-dire que tout ce que vous pouvez faire est de cautionner ou simplement essayer de l'attribuer de quelque façon que ce soit.

Pour utiliser, malloc()j'utilise des globaux et je les attribue NULL. Si le pointeur n'est pas NULL, je le libère avant de l'utiliser malloc().

Vous pouvez également utiliser realloc()comme cas général si vous souhaitez copier des données existantes. Vous devez vérifier le pointeur avant de déterminer si vous allez copier ou concaténer après le realloc().

3.2.5.2 Avantages de alloca

Les processus ne disposent que d'une quantité limitée d'espace de pile disponible, bien inférieure à la quantité de mémoire disponible malloc().

En utilisant, alloca()vous augmentez considérablement vos chances d'obtenir une erreur de débordement de pile (si vous avez de la chance, ou un plantage inexplicable si vous ne l'êtes pas).

Pas très joli, mais si les performances comptent vraiment, vous pouvez préallouer de l'espace sur la pile.

Si vous avez déjà la taille maximale du bloc de mémoire dont vous avez besoin et que vous souhaitez conserver les vérifications de débordement, vous pouvez faire quelque chose comme:

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

    (...)
}

La fonction alloca est géniale et tous les opposants répandent simplement du FUD.

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

Array et parray sont EXACTEMENT les mêmes avec EXACTEMENT les mêmes risques. Dire que l'un est meilleur qu'un autre est un choix syntaxique et non technique.

En ce qui concerne le choix des variables de pile par rapport aux variables de tas, il y a BEAUCOUP d'avantages aux programmes de longue durée utilisant la pile sur le tas pour les variables avec des durées de vie in-scope. Vous évitez la fragmentation du tas et vous pouvez éviter d'agrandir votre espace de processus avec de l'espace de tas inutilisé (inutilisable). Vous n'avez pas besoin de le nettoyer. Vous pouvez contrôler l'allocation de pile sur le processus.

Pourquoi est-ce mauvais?

En fait, alloca n'est pas garanti d'utiliser la pile. En effet, l'implémentation gcc-2.95 d'alloca alloue de la mémoire à partir du tas en utilisant malloc lui-même. De plus, cette implémentation est boguée, elle peut entraîner une fuite de mémoire et un comportement inattendu si vous l'appelez à l'intérieur d'un bloc avec une nouvelle utilisation de goto. Non, pour dire que vous ne devriez jamais l'utiliser, mais parfois, alloca entraîne plus de frais généraux qu'il n'en libère.

À mon humble avis, alloca est considéré comme une mauvaise pratique car tout le monde a peur d'épuiser la limite de taille de pile.

J'ai beaucoup appris en lisant ce fil et quelques autres liens:

• /unix/63742/what-is-automatic-stack-expansion
• Limite d'allocation de pile pour les programmes sur une machine Linux 32 bits
• ulimit -s

J'utilise alloca principalement pour rendre mes fichiers C simples compilables sur msvc et gcc sans aucune modification, style C89, pas de #ifdef _MSC_VER, etc.

Merci ! Ce fil m'a fait m'inscrire à ce site :)

À mon avis, alloca (), lorsqu'elle est disponible, ne doit être utilisée que de manière contrainte. Tout comme l'utilisation de "goto", un assez grand nombre de personnes par ailleurs raisonnables ont une forte aversion non seulement pour l'utilisation de alloca (), mais aussi pour son existence.

Pour une utilisation intégrée, où la taille de la pile est connue et où des limites peuvent être imposées via la convention et l'analyse de la taille de l'allocation, et où le compilateur ne peut pas être mis à niveau pour prendre en charge C99 +, l'utilisation de alloca () est très bien, et j'ai été connu pour l'utiliser.

Lorsqu'ils sont disponibles, les VLA peuvent avoir certains avantages par rapport à alloca (): le compilateur peut générer des vérifications de limites de pile qui intercepteront l'accès hors limites lorsque l'accès au style de tableau est utilisé (je ne sais pas si des compilateurs le font, mais il peut et l'analyse du code peut déterminer si les expressions d'accès au tableau sont correctement délimitées. Notez que, dans certains environnements de programmation, tels que l'automobile, les équipements médicaux et l'avionique, cette analyse doit être effectuée même pour les baies de taille fixe, à la fois automatique (sur la pile) et statique (globale ou locale).

Sur les architectures qui stockent à la fois des données et des adresses de retour / pointeurs de trame sur la pile (d'après ce que je sais, c'est tout), toute variable allouée à la pile peut être dangereuse car l'adresse de la variable peut être prise et des valeurs d'entrée non contrôlées peuvent permettre toutes sortes de méfaits.

La portabilité est moins préoccupante dans l'espace intégré, mais c'est un bon argument contre l'utilisation de alloca () en dehors de circonstances soigneusement contrôlées.

En dehors de l'espace intégré, j'ai utilisé alloca () principalement à l'intérieur des fonctions de journalisation et de formatage pour plus d'efficacité, et dans un scanner lexical non récursif, où des structures temporaires (allouées en utilisant alloca () sont créées lors de la tokenisation et de la classification, puis une persistance l'objet (alloué via malloc ()) est rempli avant le retour de la fonction. L'utilisation d'alloca () pour les petites structures temporaires réduit considérablement la fragmentation lorsque l'objet persistant est alloué.

La plupart des réponses manquent ici: il y a une raison pour laquelle utiliser _alloca() est potentiellement pire que de simplement stocker de gros objets dans la pile.

La principale différence entre le stockage automatique et le _alloca()fait que ce dernier souffre d'un problème supplémentaire (grave): le bloc alloué n'est pas contrôlé par le compilateur , il n'y a donc aucun moyen pour le compilateur de l'optimiser ou de le recycler.

Comparer:

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

avec:

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

Le problème avec ce dernier devrait être évident.

Je ne pense pas que quiconque ait mentionné cela, mais alloca a également de sérieux problèmes de sécurité qui ne sont pas nécessairement présents avec malloc (bien que ces problèmes surviennent également avec les tableaux basés sur la pile, dynamiques ou non). Étant donné que la mémoire est allouée sur la pile, les débordements / débordements de tampon ont des conséquences beaucoup plus graves qu'avec un simple malloc.

En particulier, l'adresse de retour d'une fonction est stockée sur la pile. Si cette valeur est corrompue, votre code pourrait être envoyé à n'importe quelle région exécutable de la mémoire. Les compilateurs se donnent beaucoup de mal pour rendre cela difficile (en particulier en randomisant la disposition des adresses). Cependant, c'est clairement pire qu'un simple débordement de pile car le meilleur des cas est un SEGFAULT si la valeur de retour est corrompue, mais il pourrait également commencer à exécuter un morceau de mémoire aléatoire ou dans le pire des cas une région de mémoire qui compromet la sécurité de votre programme .