> От переполнения стэка ни один код не защищён. И ни один код
> не защищён от исчерпания памяти.Если я статически пишу uint8_t arr[10]; я имею основания полагать что это будет работать даже на микроконтроллере с склерозом вместо памяти, и если этот код вообще запустился то скорее всего работает до упора.
Есди я динамически аллоцирую память и ее ен было - то там по крайней мере вернут ошибку и я могу ее прочекать. И что-то сделать по этому поводу.
Но если это будет
void func1 (uint32_t n) {
uint8_t arr[n]; // VLA!
// do something with arr[] here
}
...и вызывать func1(10); func1(100); func1(100500); ... то я вообще не знаю на каком n оно грохнется. И нет никаких способов это узнать, кроме как грохнувшись. Если *alloc еще фэйлить хотя-бы могут, то тут о фэйле узнаем только путем краха/системного факапа. Круто, да? Особенно в кернеле. Вы же будете очень рады что кернел в панику $%^нется без предупрежления, да?! Вместо фэйла внутренних операций, retry выделения памяти и прочих глупостей.
>> Ибо uint8_t arr[n] работать ну вот не обязано если n == 100500000.
> При таком n, даже если всё в куче будет, на большинстве компов грохнется.
В случае динамической аллокации я как бы могу проверить успех операции. А тут сразу крах в репу, обработать нехватку памяти вообще совсем никак нельзя. И поскольку это рантайм параметр - получается код который очень ненадежный, скажем так, и может просто грубо навернуться если параметр неудачный. Без какой либо адекватной обработки этого вообще.
> И всё тут. И там и там надо ограничивать разрешённые значения N.
Просто крах без предупреждения, в рантайме, без возможности это обработать - может и ок для питоняш, но в системном яп - такое себе.
