История изменений

Все _builtin* функции - это внутренняя кухня компилятора gcc, glibc тут не причем, если только это не умышленный хак, как для sparc

Вы абсолютно правы. Но тут есть ряд моментов.

Во-первых, если Вы внимательно прочтёте Максимально допустимый размер массива на стеке? (комментарий) , то я там явно сказал следующее:

Пусть лучше этим занимается внутренняя реализация gcc.

Именно так и здесь Вы абсолютно правы. К тому же я читал вот этот документец и в курсе что ф-ий __builtin_alloca ни фига не одна. И что это не glibc.

Во-вторых, если бы я сразу сказал этому… инвалиду головного мозга о том, что это gcc, то мне бы пришлось грепать исходники gcc (они у меня есть, я гентарь), но Господь свидетель, мне так лениво это делать, что проще линкануть патч для одной из архитектур из libc, чем убеждать птушника в том, что он неуч и бестолочь. А то начнётся – «а покажи мне в исходниках gcc», «а у меня другие исходники и там это в другом месте», «а я вааще не нашёл и искать не собирался»… ну и прочая пурга, коей знаменит сей достославный клован. Зачем мне это? =))) Я просто показал на одной из реализаций (на весьма частном случае) что эта реализация не макрос. Что это именно функция. Получил искомое и угомонился. =))) Я, но не…

Где говорится, что это хак специально для SunOS libc, и не нужен при использовании gcc.

И это правда. Именно по этой причине я линканул публично доступный код, который показывает что alloca()/__builtin_alloca() это ни фига ни разу не макрос. Даже не макрос с возвращаемым значением. Т.е., по сути, я просто потыкал палочкой и отошёл спокойно в сторонку. Теперь сижу, курю, пью кофиёк, сваренный в турке и наслаждаюсь новогодним фейерверком в исполнении… =)))

«Программисты С» это довольно… скажем так, «тонкие» люди, умеющие создавать надёжные и довольно изысканные (если не сказать извращённые) реализации. И вовсе не нужно всё делать самому, можно развлечься за чужой счёт. Даже не столько «можно», сколько «нужно». Как видите, вот этот метод indirect control, косвенного управления, работает на практике. Так не только с кодом, так и с любым программируемым животным типа… =)))

alloca - это полноценная функция, можно даже адрес взять.

Да. Et tu, Brutus? =)))

Все _builtin* функции - это внутренняя кухня компилятора gcc, glibc тут не причем, если только это не умышленный хак, как для sparc

Вы абсолютно правы. Но тут есть ряд моментов.

Во-первых, если Вы внимательно прочтёте Максимально допустимый размер массива на стеке? (комментарий) , то я там явно сказал следующее:

Пусть лучше этим занимается внутренняя реализация gcc.

Именно так и здесь Вы абсолютно правы. К тому же я читал вот этот документец и в курсе что ф-ий __builtin_alloca ни фига не одна. И что это не glibc.

Во-вторых, если бы я сразу сказал этому… инвалиду головного мозга о том, что это gcc, то мне бы пришлось грепать исходники gcc (они у меня есть, я гентарь), но Господь свидетель, мне так лениво это делать, что проще линкануть патч для одной из архитектур из libc, чем убеждать птушника в том, что он неуч и бестолочь. А то начнётся – «а покажи мне в исходниках gcc», «а у меня другие исходники и там это в другом месте», «а я вааще не нашёл и искать не собирался»… ну и прочая пурга, коей знаменит сей достославный клован. Зачем мне это? =)))

Где говорится, что это хак специально для SunOS libc, и не нужен при использовании gcc.

И это правда. Именно по этой причине я линканул публично доступный код, который показывает что alloca()/__builtin_alloca() это ни фига ни разу не макрос. Даже не макрос с возвращаемым значением. Т.е., по сути, я просто потыкал палочкой и отошёл спокойно в сторонку. Теперь сижу, курю, пью кофиёк, сваренный в турке и наслаждаюсь новогодним фейерверком в исполнении… =)))

«Программисты С» это довольно… скажем так, «тонкие» люди, умеющие создавать надёжные и довольно изысканные (если не сказать извращённые) реализации. И вовсе не нужно всё делать самому, можно развлечься за чужой счёт. Даже не столько «можно», сколько «нужно». Как видите, вот этот метод indirect control, косвенного управления, работает на практике. Так не только с кодом, так и с любым программируемым животным типа… =)))

alloca - это полноценная функция, можно даже адрес взять.

Да. Et tu, Brutus? =)))

Все _builtin* функции - это внутренняя кухня компилятора gcc, glibc тут не причем, если только это не умышленный хак, как для sparc

Вы абсолютно правы. Но тут есть ряд моментов.

Во-первых, если Вы внимательно прочтёте Максимально допустимый размер массива на стеке? (комментарий) , то я там явно сказал следующее:

Пусть лучше этим занимается внутренняя реализация gcc.

Именно так и здесь Вы абсолютно правы. К тому же я читал вот этот документец и в курсе что ф-ий __builtin_alloca ни фига не одна. И что это не glibc.

Во-вторых, если бы я сразу сказал этому… инвалиду головного мозга о том, что это gcc, то мне бы пришлось грепать исходники gcc (они у меня есть, я гентарь), но Господь свидетель, мне так лениво это делать, что проще линкануть патч для одной из архитектур из libc, чем убеждать птушника в том, что он неуч и бестолочь. А то начнётся – «а покажи мне в исходниках gcc», «а у меня другие исходники и там это в другом месте», «а я вааще не нашёл и искать не собирался»… ну и прочая пурга, коей знаменит сей достославный клован. Зачем мне это? =)))

Где говорится, что это хак специально для SunOS libc, и не нужен при использовании gcc.

И это правда. Именно по этой причине я линканул публично доступный код, который показывает что alloca()/__builtin_alloca() это ни фига ни разу не макрос. Даже не макрос с возвращаемым значением. Т.е., по сути, я просто потыкал палочкой и отошёл спокойно в сторонку. Теперь сижу, курю, пью кофиёк, сваренный в турке и наслаждаюсь новогодним фейерверком в исполнении… =)))

alloca - это полноценная функция, можно даже адрес взять. Да. Et tu, Brutus? =)))