Чому використання аллока () не вважається хорошою практикою?

alloca()виділяє пам'ять на стек, а не на купу, як у випадку malloc(). Отже, коли я повертаюся з розпорядку, пам'ять звільняється. Отже, насправді це вирішує мою проблему звільнення динамічно розподіленої пам'яті. Звільнення пам'яті, що виділяється, malloc()є головним болем, і якщо якимось чином пропущене, призводить до всіляких проблем з пам'яттю.

Чому використання alloca()знешкоджених незважаючи на вищезазначені особливості?

Відповідь знаходиться прямо на manсторінці (принаймні в Linux ):

ПОВЕРНЕННЯ ЗНАЧЕННЯ Функція alloca () повертає покажчик на початок виділеного простору. Якщо виділення викликає переповнення стека, поведінка програми не визначена.

Що не означає, що його ніколи не слід використовувати. Один із проектів OSS, над яким я працюю, широко використовує його, і поки ви не зловживаєте ним ( alloca'величезні значення'), це добре. Після того, як ви пройдете повз позначку "кілька сотень байтів", настав час mallocнатомість використовувати та друзів. Ви все ще можете отримати збої в розподілі, але принаймні ви будете мати певні вказівки на помилку, а не просто видувати стек.

Один з найбільш запам'ятовуваних помилок, який я мав, - це вбудована функція, яка використовувалась alloca. Він проявився як переповнення стека (оскільки він виділяє на стек) у випадкових точках виконання програми.

У файлі заголовка:

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

У файлі реалізації:

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

Тож сталося, що вбудована DoSomethingфункція компілятора, і всі розподіли стека відбуваються всередині Process()функції, і таким чином підірвати стек. На мій захист (і я не був тим, хто знайшов проблему; мені довелося піти і поплакатися до одного зі старших розробників, коли я не зміг його виправити), це було не прямо alloca, це було одним із перетворень рядків ATL макроси

Отже, урок - не використовуйте allocaфункції, які, на вашу думку, можуть бути окреслені.

Старе питання, але ніхто не згадував, що його слід замінити масивами змінної довжини.

char arr[size];

замість

char *arr=alloca(size);

Він знаходиться в стандартному С99 і існував як розширення компілятора у багатьох компіляторах.

alloca () дуже корисний, якщо ви не можете використовувати стандартну локальну змінну, оскільки її розмір потрібно визначити під час виконання, і ви можете абсолютно гарантувати, що покажчик, який ви отримаєте від alloca (), НІКОЛИ не буде використаний після повернення цієї функції .

Ти можеш бути досить безпечним, якщо ти

• не повертайте вказівник або щось, що його містить.
• не зберігайте вказівник у будь-якій структурі, виділеній на купі
• не дозволяйте іншим потокам використовувати вказівник

Справжня небезпека випливає з того, що десь пізніше хтось порушить ці умови. Зважаючи на це, це чудово для передачі буферів до функцій, які форматують текст у них :)

Як зазначається в публікації цієї групи новин , є кілька причин, через які використання allocaможна вважати складним та небезпечним:

• Не всі компілятори підтримують alloca.
• Деякі компілятори по- allocaрізному інтерпретують передбачувану поведінку , тому портативність не гарантується навіть між компіляторами, які її підтримують.
• Деякі реалізації є помилковими.

Одне питання полягає в тому, що він не є стандартним, хоча широко підтримується. За інших рівних умов я завжди використовував би стандартну функцію, а не загальне розширення компілятора.

все-таки використання алоки не рекомендується, чому?

Я не сприймаю такого консенсусу. Багато сильних плюсів; кілька мінусів:

• C99 надає масиви змінної довжини, які часто використовуються переважно, оскільки позначення більше відповідають масивам фіксованої довжини та інтуїтивно зрозумілим в цілому
• у багатьох системах доступний менше стеку пам'яті / адреси для стека, ніж для купи, що робить програму трохи більш сприйнятливою до виснаження пам'яті (через переповнення стека): це може сприйматись як хороша чи погана річ - одна з причин, що стек не збільшується автоматично так, як це робить купівель, - це запобігання тим, щоб програми поза контролем мали стільки негативного впливу на всю машину
• при використанні в більш локальної області (наприклад, whileчи forпетлі) або в декількох областях, пам'ять накопичується на ітерацію / обсяг і не вивільняється , поки функція виходів: це контрастує з нормальними змінними , визначеними в рамках структури управління (наприклад , for {int i = 0; i < 2; ++i) { X }буде накопичуватися allocaзапитувана в X пам'ять, але пам'ять для масиву фіксованого розміру буде перероблена за ітерацію).
• сучасні компілятори зазвичай не inlineфункціонують, які викликають alloca, але якщо ви змусите їх, то це allocaвідбудеться в контексті абонентів (тобто стек не буде випущений, поки абонент не повернеться)
• давним-давно allocaперейшов з не портативної функції / злому до стандартизованого розширення, але деяке негативне сприйняття може зберігатися
• термін експлуатації пов'язаний з областю функціонування, яка може або не може відповідати програмісту краще, ніж mallocявний контроль
• необхідність використання mallocзаохочує думати про угоду - якщо це управляється за допомогою функції обгортки (наприклад WonderfulObject_DestructorFree(ptr)), то ця функція дає точку для операцій очищення впровадження (наприклад, закриття дескрипторів файлів, звільнення внутрішніх покажчиків або виконання деяких журналів) без явних змін клієнта код: іноді це приємна модель послідовно прийняти
  • у цьому стилі програмування псевдо-OO, природно бажати чогось подібного WonderfulObject* p = WonderfulObject_AllocConstructor();- це можливо, коли "конструктор" - це функція, що повертає mallocпам'ять, що повертається (оскільки пам'ять залишається виділеною після того, як функція повертає значення для зберігання p), але не якщо "конструктор" використовуєalloca
    • версія макросу WonderfulObject_AllocConstructorможе досягти цього, але "макроси є злими", оскільки вони можуть конфліктувати один з одним та немакрокодовим кодом і створювати ненавмисні підстановки та наслідки важких для діагностики проблем
  • пропущені freeоперації можуть бути виявлені ValGrind, Purify тощо, але відсутні виклики "деструктора" не завжди можуть бути виявлені взагалі - одна дуже неміцна вигода в частині використання призначеного використання; деякі alloca()реалізації (наприклад, GCC'S) використовувати вбудований макрос для alloca(), тому під час виконання підмін пам'яті-використання діагностичної бібліотеки неможливий так воно і є на malloc/ realloc/ free(наприклад , електричний паркан)
• деякі реалізації мають тонкі проблеми: наприклад, зі сторінки управління Linux:

  У багатьох системах аллока () не може бути використана всередині списку аргументів виклику функції, оскільки простір стека, зарезервований аллока (), з'явиться на стеці посеред простору для аргументів функції.

Я знаю, що це питання позначено тегом C, але як програміст на C ++ я думав, що використовую C ++, щоб проілюструвати потенційну корисність alloca: код нижче (і тут у ideone ) створює векторне відстеження поліморфних типів різного розміру, які виділяються стеком (з термін експлуатації, пов'язаний з функцією повернення), а не купою.

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

Усі інші відповіді правильні. Однак якщо річ, яку ви хочете виділити за допомогою alloca(), досить мала, я думаю, що це хороша техніка, яка швидше і зручніше, ніж використання malloc()чи іншим способом.

Іншими словами, alloca( 0x00ffffff )це небезпечно і може спричинити переповнення рівно стільки, скільки char hugeArray[ 0x00ffffff ];є. Будьте обережні та розумні, і у вас все буде добре.

Дуже багато цікавих відповідей на це "старе" питання, навіть деякі відносно нові відповіді, але я не знайшов жодної, яка б це згадувала ....

При правильному та обережному застосуванні послідовне використання alloca() (можливо, на всьому застосуванні) для обробки невеликих розподілів із змінною довжиною (або C99 VLAs, якщо вони доступні) може призвести до зниження загального зростання стека, ніж інакше еквівалентна реалізація з використанням великих розмірів локальних масивів фіксованої довжини . Тож alloca()може бути корисним для вашої стеки, якщо ви ретельно використовуєте її.

Я знайшов цю цитату в .... Добре, я склав цю цитату. Але справді, подумайте про це….

@j_random_hacker дуже правий у своїх коментарях під іншими відповідями: Уникнення використання alloca()на користь негабаритних локальних масивів не робить вашу програму більш безпечною від переповнення стека (якщо тільки ваш компілятор не є достатньо старшим, щоб дозволяти вбудовувати функції, які використовуються. alloca()У цьому випадку вам слід оновлення або, якщо ви не використовуєте alloca()всередині циклів, і в цьому випадку вам слід ... не використовувати alloca()всередині циклів).

Я працював на робочому столі / сервері та вбудованих системах. Багато вбудованих систем взагалі не використовують купу (вони навіть не посилаються на її підтримку) з причин, які включають уявлення про те, що динамічно виділена пам'ять є злою через ризики витоку пам'яті у програмі, яка ніколи коли-небудь перезавантажуватися роками за один раз, або більш розумне обгрунтування того, що динамічна пам’ять небезпечна, оскільки не може бути точно відомо, що програма ніколи не буде фрагментувати свою купу до точки помилкового вичерпання пам'яті. Тому вбудованим програмістам залишається мало альтернатив.

alloca() (або VLA) можуть бути лише правильним інструментом для роботи.

Я знову бачив час і час, коли програміст робить буфер, виділений стеком, "достатньо великий, щоб обробляти будь-який можливий випадок". У глибоко вкладеному дереві викликів багаторазове використання цього (анти -?) Шаблону призводить до перебільшеного використання стека. (Уявіть дерево викликів глибиною 20 рівнів, де на кожному рівні з різних причин функція сліпо перерозподіляє буфер у 1024 байти "просто для безпечності", коли загалом він буде використовувати лише 16 або менше, і лише в дуже рідкісні випадки можуть використовувати більше.) Альтернатива - використанняalloca()або VLA та виділити лише стільки простору стеку, скільки потрібно вашій функції, щоб уникнути зайвого навантаження на стек. Будемо сподіватися, що коли одна функція в дереві викликів потребує розподілу більше, ніж зазвичай, інші в дереві викликів все ще використовують свої звичайні невеликі асигнування, і загальне використання стека додатків значно менше, ніж якщо кожна функція сліпо перерозподіляє локальний буфер .

Але якщо ви вирішите використовувати alloca()...

Виходячи з інших відповідей на цій сторінці, здається, що VLA повинні бути безпечними (вони не з'єднують виділення стеків, якщо викликаються з циклу), але якщо ви використовуєте alloca(), будьте обережні, щоб не використовувати їх у циклі, і зробіть переконайтеся, що ваша функція не може бути вбудована, якщо є ймовірність, що вона може бути викликана в циклі іншої функції.

Усі вже вказали на велику річ, яка є потенційною невизначеною поведінкою через переповнення стека, але я мушу зазначити, що середовище Windows має чудовий механізм, щоб зрозуміти це за допомогою структурованих винятків (SEH) та сторожових сторінок. Оскільки стек росте лише у міру необхідності, ці охоронні сторінки розміщуються в місцях, які не розміщені. Якщо ви виділите в них (переповнюючи стек), викидається виняток.

Ви можете зловити цей виняток SEH і зателефонувати _resetstkoflw, щоб скинути стек і продовжити ваш веселий шлях. Це не ідеально, але це ще один механізм, принаймні знати, що щось пішло не так, коли штука потрапляє у вентилятор. * nix може мати щось подібне, про що я не знаю.

Я рекомендую обмежувати максимальний розмір виділення, загортаючи аллока та відстежуючи його внутрішньо. Якщо ви насправді жорстокі з цього приводу, ви можете викинути деякі довірені обсяги у верхній частині вашої функції, щоб відстежувати будь-які виділення алокації в області функцій, і перевірити це відповідно до максимальної суми, дозволеної для вашого проекту.

Крім того, не допускаючи витоку пам'яті, аллока не викликає фрагментації пам'яті, що є досить важливим. Я не думаю, що аллока є поганою практикою, якщо ти її розумно використовуєш, що в основному стосується всього. :-)

Аллока () приємний і ефективний ... але він також глибоко порушений.

• порушена поведінка області (область дії замість області блоку)
• використовуйте непостоянку з покажчиком з malloc ( alloca ()) не слід звільняти, відтепер вам слід відстежувати, куди ви надходите вказівники, щоб вивільнити () лише ті, які ви отримали з malloc () )
• погана поведінка, коли ви також використовуєте вбудовану лінію (сфера дії іноді переходить до функції виклику залежно від того, чи є виклик накресленим чи ні).
• відсутність перевірки меж стека
• невизначена поведінка у разі відмови (не повертає NULL як malloc ... і що означає несправність, оскільки вона не перевіряє межі стека в будь-якому випадку ...)
• не ansi стандарт

У більшості випадків ви можете замінити його за допомогою локальних змінних та розміру мажоранта. Якщо його використовують для великих предметів, їх розміщення, як правило, є більш безпечною ідеєю.

Якщо він вам справді потрібен, ви можете використовувати VLA (немає vla в C ++, теж погано). Вони значно кращі, ніж аллока () щодо поведінки та послідовності сфери. Як я бачу, VLA - це свого роду аллока (), зроблений правильно.

Звичайно, локальна структура або масив, що використовує мажорант потрібного простору, все ще краще, і якщо у вас немає такого розміщення мажорантової купи за допомогою простого malloc (), ймовірно, розумним. Я не бачу жодного розумного випадку використання, де вам дійсно потрібні алока () або VLA.

Ось чому:

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

Не те, щоб хтось писав цей код, але аргумент розміру, на який ви переходите, allocaмайже напевно походить з якогось вводу, який може злісно націлити на те, щоб домогтися вашої програми allocaчогось такого величезного. Зрештою, якщо розмір не заснований на введенні або не має можливості бути великим, чому ви просто не оголосили невеликий локальний буфер фіксованого розміру?

Практично весь код, що використовує allocaта / або власник C99, має серйозні помилки, що призведе до збоїв (якщо вам пощастить) або компромісних привілеїв (якщо вам не так пощастить).

Я не думаю, що хтось це згадував: Використання аллока у функції перешкоджатиме або відключає деякі оптимізації, які в іншому випадку можуть бути застосовані до функції, оскільки компілятор не може знати розмір кадру стека функції.

Наприклад, загальна оптимізація компіляторами C полягає у усуненні використання покажчика кадру в межах функції, а доступ до кадру робиться відносно покажчика стека; тому є ще один реєстр для загального користування. Але якщо аллока викликається в межах функції, різниця між sp і fp буде невідома для частини функції, тому цю оптимізацію неможливо зробити.

Зважаючи на рідкість його використання та його тінистий статус як стандартної функції, дизайнери компіляторів цілком можливо відключать будь-яку оптимізацію, яка може спричинити проблеми з аллока, якщо знадобиться більше ніж трохи зусиль, щоб змусити її працювати з аллока.

ОНОВЛЕННЯ: Оскільки локальні масиви змінної довжини додані до C, і оскільки вони представляють дуже схожі проблеми генерації коду для компілятора, як аллока, я бачу, що "рідкість використання та тінистий статус" не поширюється на базовий механізм; але я все ще підозрюю, що використання або alloca, або VLA має тенденцію до компрометації генерації коду в межах функції, яка їх використовує. Я вітаю будь-які відгуки дизайнерів-компіляторів.

Одне підводне каміння alloca- це longjmpперемотування його назад.

Тобто, якщо ви збережете контекст із setjmp, то allocaдеякою пам’яттю, то longjmpконтекстом, ви можете втратити allocaпам’ять. Вказівник стека повертається туди, де він був, і тому пам'ять більше не зарезервована; якщо ви зателефонуєте в якусь функцію або зробите іншу alloca, ви заглухнете оригінал alloca.

Для уточнення, на що я тут конкретно маю на увазі ситуацію, коли longjmpне повертається з функції, де allocaвідбулося! Швидше, функція зберігає контекст за допомогою setjmp; потім виділяє пам'ять за допомогою allocaі, нарешті, у цьому контексті відбувається longjmp. allocaПам'ять цієї функції не все звільнена; просто вся пам'ять, яку він виділив з моменту setjmp. Звичайно, я кажу про спостережувану поведінку; жодна така вимога не задокументована жодним, allocaщо я знаю.

Основна увага в документації приділяється тому, що allocaпам'ять пов'язана з активацією функції , а не з будь-яким блоком; що кілька викликів allocaпросто захоплюють більше пам'яті стека, яка вивільняється, коли функція припиняється. Не так; пам'ять фактично пов'язана з контекстом процедури. Коли контекст відновлюється за допомогою longjmp, такий самий попередній allocaстан. Це наслідок того, що сам реєстр покажчиків стека використовується для розподілу, а також (обов'язково) зберігається та відновлюється в jmp_buf.

