Dlaczego korzystanie z funkcji splita () nie jest uważane za dobrą praktykę?

alloca()przydziela pamięć na stosie, a nie na stercie, jak w przypadku malloc(). Kiedy wracam z rutyny, pamięć zostaje uwolniona. Tak więc faktycznie rozwiązuje to mój problem zwalniania dynamicznie alokowanej pamięci. Zwolnienie pamięci przydzielonej przez malloc()to poważny ból głowy i jeśli w jakiś sposób pominięty, prowadzi do różnego rodzaju problemów z pamięcią.

Dlaczego stosowanie alloca()powyższych funkcji jest odradzane pomimo powyższych funkcji?

Odpowiedź znajduje się na manstronie (przynajmniej w systemie Linux ):

WARTOŚĆ ZWRACANA Funkcja przydzielania () zwraca wskaźnik na początek przydzielonego miejsca. Jeśli przydział powoduje przepełnienie stosu, zachowanie programu jest niezdefiniowane.

Co nie znaczy, że nigdy nie należy go używać. Jeden z projektów OSS, nad którym pracuję, wykorzystuje go w szerokim zakresie i dopóki go nie nadużywasz ( allocaz dużymi wartościami), jest w porządku. Gdy miniesz znak „kilkaset bajtów”, czas na użycie malloci przyjaciół. Nadal możesz otrzymywać awarie alokacji, ale przynajmniej będziesz mieć pewne oznaki niepowodzenia zamiast po prostu wysadzić stos.

Jednym z najbardziej pamiętnych błędów, jakie miałem, było użycie wbudowanej funkcji alloca. Przejawiał się jako przepełnienie stosu (ponieważ alokuje na stosie) w losowych punktach wykonania programu.

W pliku nagłówkowym:

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

W pliku implementacyjnym:

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

Tak więc stało się z wbudowaną DoSomethingfunkcją kompilatora, a wszystkie alokacje stosu odbywały się wewnątrz Process()funkcji i tym samym wysadzały stos. W mojej obronie (i to nie ja znalazłem problem; musiałem iść i płakać do jednego ze starszych programistów, kiedy nie mogłem go naprawić), nie było to proste alloca, to była konwersja ciągów ATL makra.

Lekcja brzmi: nie używaj allocaw funkcjach, które Twoim zdaniem mogą być wbudowane.

Stare pytanie, ale nikt nie wspomniał, że należy je zastąpić tablicami o zmiennej długości.

char arr[size];

zamiast

char *arr=alloca(size);

Jest w standardowym C99 i istniał jako rozszerzenie kompilatora w wielu kompilatorach.

alokacja () jest bardzo przydatna, jeśli nie możesz użyć standardowej zmiennej lokalnej, ponieważ jej rozmiar musiałby zostać określony w czasie wykonywania i możesz absolutnie zagwarantować, że wskaźnik, który otrzymujesz z alokacji (), NIGDY nie zostanie użyty po powrocie tej funkcji .

Możesz być całkiem bezpieczny, jeśli tak

• nie zwracaj wskaźnika ani niczego, co go zawiera.
• nie przechowuj wskaźnika w żadnej strukturze przydzielonej na stercie
• nie pozwól, aby jakikolwiek inny wątek używał wskaźnika

Prawdziwe niebezpieczeństwo wiąże się z szansą, że ktoś później naruszy te warunki. Mając to na uwadze, świetnie nadaje się do przekazywania buforów do funkcji formatujących w nich tekst :)

Jak zauważono w tym poście , istnieje kilka powodów, dla których używanie allocamoże być uważane za trudne i niebezpieczne:

• Nie wszystkie kompilatory obsługują alloca.
• Niektóre kompilatory allocaróżnie interpretują zamierzone zachowanie , więc przenośność nie jest gwarantowana nawet między kompilatorami, które je obsługują.
• Niektóre implementacje są błędne.

