>[оверквотинг удален]
>>> в массив загружу? По крайней мере так любят утверждать некоторые фанаты.
>> Скопирую контекст из сообщений, на которые я отвечал:
>>>> Или спроси по приколу почему цикл
>>>> никогда не вызовет переполнение стека в отличии от рекурсии
>>> Слушай, гениально. Всё, у меня на следующей неделе собеседование.
>>> Я обязательно спрошу. Классный вопрос. Спасибо.
> А, вот оно что. Спасибо что контекст вернул, тут иногда его трудно
> отследить.
> Что-ж, замечание достойное, принимается. Но поскольку мы тут стали играть в задачки
> со звёздочками твой пример не сработал. Давай подумаем почему?А зачем думать? У меня переполняет. Достаточно, что бы опровергнуть "никогда не вызовет переполнение". Выполнил ли кто-то ulimit -s 500000000, задал размер стека в заголовке PE образа, или же при адресации проскочили сторожевую страницу и программа завершилась "без ошибок" -- важно не это, а что она обязательно где-то упадёт. Просто изменят тип счётчика на "правильный" и она упадёт.
Она упадёт даже без цикла и с константным размером массива, потому что где-то WCHAR_MAX всего 65535, а где-то нет.
Она вообще просто так возьмёт и упадёт, потому что... смотрите внимательно за руками, что бы я не смухлевал:
Like all other architectures, x86_64 has a kernel stack for every
active thread. These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big.
https://www.kernel.org/doc/Documentation/x86/kernel-stacks
arch/x86/include/asm/page_32_types.h:#define THREAD_SIZE_ORDER 1
arch/x86/include/asm/page_32_types.h:#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)
arch/x86/include/asm/page_64_types.h:#define THREAD_SIZE_ORDER (2 + KASAN_STACK_ORDER)
arch/x86/include/asm/page_64_types.h:#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
но пока везёт и "у меня на виртуалке всё работает!"