Між іншим, це, якщо це працює таким чином, забезпечує правдоподібний механізм навмисного звільнення пам'яті, на яку було виділено alloca.

Я натрапив на це як першопричину помилки.

Місце, де alloca()особливо небезпечно, ніж malloc()ядро - ядро ​​типової операційної системи має фіксований розмір простору стека, жорстко закодований в один із його заголовків; він не такий гнучкий, як стек програми. Здійснення дзвінка alloca()з необґрунтованим розміром може призвести до збою ядра. Деякі компілятори попереджають про використання alloca()(і навіть VLA для цього питання) під певними параметрами, які слід увімкнути під час компіляції коду ядра - тут краще виділити пам'ять у купі, яка не фіксована жорстко закодованим лімітом.

Якщо ви випадково allocaзаписуєте за межі блоку, виділеного з (наприклад, через переповнення буфера), тоді ви перезапишете зворотну адресу своєї функції, тому що ця розташована "вище" на стеці, тобто після виділеного вами блоку.

Наслідок цього двоякий:

1. Програма призведе до краху, і неможливо буде сказати, чому і де вона вийшла з ладу (стек, швидше за все, відкрутить до випадкової адреси через перезаписаний покажчик кадру).

2. Це робить переповнення буфера в багато разів небезпечнішим, оскільки зловмисник може створити спеціальну корисну навантаження, яка буде розміщена на стеку і тому може закінчитися виконанням.