Jednym z problemów jest to, że nie jest standardem, chociaż jest szeroko obsługiwany. Gdy inne rzeczy są takie same, zawsze używałbym standardowej funkcji zamiast wspólnego rozszerzenia kompilatora.

nadal odradza się używanie alokacji, dlaczego?

Nie dostrzegam takiego konsensusu. Wiele silnych zalet; kilka wad:

• C99 zapewnia tablice o zmiennej długości, które często byłyby stosowane preferencyjnie, ponieważ notacja jest bardziej spójna z tablicami o stałej długości i ogólnie intuicyjnie
• wiele systemów ma mniej ogólnej pamięci / przestrzeni adresowej dostępnej dla stosu niż dla stosu, co czyni program nieco bardziej podatnym na wyczerpanie pamięci (poprzez przepełnienie stosu): może to być postrzegane jako dobre lub złe - jedno z powodów, dla których stos nie rośnie automatycznie w taki sam sposób, jak sterty, jest zapobieganie, aby niekontrolowane programy miały tak niekorzystny wpływ na całą maszynę
• w przypadku zastosowania w bardziej lokalnym zasięgu (takim jak pętla whilelub for) lub w kilku zakresach pamięć gromadzi się w zależności od iteracji / zakresu i nie jest zwalniana do momentu wyjścia z funkcji: kontrastuje to z normalnymi zmiennymi zdefiniowanymi w zakresie struktury kontroli (np. for {int i = 0; i < 2; ++i) { X }zgromadziłaby allocapamięć-X wymaganą w X, ale pamięć dla macierzy o stałej wielkości byłaby ponownie przetwarzana dla każdej iteracji).
• nowoczesne kompilatory zazwyczaj nie inlinedziałają wzywające alloca, ale jeśli je wymusisz, allocanastąpi to w kontekście dzwoniących (tzn. stos nie zostanie zwolniony, dopóki dzwoniący nie powróci)
• dawno temu allocaprzeszedł z nieprzenośnej funkcji / hacka do standardowego rozszerzenia, ale pewne negatywne postrzeganie może się utrzymywać
• czas życia jest powiązany z zakresem funkcji, który może, ale nie musi, odpowiadać programiście lepiej niż mallocwyraźna kontrola
• konieczność użycia malloczachęca do myślenia o dealokacji - jeśli jest to zarządzane za pomocą funkcji otoki (np. WonderfulObject_DestructorFree(ptr)), wówczas funkcja zapewnia punkt dla operacji czyszczenia implementacji (takich jak zamykanie deskryptorów plików, zwalnianie wewnętrznych wskaźników lub przeprowadzanie rejestrowania) bez wyraźnych zmian w kliencie kod: czasami jest to miły model do konsekwentnego przyjmowania
  • w tym pseudo-OO stylu programowania jest rzeczą naturalną chcieć czegoś podobnego WonderfulObject* p = WonderfulObject_AllocConstructor();- jest to możliwe, gdy „konstruktor” jest funkcją zwracającą mallocpamięć (ponieważ pamięć pozostaje przydzielona po zwróceniu przez funkcję wartości do zapamiętania p), ale nie jeśli używa „konstruktora”alloca
    • wersja makr WonderfulObject_AllocConstructormoże to osiągnąć, ale „makra są złe”, ponieważ mogą one powodować konflikty między sobą i kodem innym niż makr oraz tworzyć niezamierzone zamiany i wynikające z tego trudne do zdiagnozowania problemy
  • freeValGrind, Purify itp. mogą wykryć brakujące operacje, ale nie zawsze można wykryć brakujące wywołania „destruktora” - jedna bardzo niewielka korzyść w zakresie egzekwowania zamierzonego użycia; niektóre alloca()implementacje (takie jak GCC) używają wbudowanego makra alloca(), więc podstawienie biblioteki diagnostycznej wykorzystania pamięci w czasie wykonywania nie jest możliwe w taki sposób, jak w przypadku malloc/ realloc/ free(np. ogrodzenie elektryczne)
