LINUX.ORG.RU

Бред? или это нормально?


0

0

Сейчас подкинули код с вопросом «это нормально?».

int main(int argc, char *argv[]) 
{
    char b[random(100)];
    return 0; 
}

нее, оно компилится и работает.. но что-то у меня нет полной картины в голове каким это макаром происходит b[random(100)]. разве аллоцирование таким образом не должно быть статичным?

Deleted

> нее, оно компилится и работает..

О_О!

zh
()
Ответ на: комментарий от Elverion

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

зыж есть подозрение, что если и есть нужда, то где-то на другой архитектуре.

Deleted
()
Ответ на: комментарий от Elverion

Можно только в Си99.

Полезно для математических операций с массивами и матрицами где большое количество malloc/free портит читаемость кода, скрывая сам алгоритм.

Но использовать (как и многое в Си) надо с осторожностью.

ntp
()
Ответ на: комментарий от Deleted

память на стеке выделяется быстрее, чем на куче
// К.О.

BreadFan ★★
()
Ответ на: комментарий от Deleted

>а что нельзя сразу написать aaa[нужное_число_байт_с_запасом]?

Может не хватить, а так точно хватит, ну или стек переполнится.

Elverion
()
Ответ на: комментарий от Deleted

> а что нельзя сразу написать aaa[нужное_число_байт_с_запасом]?

"640к должно хватить всем"

Очень распространенная ошибка. Рано или поздно получится так, что ваш запас уже давно израсходован и полезут трудно отлавливаемые падения и уязвимости из-за переполнения стека.

ntp
()
Ответ на: комментарий от Deleted

> зачем?

у выделения на стеке помимо скорости и отсутствия блокировок есть ещё очень полезная фишка - автоматическое освобождение после выхода из функции (даже по longjmp). memory leek исключён :)

есть ещё прикольная void* alloca(size_t) :)

ps: есть и минусы - ограниченный размер, а alloca вообще не может проверить есть ещё стек или уже кончился.

Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot

> у выделения на стеке помимо скорости и отсутствия блокировок есть ещё очень полезная фишка - автоматическое освобождение после выхода из функции (даже по longjmp). memory leek исключён :)

зато появляется новый чудный Друг - stack overflow :)

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от Deleted

> чревато сегфолтом, если не будет контролировать объем выделения памяти (ведь оно в стек выделяет)

Верно. На этот случай придумано setrlimit(RLIMIT_STACK), но злоупотреблять, естественно, не следует.

const86 ★★★★★
()
Ответ на: комментарий от klalafuda

>ходить на gcc.gnu.org уже не модно :-?

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

зыж за что с тебя звезды снимают? ;) кому ж ты так солишь? :)

Deleted
()
Ответ на: комментарий от ntp

>Очень распространенная ошибка. Рано или поздно получится так, что ваш запас уже давно израсходован и полезут трудно отлавливаемые падения и уязвимости из-за переполнения стека.

можно просто проверять израсходован запас или нет, если израсходован, то ругаться и сразу будет все понятно.

mono ★★★★★
()
Ответ на: комментарий от Deleted

>а что нельзя сразу написать aaa[нужное_число_байт_с_запасом]?

Нужное число с запасом - это таймер на динамите (ц) Саттер

Absurd ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.