На противагу цьому, якщо ви пишете поза блоком на купі, ви "просто" отримуєте пошкодження купи. Програма, ймовірно, завершиться несподівано, але належним чином розмотає стек, тим самим знижуючи ймовірність виконання зловмисного коду.

На жаль, справді дивовижного alloca()не вистачає майже чудового ТЦК. Gcc є alloca().

1. Він сіє насіння власного знищення. З поверненням як деструктор.

2. Начебто malloc()він повертає недійсний покажчик на помилку, який буде розбито на сучасні системи з MMU (і, сподіваємось, перезапустіть без нього).

3. На відміну від автоматичних змінних, ви можете вказати розмір під час виконання.

Добре справляється з рекурсією. Ви можете використовувати статичні змінні, щоб досягти чогось подібного до хвостової рекурсії та використовувати лише декілька інших для передачі інформації для кожної ітерації.

Якщо ви натискаєте занадто глибоко, ви впевнені в сегменті (якщо у вас є MMU).

Зверніть увагу, що він malloc()не пропонує більше, оскільки він повертає NULL (який також буде сегментарно, якщо він призначений), коли система не має пам'яті. Тобто все, що ви можете зробити - це застава або просто спробувати призначити це будь-яким способом.

Для використання malloc()я використовую глобальні та присвоюю їм NULL. Якщо вказівник не NULL, я звільняю його перед використанням malloc().