• niektóre implementacje mają subtelne problemy: na przykład z podręcznika systemu Linux:

  W wielu systemach nie można używać funkcji wywoływania () na liście argumentów wywołania funkcji, ponieważ przestrzeń stosu zarezerwowana przez funkcję wywoływania pojawiłaby się na stosie w środku miejsca dla argumentów funkcji.

Wiem, że to pytanie jest oznaczone jako C, ale jako programista C ++ pomyślałem, że użyję C ++ do zilustrowania potencjalnej użyteczności alloca: poniższy kod (i tutaj w ideone ) tworzy wektor śledzący typy polimorficzne o różnej wielkości, które są przydzielane stosowo (z czas życia związany z funkcją return) zamiast przydzielonej sterty.

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

Wszystkie pozostałe odpowiedzi są poprawne. Jeśli jednak rzecz, którą chcesz przydzielić, alloca()jest stosunkowo niewielka, uważam, że jest to dobra technika, która jest szybsza i wygodniejsza niż używanie malloc()lub w inny sposób.

Innymi słowy, alloca( 0x00ffffff )jest niebezpieczny i może spowodować przepełnienie, dokładnie tak samo jak char hugeArray[ 0x00ffffff ];jest. Bądź ostrożny i rozsądny, a wszystko będzie dobrze.

Wiele interesujących odpowiedzi na to „stare” pytanie, nawet niektóre stosunkowo nowe odpowiedzi, ale nie znalazłem żadnej, która wspomniałaby o tym ....

Przy prawidłowym i ostrożnym stosowaniu konsekwentne stosowanie alloca() (być może w całej aplikacji) do obsługi małych przydziałów o zmiennej długości (lub VLA C99, jeśli są dostępne) może prowadzić do niższego ogólnego wzrostu stosu niż w innym przypadku równoważna implementacja z wykorzystaniem dużych lokalnych tablic o stałej długości . alloca()Może więc być dobry dla twojego stosu, jeśli użyjesz go ostrożnie.

Znalazłem ten cytat w ... OK, zrobiłem go. Ale naprawdę, pomyśl o tym ....

@j_random_hacker ma rację w swoich komentarzach pod innymi odpowiedziami: Unikanie użycia alloca()na rzecz przewymiarowanych tablic lokalnych nie czyni twojego programu bezpieczniejszym przed przepełnieniem stosu (chyba że twój kompilator jest wystarczająco stary, aby umożliwić wstawianie funkcji, które alloca()w takim przypadku należy zastosować uaktualnić lub, chyba że używasz alloca()pętli wewnętrznych, w takim przypadku nie powinieneś ... nie używać alloca()pętli wewnętrznych).

Pracowałem w środowiskach desktop / server i systemach wbudowanych. Wiele systemów wbudowanych w ogóle nie korzysta ze sterty (nawet nie łączy się z obsługą), z powodów obejmujących przekonanie, że pamięć dynamicznie przydzielana jest zła z powodu ryzyka wycieków pamięci w aplikacji, która nigdy nie zawsze restartuje się przez lata lub bardziej rozsądne uzasadnienie, że pamięć dynamiczna jest niebezpieczna, ponieważ nie można z całą pewnością stwierdzić, że aplikacja nigdy nie podzieli stosu do momentu wyczerpania fałszywej pamięci. Dlatego wbudowanym programistom pozostaje niewiele alternatyw.

alloca() (lub VLA) może być właściwym narzędziem do pracy.

