Почему использование 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);

Он находится в стандарте C99 и существует как расширение компилятора во многих компиляторах.

Как отмечено в этой публикации в группе новостей, есть несколько причин, по которым использование alloca можно считать сложными и опасными:

• Не все компиляторы поддерживают alloca.
• Некоторые компиляторы по-разному интерпретируют предполагаемое поведение alloca, поэтому переносимость не гарантируется даже между компиляторами, которые его поддерживают.
• Некоторые реализации содержат ошибки.

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

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

Я не вижу такого консенсуса. Множество сильных плюсов; несколько минусов:

• C99 предоставляет массивы переменной длины, которые часто предпочтительнее использовать, поскольку нотация более согласована с массивами фиксированной длины и интуитивно понятна в целом.
• многие системы имеют меньше общей памяти / адресного пространства, доступного для стека, чем для кучи, что делает программу немного более восприимчивой к исчерпанию памяти (из-за переполнения стека): это можно рассматривать как хорошо или плохо - одно из причин, по которым стек не увеличивается автоматически, как это делает куча, является предотвращение того, чтобы неконтролируемые программы оказывали столь же негативное влияние на всю машину
• при использовании в более локальной области (например, в цикле while или for) или в нескольких областях память накапливается за итерацию / область действия и не освобождается до выхода из функции: это контрастирует с обычными переменными, определенными в области действия управляющей структуры. (например, for {int i = 0; i < 2; ++i) { X } будет накапливать alloca-ed память, запрошенную в X, но память для массива фиксированного размера будет повторно использоваться за итерацию).
• современные компиляторы обычно не inline функции, которые вызывают alloca, но если вы заставите их, то alloca произойдет в контексте вызывающих (т.е. стек не будет освобожден до тех пор, пока вызывающий не вернется)
• давным-давно alloca перешел от непереносимой функции / хака к стандартизированному расширению, но некоторое негативное восприятие может сохраниться
• время жизни привязано к области действия функции, которая может или не может устраивать программиста лучше, чем явное управление malloc
• having to use malloc encourages thinking about the deallocation - if that's managed through a wrapper function (e.g. WonderfulObject_DestructorFree(ptr)), then the function provides a point for implementation clean up operations (like closing file descriptors, freeing internal pointers or doing some logging) without explicit changes to client code: sometimes it's a nice model to adopt consistently
  • in this pseudo-OO style of programming, it's natural to want something like WonderfulObject* p = WonderfulObject_AllocConstructor(); - that's possible when the "constructor" is a function returning malloc-ed memory (as the memory remains allocated after the function returns the value to be stored in p), but not if the "constructor" uses alloca
    • a macro version of WonderfulObject_AllocConstructor could achieve this, but "macros are evil" in that they can conflict with each other and non-macro code and create unintended substitutions and consequent difficult-to-diagnose problems
  • отсутствующие free операции могут быть обнаружены ValGrind, Purify и т. д., но отсутствующие вызовы «деструктора» не всегда могут быть обнаружены вообще - одно очень незначительное преимущество с точки зрения обеспечения предполагаемого использования; некоторые реализации alloca() (например, GCC) используют встроенный макрос для alloca(), поэтому замена библиотеки диагностики использования памяти во время выполнения невозможна, как для _20 _ / _ 21 _ / _ 22_ (например, электрический забор)
• some implementations have subtle issues: for example, from the Linux manpage:

  Во многих системах alloca () нельзя использовать внутри списка аргументов вызова функции, потому что пространство стека, зарезервированное функцией alloca (), будет отображаться в стеке посередине пространства для аргументов функции.

---

Я знаю, что этот вопрос помечен тегом C, но как программист на C ++ я подумал, что буду использовать C ++, чтобы проиллюстрировать потенциальную полезность alloca: приведенный ниже код (и здесь at 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
    }
}