Ви також можете використовувати realloc()як загальний регістр, якщо хочете скопіювати будь-які наявні дані. Потрібно перевірити вказівник перед тим, як розібратися, чи збираєтесь ви скопіювати або об'єднати після realloc().

3.2.5.2 Переваги алоки

Процеси мають лише обмежену кількість місця в стеці - набагато менше, ніж об'єм пам'яті, доступний malloc().

Використовуючи alloca()ви, різко збільшуйте шанси отримати помилку переповнення стека (якщо вам пощастить, або незрозумілу аварію, якщо ви цього не зробите).

Не дуже красиво, але якщо продуктивність дійсно важлива, ви можете виділити трохи місця на стеку.

Якщо ви вже максимум розміру блоку пам'яті, який вам потрібно, і ви хочете продовжувати перевірки на переповнення, ви можете зробити щось на кшталт:

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

    (...)
}

Функція алока чудова, і всі найсеї просто поширюють FUD.

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

Масив та параметри ТОЧНО однакові з РОЗПОВІДАМИ однакових ризиків. Говорити, що один кращий за інший - це синтаксичний вибір, а не технічний.

Що стосується вибору змінних стека проти змінних купи, то існує багато переваг для довгих запущених програм, що використовують стек над купою для змінних із строком життя. Ви уникаєте фрагментації купи і можете уникнути збільшення простору процесу за допомогою невикористаного (непридатного) простору. Не потрібно це прибирати. Ви можете контролювати розподіл стеку в процесі.

Чому це погано?