Raz po raz widziałem, jak programista sprawia, że ​​bufor przydzielany przez stos jest „wystarczająco duży, aby obsłużyć każdą możliwą sprawę”. W głęboko zagnieżdżonym drzewie wywołań wielokrotne stosowanie tego wzorca (anty -?) Prowadzi do przesadzonego użycia stosu. (Wyobraź sobie, że drzewo wywołań ma 20 poziomów głębokości, gdzie na każdym poziomie z różnych powodów funkcja ślepo przesadza bufor 1024 bajtów „po prostu dla bezpieczeństwa”, gdy generalnie użyje tylko 16 lub mniej z nich, i tylko w bardzo w rzadkich przypadkach można użyć więcej.) Alternatywą jest użyciealloca()lub VLA i alokuj tylko tyle miejsca na stosie, ile potrzebuje Twoja funkcja, aby uniknąć niepotrzebnego obciążania stosu. Mamy nadzieję, że gdy jedna funkcja w drzewie połączeń wymaga alokacji większej niż normalna, inne w drzewie połączeń nadal używają swoich normalnych małych alokacji, a ogólne użycie stosu aplikacji jest znacznie mniejsze niż w przypadku, gdy każda funkcja ślepo nadmiernie alokuje bufor lokalny .

Ale jeśli zdecydujesz się użyć alloca()...

Na podstawie innych odpowiedzi na tej stronie wydaje się, że VLA powinny być bezpieczne (nie łączą alokacji stosu, jeśli są wywoływane z pętli), ale jeśli używasz alloca(), uważaj, aby nie używać go wewnątrz pętli i upewnij się, że nie można wstawić funkcji, jeśli istnieje szansa, że ​​zostanie wywołana w pętli innej funkcji.

Wszyscy już wskazywali na wielką rzecz, jaką jest potencjalne niezdefiniowane zachowanie po przepełnieniu stosu, ale powinienem wspomnieć, że środowisko Windows ma świetny mechanizm do wychwytywania tego za pomocą wyjątków strukturalnych (SEH) i ochrony stron. Ponieważ stos rośnie tylko w razie potrzeby, strony ochronne znajdują się w nieprzydzielonych obszarach. Jeśli przydzielisz do nich (poprzez przepełnienie stosu), zgłoszony zostanie wyjątek.

Możesz złapać ten wyjątek SEH i wywołać _resetstkoflw, aby zresetować stos i kontynuować na wesołej drodze. Nie jest idealny, ale jest to kolejny mechanizm pozwalający przynajmniej wiedzieć, że coś poszło nie tak, gdy coś trafi w wentylator. * nix może mieć coś podobnego, czego nie jestem świadomy.

Zalecam ograniczenie maksymalnego rozmiaru alokacji poprzez zawinięcie alokacji i śledzenie jej wewnętrznie. Jeśli naprawdę nie lubisz tego, możesz rzucić niektórymi wartownikami na górze swojej funkcji, aby śledzić wszelkie alokacje przydziałów w zakresie funkcji i sprawdzić, czy jest to poprawne względem maksymalnej dozwolonej kwoty dla twojego projektu.

Oprócz tego, że nie zezwala się na wycieki pamięci, alokacja nie powoduje fragmentacji pamięci, co jest dość ważne. Nie sądzę, że alga jest złą praktyką, jeśli używasz go inteligentnie, co zasadniczo jest prawdą we wszystkim. :-)

alokacja () jest ładna i wydajna ... ale jest również głęboko zepsuta.

• zepsuty zakres działania (zakres funkcji zamiast zakresu bloku)
• używanie niespójnego wskaźnika nie powinno być zwolnione, ponieważ wskaźnik wyskakujący z malloc ( przydzielania () nie powinien być uwolniony, odtąd musisz śledzić, skąd pochodzą twoje wskaźniki do free () tylko tych, które otrzymałeś przy pomocy malloc () )
• złe zachowanie, gdy używasz również inlinizacji (zakres czasami przechodzi do funkcji dzwoniącego, w zależności od tego, czy odbiorca jest wstawiony, czy nie).
• brak kontroli granicy stosu
• niezdefiniowane zachowanie w przypadku awarii (nie zwraca NULL jak malloc ... a co oznacza awaria, ponieważ i tak nie sprawdza granic stosu ...)
• nie jest standardem