person Tony Delroy    schedule 26.02.2013
comment
нет +1 из-за подозрительного идиосинкразического подхода к нескольким типам :-( - person einpoklum; 18.07.2015
comment
@einpoklum: ну, это поучительно ... спасибо. - person Tony Delroy; 18.07.2015
comment
Перефразирую: это очень хороший ответ. Вплоть до того момента, когда я думаю, вы предлагаете людям использовать своего рода контр-паттерн. - person einpoklum; 18.07.2015
comment
Комментарий с man-страницы linux очень старый и, я уверен, устарел. Все современные компиляторы знают, что такое alloca (), и не споткнутся вот так. В старом K&R C: (1) все функции использовали указатели кадров (2) Все вызовы функций были {push args on stack} {call func} {add # n, sp}. alloca была функцией библиотеки, которая просто поднимала стек вверх, компилятор даже не знал об этом. (1) и (2) больше не верны, поэтому alloca не может работать таким образом (теперь это внутренняя функция). В старом C вызов alloca в середине отправки аргументов, очевидно, нарушил бы и эти предположения. - person greggo; 02.05.2017
comment
Что касается примера, меня обычно беспокоит что-то, что требует always_inline, чтобы избежать повреждения памяти .... - person greggo; 02.05.2017
comment
Использует новое размещение для возврата буфера выделения. Если функция оказывается не встроенной, вы уничтожаете стек. Ваш код не определен. - person Joshua; 25.09.2019
comment
если кто-нибудь прочитает это: современный стиль C ++ для размещения в стеке осуществляется через allocator - создайте его и направьте все векторы и новые через него - person Noone AtAll; 22.07.2020

Все остальные ответы верны. Однако, если вещь, которую вы хотите выделить с помощью alloca(), достаточно мала, я думаю, что это хороший метод, который быстрее и удобнее, чем использование malloc() или иное.

Другими словами, alloca( 0x00ffffff ) опасен и может вызвать переполнение, как и char hugeArray[ 0x00ffffff ];. Будьте осторожны и рассудительны, и все будет в порядке.

Множество интересных ответов на этот "старый" вопрос, даже несколько относительно новых ответов, но я не нашел ни одного упоминания об этом ....

При правильном и осторожном использовании последовательное использование alloca() (возможно, в масштабе всего приложения) для обработки небольших распределений переменной длины (или C99 VLA, если они доступны) может привести к меньшему общему росту стека, чем аналогичный реализация с использованием негабаритных локальных массивов фиксированной длины. Так что alloca() может быть полезным для вашего стека, если вы будете его использовать осторожно.

Я нашел эту цитату в .... Хорошо, я придумал эту цитату. Но на самом деле подумайте об этом ....

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

Я работал над настольными / серверными средами и встроенными системами. Многие встроенные системы вообще не используют кучу (они даже не связываются для ее поддержки) по причинам, включающим в себя представление о том, что динамически выделяемая память является злом из-за рисков утечек памяти в приложении, которое никогда не когда-либо перезагружается в течение многих лет, или более разумное оправдание того, что динамическая память опасна, потому что нельзя знать наверняка, что приложение никогда не фрагментирует свою кучу до точки ложного исчерпания памяти. Таким образом, у встроенных программистов остается мало альтернатив.

alloca() (или VLA) может быть подходящим инструментом для работы.

Я снова и снова видел, как программист делает буфер, выделенный стеком, «достаточно большим для обработки любого возможного случая». В глубоко вложенном дереве вызовов повторное использование этого (анти -?) Шаблона приводит к чрезмерному использованию стека. (Представьте себе дерево вызовов глубиной 20 уровней, где на каждом уровне по разным причинам функция слепо перераспределяет буфер размером 1024 байта «на всякий случай», когда обычно используется только 16 или меньше из них, и только в очень больших количествах. в редких случаях может использоваться больше.) Альтернативой является использование alloca() или VLA и выделение столько места в стеке, сколько требуется вашей функции, чтобы избежать ненужной нагрузки на стек. Надеюсь, когда одной функции в дереве вызовов требуется выделение большего размера, чем обычно, другие в дереве вызовов по-прежнему используют свои обычные небольшие выделения, а общее использование стека приложения значительно меньше, чем если бы каждая функция слепо перераспределяла локальный буфер .

Но если вы решите использовать _9 _...

Основываясь на других ответах на этой странице, кажется, что VLA должны быть безопасными (они не объединяют выделения стека, если вызываются из цикла), но если вы используете alloca(), будьте осторожны, чтобы не использовать его внутри цикла, и убедитесь, что ваша функция не может быть встроена, если есть вероятность, что она может быть вызвана в цикле другой функции.

Все уже указали на важную вещь, которая является потенциальным неопределенным поведением из-за переполнения стека, но я должен упомянуть, что в среде Windows есть отличный механизм для обнаружения этого с помощью структурированных исключений (SEH) и защитных страниц. Поскольку стек увеличивается только по мере необходимости, эти защитные страницы находятся в нераспределенных областях. Если вы выделяете в них (переполняя стек), генерируется исключение.

Вы можете поймать это исключение SEH и вызвать _resetstkoflw, чтобы сбросить стек и продолжить свой веселый путь. Это не идеально, но это еще один механизм, позволяющий хотя бы знать, что что-то пошло не так, когда материал попадает в вентилятор. * nix может иметь что-то подобное, о чем я не знаю.

Я рекомендую ограничить максимальный размер выделения, обернув alloca и отслеживая его внутри. Если бы вы были действительно хардкорными в этом вопросе, вы могли бы установить несколько стражей области в верхней части своей функции, чтобы отслеживать любые выделения выделения в области действия функции и проверять работоспособность на соответствие максимальной сумме, разрешенной для вашего проекта.

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

Я не думаю, что кто-то упомянул об этом: использование alloca в функции будет препятствовать или отключать некоторые оптимизации, которые в противном случае могли бы быть применены в функции, поскольку компилятор не может знать размер фрейма стека функции.

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

Учитывая редкость его использования и сомнительный статус стандартной функции, разработчики компилятора вполне могут отключить любую оптимизацию, которая может вызвать проблемы с alloca, если потребуется больше, чем немного усилий, чтобы заставить его работать с alloca.

ОБНОВЛЕНИЕ. Поскольку в C были добавлены локальные массивы переменной длины, и поскольку они представляют очень похожие проблемы генерации кода для компилятора, как alloca, я вижу, что «редкость использования и сомнительный статус» не применить к базовому механизму; но я все равно подозреваю, что использование 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.

Я столкнулся с этим как с основной причиной ошибки.

Вот почему:

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

Не то чтобы кто-нибудь мог написать этот код, но аргумент размера, который вы передаете alloca, почти наверняка исходит от какого-то типа ввода, который может злонамеренно направить вашу программу на alloca что-то подобное. В конце концов, если размер не зависит от ввода или не может быть большим, почему вы просто не объявили небольшой локальный буфер фиксированного размера?

Практически весь код, использующий alloca и / или C99 vlas, содержит серьезные ошибки, которые приведут к сбоям (если вам повезет) или компрометации привилегий (если вам не повезло).

alloca () хорош и эффективен ... но он также глубоко сломан.

• нарушенное поведение области (область функции вместо области блока)
• используйте несовместимое с malloc (указатель alloca () не должен освобождаться, отныне вы должны отслеживать, откуда поступают ваши указатели, на free () только те, которые у вас есть с malloc ())
• плохое поведение, когда вы также используете встраивание (иногда область видимости переходит к функции вызывающего, в зависимости от того, встроен ли вызываемый объект или нет).
• нет проверки границ стека
• undefined поведение в случае сбоя (не возвращает NULL, как malloc ... и что означает сбой, поскольку он все равно не проверяет границы стека ...)
• не стандарт ANSI

В большинстве случаев вы можете заменить его, используя локальные переменные и мажорантный размер. Если он используется для больших объектов, положить их в кучу обычно более безопасно.

Если вам это действительно нужно C, вы можете использовать VLA (без vla в C ++, очень плохо). Они намного лучше, чем alloca (), в отношении поведения и согласованности области видимости. На мой взгляд, VLA - это своего рода alloca (), сделанная правильно.

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

Место, где alloca() особенно опасно, чем malloc(), это ядро ​​- ядро ​​типичной операционной системы имеет пространство стека фиксированного размера, жестко закодированное в одном из его заголовков; он не такой гибкий, как стек приложения. Выполнение вызова alloca() с необоснованным размером может привести к сбою ядра. Некоторые компиляторы предупреждают об использовании alloca() (и даже VLA, если на то пошло) при определенных параметрах, которые должны быть включены при компиляции кода ядра - здесь лучше выделять память в куче, которая не фиксируется жестко заданным пределом .

Если вы случайно напишете за пределами блока, выделенного с помощью alloca (например, из-за переполнения буфера), то вы перезапишете адрес возврата вашей функции, потому что он расположен «выше» в стеке, т.е. после выделенного блока.

Последствия этого двоякие:

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

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

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

У процессов есть только ограниченный объем доступного пространства стека - намного меньше, чем объем памяти, доступный для malloc().

Используя alloca(), вы резко увеличиваете свои шансы получить ошибку переполнения стека (если вам повезет, или необъяснимый сбой в противном случае).

К сожалению, действительно потрясающий alloca() отсутствует в почти потрясающем tcc. Gcc действительно имеет alloca().

1. Он сеет семена собственного разрушения. С return в качестве деструктора.

2. Как и malloc(), он возвращает неверный указатель при сбое, что приведет к сбою в современных системах с MMU (и, надеюсь, перезапустит их без).

3. В отличие от автоматических переменных, вы можете указать размер во время выполнения.

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

Если вы нажмете слишком глубоко, вы наверняка столкнетесь с ошибкой сегментации (если у вас есть MMU).

Обратите внимание, что malloc() больше не предлагает, поскольку он возвращает NULL (который также будет иметь ошибку segfault, если он назначен), когда системе не хватает памяти. Т.е. все, что вы можете сделать, это внести залог или просто попытаться назначить его каким-либо образом.

Чтобы использовать malloc(), я использую глобальные переменные и присваиваю им NULL. Если указатель не равен NULL, я освобождаю его перед использованием malloc().

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

3.2. 5.2 Преимущества alloca

На самом деле не гарантируется, что alloca будет использовать стек. Действительно, реализация alloca в gcc-2.95 выделяет память из кучи с помощью самого malloc. Также эта реализация содержит ошибки, это может привести к утечке памяти и некоторому неожиданному поведению, если вы вызовете его внутри блока с дальнейшим использованием goto. Нет, чтобы сказать, что вы никогда не должны его использовать, но иногда alloca приводит к большим накладным расходам, чем освобождает от них.

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

Для встроенного использования, когда размер стека известен и ограничения могут быть наложены посредством соглашения и анализа размера выделения, и когда компилятор не может быть обновлен для поддержки C99 +, использование alloca () подходит, и я был известно использовать его.

Когда они доступны, VLA могут иметь некоторые преимущества перед alloca (): компилятор может генерировать проверки ограничения стека, которые улавливают доступ за пределы, когда используется доступ к стилю массива (я не знаю, делают ли это какие-либо компиляторы, но он может быть сделано), и анализ кода может определить, правильно ли ограничены выражения доступа к массиву. Обратите внимание, что в некоторых средах программирования, таких как автомобилестроение, медицинское оборудование и авионика, этот анализ должен выполняться даже для массивов фиксированного размера, как автоматического (в стеке), так и статического распределения (глобального или локального).

В архитектурах, которые хранят в стеке как данные, так и адреса возврата / указатели фреймов (насколько я знаю, это все), любая выделенная в стеке переменная может быть опасной, потому что адрес переменной может быть взят, а непроверенные входные значения могут разрешить всякие озорства.

Переносимость менее важна для встроенного пространства, однако это хороший аргумент против использования alloca () вне тщательно контролируемых обстоятельств.

За пределами встроенного пространства я использовал alloca () в основном внутри функций ведения журнала и форматирования для повышения эффективности, а также в нерекурсивном лексическом сканере, где временные структуры (выделенные с помощью alloca () создаются во время токенизации и классификации, а затем постоянный объект (выделенный через malloc ()) заполняется до возврата из функции. Использование alloca () для небольших временных структур значительно снижает фрагментацию при выделении постоянного объекта.

Я не думаю, что кто-то упомянул об этом, но у alloca также есть некоторые серьезные проблемы с безопасностью, которые не обязательно присутствуют в malloc (хотя эти проблемы также возникают с любыми массивами на основе стека, динамическими или нет). Поскольку память выделяется в стеке, переполнение / опустошение буфера имеет гораздо более серьезные последствия, чем просто malloc.

В частности, в стеке хранится адрес возврата для функции. Если это значение будет повреждено, ваш код может быть перемещен в любую исполняемую область памяти. Компиляторы делают все возможное, чтобы усложнить эту задачу (в частности, путем рандомизации компоновки адресов). Однако это явно хуже, чем просто переполнение стека, поскольку в лучшем случае это SEGFAULT, если возвращаемое значение повреждено, но он также может начать выполнение случайного фрагмента памяти или, в худшем случае, некоторой области памяти, которая ставит под угрозу безопасность вашей программы. .

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

Основное различие между автоматическим хранением и _alloca() заключается в том, что последний страдает дополнительной (серьезной) проблемой: выделенный блок не контролируется компилятором, поэтому компилятор не может оптимизировать или переработать его. .

Сравнивать:

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

с участием:

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

Проблема с последним должна быть очевидна.