Насправді, аллока не гарантує використання стека. Дійсно, реалізація alc-2,95 аллока виділяє пам'ять із купи за допомогою самого malloc. Крім того, що реалізація є помилковою, вона може призвести до витоку пам'яті та до несподіваної поведінки, якщо ви зателефонуєте всередині блоку з подальшим використанням goto. Не кажучи про те, що ви ніколи не повинні його використовувати, але іноді алока призводить до великих витрат, ніж це звільняє від себе.

IMHO, аллока вважається поганою практикою, тому що всі бояться вичерпати обмеження розміру стека.

Я багато чого дізнався, прочитавши цю тему та деякі інші посилання:

• /unix/63742/what-is-automatic-stack-expansion
• Ліміт розподілу стеків для програм на 32-бітній машині Linux
• ulimit -s

Я використовую аллока в основному, щоб зробити мої звичайні файли C компільованими у msvc та gcc без будь-яких змін, стиль C89, не #ifdef _MSC_VER тощо.

Дякую ! Ця тема змусила мене зареєструватися на цьому сайті :)

На мою думку, аллока (), якщо вона є, повинна використовуватися лише обмежено. Дуже схоже на використання "goto", досить велика кількість інакше розумних людей має сильну неприязнь не лише до використання, але й до існування аллока ().

Для вбудованого використання, коли розмір стека відомий і обмеження можуть бути накладені за допомогою конвенції та аналізу розміру виділення, і де компілятор не може бути оновлений для підтримки C99 +, використання alloca () є нормальним, і я був відомо, що його використовують.

Якщо вони доступні, VLA можуть мати деякі переваги порівняно з alloca (): Компілятор може генерувати перевірку ліміту стеків, яка буде отримувати доступ поза межами діапазону, коли використовується доступ до стилю масиву (я не знаю, чи це роблять якісь компілятори, але це може буде зроблено), і аналіз коду може визначити, чи вирази доступу до масиву правильно обмежені. Зауважте, що в деяких середовищах програмування, таких як автомобільна, медична техніка та авіоніка, цей аналіз потрібно робити навіть для масивів фіксованого розміру, як автоматичного (на стеку), так і статичного розподілу (глобального або локального).

У архітектурах, які зберігають і дані, і зворотні адреси / покажчики кадру на стеці (з того, що я знаю, це все), будь-яка розподілена стека може бути небезпечною, оскільки може бути взята адреса змінної, і неперевірені вхідні значення можуть дозволяти всілякі пустощі.

Переносність викликає занепокоєння у вбудованому просторі, проте це хороший аргумент проти використання аллока () поза ретельно контрольованими обставинами.

Поза вбудованого простору я використовував аллока () здебільшого всередині функцій реєстрації та форматування для ефективності, а також у нерекурсивному лексичному сканері, де тимчасові структури (виділені за допомогою аллока () створюються під час токенізації та класифікації, а потім стійкі Об'єкт (виділений через malloc ()) заповнюється до повернення функції. Використання аллока () для менших тимчасових структур значно зменшує фрагментацію при виділенні стійкого об'єкта.

Більшість відповідей тут значною мірою пропускають суть: є причина, чому використання _alloca()потенційно гірше, ніж просто зберігання великих предметів у стеку.

Основна відмінність автоматичного зберігання від цього _alloca()полягає в тому, що останній страждає від додаткової (серйозної) проблеми: виділений блок не контролюється компілятором , тому компілятор не може його оптимізувати чи переробити.

Порівняйте:

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

з:

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

Проблема з останнім повинна бути очевидною.

Я не думаю, що хтось про це згадував, але аллока також має серйозні проблеми безпеки, не обов'язково присутніми з malloc (хоча ці проблеми також виникають із будь-якими масивами на основі стека, динамічними чи ні). Оскільки пам’ять виділяється на стек, переповнення / підтоки буфера мають набагато серйозніші наслідки, ніж лише з malloc.

Зокрема, зворотна адреса функції зберігається у стеку. Якщо це значення пошкодиться, ваш код може бути перетворений на будь-яку виконавчу область пам'яті. Компілятори намагаються зробити це важким (зокрема, рандомізувавши макет адреси). Однак це явно гірше, ніж просто переповнення стека, оскільки найкращим випадком є ​​SEGFAULT, якщо повернене значення пошкоджено, але воно може також почати виконувати випадковий фрагмент пам'яті або, в гіршому випадку, якийсь регіон пам'яті, який загрожує безпеці вашої програми. .