W większości przypadków można go zastąpić przy użyciu zmiennych lokalnych i wielkości głównej. Jeśli jest używany do dużych obiektów, umieszczenie ich na stosie jest zwykle bezpieczniejszym pomysłem.

Jeśli naprawdę potrzebujesz C, możesz użyć VLA (brak vla w C ++, szkoda). Są o wiele lepsze niż przydziała () pod względem zachowania zakresu i spójności. Widzę, że VLA jest rodzajem poprawnie wykonanej metody splita () .

Oczywiście lokalna struktura lub tablica wykorzystująca większość potrzebnej przestrzeni jest jeszcze lepsza, a jeśli nie masz takiej alokacji sterty głównej za pomocą zwykłego malloc (), prawdopodobnie jest to rozsądne. Nie widzę żadnego rozsądnego przypadku użycia, w którym naprawdę potrzebujesz albo funkcji Almla (), albo VLA.

Dlatego:

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

Nie żeby ktokolwiek napisał ten kod, ale argument wielkości, do którego przekazujesz, allocaprawie na pewno pochodzi z jakiegoś rodzaju danych wejściowych, które mogą złośliwie dążyć do doprowadzenia twojego programu do allocaczegoś takiego. W końcu, jeśli rozmiar nie jest oparty na danych wejściowych lub nie ma możliwości być duży, to dlaczego nie zadeklarowałeś małego lokalnego bufora o stałej wielkości?

Praktycznie cały kod używający allocai / lub C99 vlas ma poważne błędy, które doprowadzą do awarii (jeśli masz szczęście) lub kompromisu uprzywilejowania (jeśli nie masz szczęścia).

Nie sądzę, żeby ktokolwiek o tym wspominał: użycie alokacji w funkcji utrudni lub wyłączy niektóre optymalizacje, które mogłyby zostać zastosowane w funkcji, ponieważ kompilator nie może znać rozmiaru ramki stosu funkcji.

Na przykład częstą optymalizacją kompilatorów C jest wyeliminowanie użycia wskaźnika ramki w funkcji, dostęp do ramki jest wykonywany względem wskaźnika stosu; więc jest jeszcze jeden rejestr do ogólnego użytku. Ale jeśli wywoływany jest alokacja w obrębie funkcji, różnica między sp i fp będzie nieznana dla części funkcji, więc tej optymalizacji nie można wykonać.

Biorąc pod uwagę rzadkość jego użycia i jego zacieniony status jako funkcji standardowej, projektanci kompilatorów całkiem prawdopodobnie wyłączają jakąkolwiek optymalizację, która mogłaby powodować problemy z przydziałem, gdyby zajęło więcej niż trochę wysiłku, aby działał z przydziałem.

AKTUALIZACJA: Ponieważ lokalne tablice o zmiennej długości zostały dodane do C, a ponieważ stanowią one bardzo podobne problemy z generowaniem kodu w kompilatorze jak przydział, widzę, że „rzadkość użycia i zacieniony status” nie ma zastosowania do mechanizmu bazowego; ale nadal podejrzewałbym, że użycie alokacji lub VLA ma tendencję do kompromitowania generowania kodu w funkcji, która ich używa. Z radością powitam wszelkie opinie projektantów kompilatorów.

Jedną z pułapek allocajest to, że longjmpto przewija.

To znaczy, jeśli zapiszesz kontekst setjmp, a następnie allocatrochę pamięci, a następnie longjmpdo kontekstu, możesz stracić allocapamięć. Wskaźnik stosu powrócił tam, gdzie był, więc pamięć nie jest już zarezerwowana; wywołanie funkcji lub wykonanie innej allocaspowoduje zatarcie oryginału alloca.

Aby wyjaśnić, konkretnie mam na myśli sytuację, w której longjmpnie wraca z funkcji, w której allocamiała miejsce! Zamiast tego funkcja zapisuje kontekst za pomocą setjmp; następnie przydziela pamięć allocai na końcu odbywa się longjmp w tym kontekście. allocaPamięć tej funkcji nie jest całkowicie uwolniona; tylko cała pamięć przydzielona od czasu setjmp. Oczywiście mówię o zaobserwowanym zachowaniu; żaden taki wymóg nie jest udokumentowany w stosunku do żadnego, allocaktóry znam.

Dokumentacja koncentruje się zwykle na koncepcji, że allocapamięć jest powiązana z aktywacją funkcji , a nie z żadnym blokiem; że wiele wywołań po allocaprostu pobiera więcej pamięci stosu, która jest zwalniana po zakończeniu funkcji. Skąd; pamięć jest faktycznie związana z kontekstem procedury. Kiedy kontekst jest przywracany longjmp, to samo dotyczy allocastanu poprzedniego . Jest to konsekwencja użycia samego rejestru wskaźników stosu do alokacji, a także (koniecznie) zapisania i przywrócenia w jmp_buf.

Nawiasem mówiąc, to, jeśli działa w ten sposób, zapewnia wiarygodny mechanizm celowego uwalniania pamięci, która została przydzielona alloca.

Natknąłem się na to jako główną przyczynę błędu.

Miejsce, w którym alloca()jest szczególnie niebezpieczne niż malloc()jądro - jądro typowego systemu operacyjnego ma miejsce na stos o stałej wielkości, zakodowane na stałe w jednym z jego nagłówków; nie jest tak elastyczny jak stos aplikacji. Wywołanie alloca()z nieuzasadnionym rozmiarem może spowodować awarię jądra. Niektóre kompilatory ostrzegają przed użyciem alloca()(a nawet VLA) pod pewnymi opcjami, które powinny być włączone podczas kompilacji kodu jądra - tutaj lepiej jest alokować pamięć na stercie, która nie jest ustalona przez zakodowany na stałe limit.

Jeśli przypadkowo napiszesz poza blok przydzielony alloca(na przykład z powodu przepełnienia bufora), nadpiszesz adres zwrotny swojej funkcji, ponieważ ten znajduje się „nad” na stosie, tj. Po przydzielonym bloku.

Konsekwencje tego są dwojakie:

1. Program zawiesi się w spektakularny sposób i nie będzie możliwe określenie, dlaczego lub gdzie się zawiesił (stos najprawdopodobniej odwija ​​się do losowego adresu z powodu nadpisanego wskaźnika ramki).

2. Powoduje to, że przepełnienie bufora jest wielokrotnie bardziej niebezpieczne, ponieważ złośliwy użytkownik może stworzyć specjalny ładunek, który zostałby umieszczony na stosie i dlatego może zostać wykonany.

W przeciwieństwie do tego, jeśli piszesz poza blokiem na stercie, „po prostu” dostajesz uszkodzenie stosu. Program prawdopodobnie zostanie nieoczekiwanie zakończony, ale odpowiednio odwija ​​stos, zmniejszając w ten sposób ryzyko wykonania złośliwego kodu.

Niestety w alloca()prawie tak niesamowitym tcc brakuje naprawdę wspaniałego . Gcc ma alloca().

1. Sieje ziarno własnego zniszczenia. Z powrotem jako destruktor.

2. Podobnie malloc()jak zwraca nieprawidłowy wskaźnik w przypadku awarii, co spowoduje segfault w nowoczesnych systemach z MMU (i mam nadzieję, że zrestartują te bez).

3. W przeciwieństwie do zmiennych automatycznych można określić rozmiar w czasie wykonywania.

Działa dobrze z rekurencją. Możesz użyć zmiennych statycznych, aby osiągnąć coś podobnego do rekurencji ogona i użyć tylko kilku innych informacji do każdej iteracji.

Jeśli pchniesz zbyt głęboko, masz pewność segfault (jeśli masz MMU).

Zauważ, że malloc()nie oferuje nic więcej, ponieważ zwraca NULL (który również segfault, jeśli zostanie przypisany), gdy w systemie zabraknie pamięci. Tj. Wszystko, co możesz zrobić, to zwolnienie za kaucją lub po prostu spróbować przypisać to w jakikolwiek sposób.

Aby użyć malloc(), używam globałów i przypisuję im NULL. Jeśli wskaźnik nie ma wartości NULL, zwalniam go przed użyciem malloc().

Możesz również użyć realloc()jako ogólnego przypadku, jeśli chcesz skopiować istniejące dane. Musisz sprawdzić wskaźnik przed sprawdzeniem, czy zamierzasz skopiować lub połączyć po realloc().

3.2.5.2 Zalety przydziału

Procesy mają tylko ograniczoną ilość dostępnego miejsca na stosie - znacznie mniej niż ilość dostępnej pamięci malloc().

Korzystając z niej alloca(), znacznie zwiększasz swoje szanse na błąd przepełnienia stosu (jeśli masz szczęście lub niewytłumaczalną awarię, jeśli nie masz).

Niezbyt ładne, ale jeśli wydajność naprawdę ma znaczenie, możesz wstępnie przydzielić trochę miejsca na stosie.

Jeśli masz już maksymalny rozmiar bloku pamięci, którego potrzebujesz i chcesz zachować kontrolę przepełnienia, możesz zrobić coś takiego:

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

    (...)
}

Funkcja alokacji jest świetna i wszyscy naysayers po prostu rozpowszechniają FUD.

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

Array i parray są DOKŁADNIE takie same, przy DOKŁADNIE takich samych ryzykach. Mówienie, że jeden jest lepszy od drugiego, jest wyborem syntaktycznym, a nie technicznym.

Jeśli chodzi o wybór zmiennych stosu względem zmiennych stosu, istnieje wiele zalet w stosunku do długo działających programów używających stosu ponad stosu dla zmiennych o czasie życia w zakresie. Unikasz fragmentacji sterty i możesz uniknąć powiększania przestrzeni procesu za pomocą nieużywanej (nieużywalnej) przestrzeni sterty. Nie musisz go sprzątać. Możesz kontrolować alokację stosu w procesie.

Dlaczego to takie złe?

W rzeczywistości nie można zagwarantować, że skorzysta ze stosu. Rzeczywiście, implementacja alokacji gcc-2.95 przydziela pamięć ze sterty za pomocą samego malloc. Również implementacja jest błędna, może prowadzić do wycieku pamięci i nieoczekiwanego zachowania, jeśli wywołasz ją w bloku z dalszym użyciem goto. Nie, żeby powiedzieć, że nigdy nie powinieneś go używać, ale czasami alokacja prowadzi do większych kosztów ogólnych, niż to, co uwalnia.

IMHO, alokacja jest uważana za złą praktykę, ponieważ wszyscy boją się wyczerpać limit wielkości stosu.

Nauczyłem się wiele, czytając ten wątek i kilka innych linków:

• /unix/63742/what-is-automatic-stack-expansion
• Limit przydziału stosu dla programów na 32-bitowym komputerze z systemem Linux
• ulimit -s

Korzystam z alokacji głównie po to, aby moje zwykłe pliki C były kompilowane na msvc i gcc bez żadnych zmian, stylu C89, bez #ifdef _MSC_VER itp.

Dziękuję Ci ! Ten wątek zmusił mnie do zarejestrowania się na tej stronie :)

Moim zdaniem, diva (), jeśli jest dostępna, powinna być używana tylko w ograniczony sposób. Bardzo podobna do użycia „goto”, całkiem spora liczba rozsądnych ludzi wykazuje dużą niechęć nie tylko do używania, ale także istnienia, funkcji diva ().

W przypadku użycia wbudowanego, gdy znany jest rozmiar stosu i można nałożyć ograniczenia poprzez konwencję i analizę wielkości alokacji, i gdzie kompilatora nie można zaktualizować do obsługi C99 +, użycie alga () jest w porządku i byłem znany z tego, że go używa.

Jeśli są dostępne, licencje VLA mogą mieć pewne zalety w stosunku do metody przydzielania (): kompilator może generować kontrole limitu stosu, które wychwycą dostęp poza granicami, gdy używany jest dostęp do stylu tablicy (nie wiem, czy którykolwiek kompilator to robi, ale może do zrobienia), a analiza kodu może ustalić, czy wyrażenia dostępu do tablicy są odpowiednio ograniczone. Należy pamiętać, że w niektórych środowiskach programowania, takich jak motoryzacja, sprzęt medyczny i awionika, analizy tej należy dokonać nawet dla tablic o stałych rozmiarach, zarówno automatycznych (na stosie), jak i przydziału statycznego (globalnego lub lokalnego).

W architekturach, które przechowują zarówno stos danych, jak i adresy zwrotne / wskaźniki ramek na stosie (z tego co wiem, to wszystko z nich), każda zmienna przydzielona do stosu może być niebezpieczna, ponieważ można pobrać adres zmiennej, a niesprawdzone wartości wejściowe mogą pozwolić wszelkiego rodzaju psoty.

Przenośność jest mniej istotna w zagnieżdżonej przestrzeni, ale jest to dobry argument przeciwko używaniu funkcji splita () poza ściśle kontrolowanymi okolicznościami.

Poza zagnieżdżoną przestrzenią, w celu zwiększenia wydajności, użyłem przydziałów () głównie w funkcjach rejestrowania i formatowania oraz w nierekurencyjnym skanerze leksykalnym, w którym struktury tymczasowe (przydzielane przy użyciu przydziału () są tworzone podczas tokenizacji i klasyfikacji, a następnie trwałe obiekt (przydzielony przez malloc ()) jest zapełniany przed powrotem funkcji. Użycie funkcji replacea () dla mniejszych struktur tymczasowych znacznie zmniejsza fragmentację, gdy przydzielany jest obiekt trwały.

Większość odpowiedzi tutaj w dużej mierze nie ma sensu: istnieje powód, dla którego używanie _alloca()jest potencjalnie gorsze niż zwykłe przechowywanie dużych obiektów na stosie.

Główna różnica między automatycznym przechowywaniem _alloca()polega na tym, że ten drugi ma dodatkowy (poważny) problem: przydzielony blok nie jest kontrolowany przez kompilator , więc nie ma możliwości, aby kompilator zoptymalizował go lub poddał recyklingowi.

Porównać:

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

z:

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

Problem z tym ostatnim powinien być oczywisty.

Nie sądzę, żeby ktokolwiek o tym wspominał, ale Alfa ma również poważne problemy z bezpieczeństwem, niekoniecznie związane z Malloc (chociaż problemy te pojawiają się także w przypadku tablic opartych na stosie, dynamicznych lub nie). Ponieważ pamięć jest przydzielana na stosie, przepełnienia / niedopełnienia bufora mają znacznie poważniejsze konsekwencje niż w przypadku samego malloc.

W szczególności adres zwrotny funkcji jest przechowywany na stosie. Jeśli ta wartość zostanie uszkodzona, twój kod może przejść do dowolnego wykonywalnego regionu pamięci. Kompilatory bardzo się starają, aby to utrudnić (w szczególności przez losowy układ adresów). Jest to jednak wyraźnie gorsze niż zwykłe przepełnienie stosu, ponieważ najlepszym przypadkiem jest SEGFAULT, jeśli zwracana wartość jest uszkodzona, ale może również zacząć wykonywać losowy fragment pamięci lub, w najgorszym przypadku, pewien obszar pamięci, który zagraża bezpieczeństwu twojego programu .