А Царь-то ненастоящий! =)))

Да, вероятно что-то навроде crt0(оно не объектником ли отдельным идёт?)

Не. Эти файлы crt0, crt1, … включены в libc. Это относится к glibc/newlib/uClibc/dietC Например

А царь-то, да, уже не царь - чёт его уже и на сишных темах с говном смешивают за пару минут

Самое смешное что один мой коллега в полу-шутку спросил меня уж не я ли под этим ником «выступаю» на лорчике… Ибо да, я – сишник и матерюсь просто по-армейски изысканно и виртуозно. Но нет. Это не я. Точно. =)))

Это эффект присутствия настоящего сишника, когда поддельный сишник вскрывается до задницы от одного присутствия. =)))

включены в libc

ok

Ибо да, я – сишник

Основной профиль - MK? Или ядро?(если не секрет, конечно)

В общем, мне лень с отребьем спорить, да и оно обделалось всё же - я тебе накидал poc. https://godbolt.org/z/zecH7D - как сделать бесконечный стек и как уменьшить его размер, если он он засран на всю память.

Да ну не, у Вас стиль комментов совершенно другой. Не царский:-)

Не. Эти файлы crt0, crt1, … включены в libc. Это относится к glibc/newlib/uClibc/dietC Например

Всё же не мог оставить без ответа этот высер. В целом, здесь можно зафиксировать ещё одно свидетельство того, что эта обезьяна - обезьяна.

Оно ничего не знает, ничего не понимает. Это отребье просто ретранслирует какую-то херню увиденную в интернете, причём даже это оно делать не может. Оно просто кидает рандомные пасты/ссылки из гугла по ключевым словам.

Дак вот, говно, crt никакого отношения к libc не имеет. Это сишный рантайм уникальный для компилятора. Никто ни в каком стандарте, обезьяна, оно не описано.

То, что, в каком-то говне пытаются уйти от gcc-рантайма и впихнуть своё - это не значит, что это говно стало частью си.

Самое смешное что один мой коллега в полу-шутку спросил меня уж не я ли под этим ником «выступаю» на лорчике… Ибо да, я – сишник и матерюсь просто по-армейски изысканно и виртуозно. Но нет. Это не я. Точно. =)))

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

Да не секрет... Какой тут секрет?

Основной профиль - MK? Или ядро?(если не секрет, конечно)

Есть всё. Помаленьку. И ядро и МК (вот прямо сейчас, я не только этого недоделка по форуму ссаными тапками гоняю, я пилю код для 1892ВМ10Я, да с DSP в том числе), есть простой «приклад», есть информбезопасность (кто-то побежит за skapy питоньей если надо пакет скрафтить, я же хмыкну и достану libnet), есть демоны, GTK+ вот тоже люблю при необходимости. СУБД, так те, если себя уважают, то имеют доступ из С. … Много всего почуть-чуть. Даже вебня.

Просто, люди ищут себе «инструмент под задачу», а я в пределах одного инструментального стека нахожу себе варианты решений. Да, учится постоянно приходится, но ни кто и не обещал что будет легко.

Вот поэтому я и не спорю. С отребьем.

Маны идите курить, любезнейший. Вам ничего ненадо «писать», в Вашем случае это неблагодарная трата времени. Вам нужно читать. И много.

ok, ясно

А я стебусь, если честно...

По временам. Мне по приколу без мата объодиться, я из «вежливых», правда, там тоже мат… Вежливый, на «Вы», но всё же. =)))

Да и потом – этот глупенький, он от души потешен. =)

ok

Не ок. Тебя обманули.

Основной профиль - MK?

Мойка полов.

Или ядро?(если не секрет, конечно)

О боже да, обезьяна которая не знает про madvise, которая не знает про builtin и прочую самую примитивную системную базу - действительно занимается ядром.

Я то думаю - как это бездарное отребье может кому-то внушить, что оно не поломой. А вот как оно оказывается. Как же просто вас поиметь.

"Имелка-то" хоть отросла? =)))

Как же просто вас поиметь.

А то я сейчас опять про TI cc1310 помяну и «имелка» опять завянет… Впрочем, это и хорошо. И так население растёт при константе разума на планете… Ещё тут всякие размножаться будут. А потом мы удивляемся – откуда Греты Тунберги берутся… =)))

Падаль, быстро же ты обделалась.

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

Ну что ж поделать, легко так легко. Что ж тебе бомбит-то так с этого?

Мне опять в спеку носом Вас тыкать? =)))

А то я сейчас опять про amd64 помяну

На процессор? Эх и глубоко же я Вам в тот раз «задвинул», не рассчитал маленько, если по сию пору вспоминается. Вы уж извините. =)))

Меня не бомбит. В любом случае говно оно говно.

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

Подобное позорное отребье позорило и позорит сишку. Я уже проходился по подобным клоунам недавно и они все разбежались. Этот, наверное, хорошо маскировался и не кукарекал. А потом вылез.

https://www.linux.org.ru/search.jsp?q=%D1%86%D0%B0%D1%80%D1%8C&range=ALL&interval=ALL&user=Moisha_Liberman&_usertopic=on&sort=DATE_OLD_TO_NEW&section= - ну да, он шифровался.

Я в этом даже не сомневался. Потом я как-то его задел, когда он нёс херню. Мне неважно кто несёт херню. Я не вылизываю жопу кому-то за то, что он сишник или не сишник - мне насрать. Если будет адекватный растовик - я буду его хвалить.

Ну вот я его потрогал - он обозлился и теперь пытается мстить.

На процессор. Эх и глубоко же я Вам в тот раз «задвинул», не рассчитал маленько, если по сию пору вспоминается. Вы уж извините. =)))

Не всегда нужно колесо заново придумывать. ;)

Но это же так интересно!

Прямо задумался, как бы я стал такой менеджер общего назначения ваять… Понятно что он на умных указателях, которые шаблоны. В указателе сам пойнтер (для скорости) и информация о записи в таблице. Сразу встроенный подсчет числа ссылок, сборка мусора, все дела. Тогда free проходит мгновенно - запись по пойнтеру искать не надо, просто перекинуть флажок.

Аллоцирование чуть сложнее, но можно единожды использованные записи группировать по размеру (типовым размерам), тогда думать придется только если нет подходящей свободной записи. Отдельным вопросом стоит дефрагментация и обеспечение локальности данных, это наверное самое сложное.

В общем прямо захотелось сделать, но надо сначала почитать теорию. Увы сейчас на это времени вообще нет, гранит науки требует долбления…

Прямо задумался, как бы я стал

Мечтать не вредно, это да

Понятно что он на умных указателях … Тогда free проходит мгновенно

ЛОЛ, но кроме как мечтать, нужно ещё от реальности не отрываться

Фенечке с двумя списками занятых и свободных элементов уже ХЗ сколько десятков лет. По факту это простейший менеджер памяти заточенный под единственый тип данных, и да - перебрасывание элемента из списка в список требует переписывания нескольких пойнтеров и не требует вообще никаких операций поиска. Можно считать что это мгновенно.

То есть блоки не сливаются и внешняя фрагментация монотонно растёт? И про потокобезопасность тоже не забудь

Поскольку речь идет о единственном типе данных, то фрагментация не важна. Вот с локальностью данных будет хуже, но это общая проблема.

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

Есть уже готовые примеры.

Их можно взять и развивать. Вот для С++, например с ведром «теории» в комплекте, если чё.

Вот ещё, под fixed-size objects

Так-то, тыщщи их. =)

речь идет о единственном типе данных

Не разглядел сразу. Тебе ж вроде массив нужен(т. е. список с последовательным распределением памяти) заранее не известного размера? На пуле затратно выйдет, в общем случае.

А про thread-local данные - мерять надо под конкретной нагрузкой. Все же аллокатор из glibc весьма хорош

Спасибо, как соберусь такое велосипедить - почитаю;-)

Ну мне в идеале нужен менеджер общего назначения, да;-) Что бы вообще не думать об этой фигне.

Для текущей задачи я прикинул что к чему и выкрутился через std::vector.

А так я подобные штуки делал с блочным (постраничным) выделением, даже для вектора нормально выходит.

Ну так потому он и Царь. Ивана Васильевича не смотрел?

Смотрел. =)

Поэтому цитату из него и вспомнил.

Блин, не могу, прошу прощения, не удержусь… =)))

Этот… умишком скорбный, конечно бывает полезен нашему сишному делу и потешен, когда он несёт огонь истинных знаний всяким гошникам, растовцам и прочим джаваскрипто-пыхопыхерам с питонистами. Но когда он предерзновенно отказывается есть манную кашу маны читать, то тут волей-неволей приходится вмешиваться. Ибо мы же с Вами оба понимаем что нас читают дети, беременные женщины и животные. А тут такой бунт, грех, харам и даже, самую малость, чуточку нарушение кашрута. Маны ему, видете ли, идиотами для идиотов писаны! Приходится, преисполнившись истинно православного смирения, призывать его к порядку, тыкая носом попеременно то в спеки, то в маны, щедро сдабривая это всё безобразие кодом… Ибо подумают же люди всякое! =)))

Нефиг ересь отказа от чтения манов разводить, короче. =)))

Хотите насмешу до колик? =)))

Для текущей задачи я прикинул что к чему и выкрутился через std::vector.

Знаете как потенциально может выглядеть реализация alloca() для семейства Intel?

Всего-навсего:

sub esp, <desired_size_in_bytes>

Причина проста – у нас в процессоре есть регистр, отвечающий за стек. С ним и работаем. Вычитаем из его текущего значения нужный нам размер (в байтах). Правда, тут всё не так просто как оно кажется. Тут есть ряд подводных камней, начиная от того, что можно таким кодом снести все gcc-оптимизации (например, global register allocation) и кончая тем, что если уж так жёстко начинаем рукоблудить в коде, то надо не забывать о том, что мы тут не одни и надо тогда такой код добавлять во все свои ф-ии. И отслеживать состояние флагов процессора, того же флага знака (SF), потому как если мы внезапно получили отрицательное число, то… то лучше ненадо таких решений. Пусть лучше этим занимается внутренняя реализация gcc.

К чему это я всё? А это такой… лёгкий намёк, если угодно. Смотрите – у Вас std::vector… Может, имеет смысл поискать более экономичные реализации? Я ни в коем разе не настаиваю, просто слегка намекаю. ;)

Никто не выгоняет и не глушит клоунов.

Именно поэтому ты тут и есть достопримечательность.

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

Знаете как потенциально может выглядеть реализация alloca() для семейства Intel?

Обезьяна, а куда делась функция? И чего ты тут заблеял откровения - загуглил что-ли, падаль?

Тут есть ряд подводных камней, начиная от того, что можно таким кодом снести все gcc-оптимизации (например, global register allocation)

Ну собственно, очередные неведомые потоки херни. Падаль, за пруфами побежала.

и кончая тем, что если уж так жёстко начинаем рукоблудить в коде, то надо не забывать о том, что мы тут не одни и надо тогда такой код добавлять во все свои ф-ии.

Чего ты несёшь, падаль? Что это за херня? Что она значит?

И отслеживать состояние флагов процессора, того же флага знака (SF), потому как если мы внезапно получили отрицательное число, то… то лучше ненадо таких решений.

То что, падаль? Зачем их отслеживать, падаль? Нагуглил про флаги и решил повторять все базворды, которые услышал где-то?

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

Ну дак заткнись, падаль, зачем ты что-то кукарекаешь, если ты бездарное говно?

К чему это я всё? А это такой… лёгкий намёк, если угодно. Смотрите – у Вас std::vector… Может, имеет смысл поискать более экономичные реализации? Я ни в коем разе не настаиваю, просто слегка намекаю. ;)

В общем, можно читать как. «я ничего не знаю, я говно. Блею рандомную херню и боюсь кукаренкнуть что-нибудь конкретное, потому как сразу буду опущен».

А зелёному клоуну впарить можно что угодно.

Этот… умишком скорбный, конечно бывает полезен нашему сишному делу и потешен, когда он несёт огонь истинных знаний всяким гошникам, растовцам и прочим джаваскрипто-пыхопыхерам с питонистами.

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

Маны ему, видете ли, идиотами для идиотов писаны!

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

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

Самое интересное тут то, что эта мразь вначале блеяла тупо про первую строчку мана, где написано про стандартные значения и про «советы». Т.е. говно даже не прочитало 10 строчек про нужный флажок.

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

И оказалось, что это никакой не совет и мразь обделалась. Ну это и не удивительно.

А после мразь заткнулась, потому как осознала своё место.

Ну и да, маны нужны домохозяйкам. Хотя говно это даже ман никогда не открывало, что и было доказано выше.

Ман - это вторичный источник. Хотя даже до вторичного он не дотягивает. Он ничего не значит, ничего не определяет. Это аксиома.

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

Про alloca():

Это не функция, очевидно.

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

где же у нас реализована __builtin_alloca (size), как не в glibc в данном случае и как она реализована кроме как внутренняя ф-я библиотеки?

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

Вот, например, для Sparc32:

Теперь читаем ченжлог:

Mon Feb 21 20:47:55 1994  Roland McGrath  (roland@churchy.gnu.ai.mit.edu)

        * sysdeps/sparc/Makefile [gnulib] (routines): Add alloca.
        * sysdeps/sparc/alloca.S: New file; support for SunOS libc's
        `__builtin_alloca' function (never needed with GCC).

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

__builtin_* могут вызываться только как функции, подругому их использвать нельзя, например, получать адрес функции.

Но gcc позволяет, хотя в документации написано, что нельзя. При этом clang - ругается на попытку взятия адреса у __builtin_*.

Но gcc позволяет, хотя в документации написано, что нельзя.

Не позволяет - это локальный хак именно для реализация всяких «стандартных» функции: https://godbolt.org/z/cg8-ri

Он просто вместо builtin"a записывает туда адрес символа в надежде на то, что где-то он определён. Это не взятие адреса builtin"a

Но с аллокой такого не прокатит - её нету в рантайме. Допустим, с тем же memcpy такое прокатит. Скорее всего это сделано для того, что-бы всякие гении начитавшись херни могли получить семантику описанную в мане.

Такая же семантика в сишном инлайне: https://godbolt.org/z/JbWPg5

https://godbolt.org/z/phy84x - если взять настоящий builtin - он правильно ругается.

Но с аллокой такого не прокатит - её нету в рантайме.

Проблемы рантайма. То что alloca для GNUC захардкожено как __builtin_что_то_там, это проблема GNUC.

Развивая тему alloca как функция.

Так как в cdecl очисткой стека занимается вызывающая сторона, то alloca можно реализовать как функцию.

В очередной раз можно заметить то, что как только я эту анинимную мразь смешал с дерьмо - прибежал холоп и зачитстил позор этой мрази. И вариантов тут да. Либо мразь виртуал холопа. либо мразь шлюха холопа. И так происходит всегда.

alloca как функция

Кстати, в libiberty есть «почти портабельная» реализация alloca, хотя для gcc также хардкодит __builtin_alloca.

Да, согласен.

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

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

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

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

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

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

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

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

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

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

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

Крымский царь — собака!

Ну так тут не чему удивляться. Си – язык для неандерталов и говноедов с задержками в развитии и дефектами черепной коробки. Стоит взглянуть только на упоротый main – войд-не-войд, инт не инт. Ещё и компиль ругается, а IDE не может сама заменить на нужный. Да чего там говорить – отсталое отсталым.

Бггг... Вы себы переоцениваете. Честно. =)))

Меня глушат - клоунов нет.

Хотя, хорошо что Вы понимаете что пока Вас нет, клоунов нет тоже.

Но Вы себя переоцениваете в том плане, что Вы думаете что Вас «глушат». На Вас просто одевают намордник и строгий ошейник когда Вы пропускаете приём препаратов, назначенных Вам добрым доктором. Я, правда, жалею что в современной РФ отменена та модель психиатрии, которая была в СССР и называлась «карательной» почему-то, но всем было бы проще, будь Вы надёжно упакованы и под присмотром. =)))

Хотя, с другой стороны, Вы блестяще исполняете роль «полезного идиота» (этот термин пришёл из политики, но уже давно применяется не тольтко там). Как говорится, «этот Вася нам ещё понадобится». =))) Для разборок с упоротыми сторонниками «новых, гибких, мощных, безопасных … бесполезных (ой, палюсь!)» языков, Вы практически идеальны. Даже местами прекрасны в своём бестолковом неведении. Тут срабатывает то, что для общения с упоротыми надо не менее упоротых. Вы же с успехом заменяете целый коллектив (хор!) дол… (ну, Вы меня поняли, да?). Вы просто «человек-оркестр» какой-то… =)))

alloca()/__builtin_alloca() это ни фига ни разу не макрос

Вот не надо мешать в одно месиво alloca и __builtin_alloca. Там в glibc напару с gcc такая хитрая магия на препроцессоре и макросах (включая для асма) напару с недокументированными (не соответствующими документации) хаками, что неизвестно что во что раскрывается и под каким именем потом будет связываться-линковаться.

По документации _builtin* - это неполноценные функции и в коде их можно вызвать только как функции. Но как видно для __builtin_alloca это не так, и почему сделана такая лазейка - можно только догадываться.

А вот тут не совсем согласен. ;)

Вот не надо мешать в одно месиво alloca и __builtin_alloca. Там в glibc напару с gcc такая хитрая магия на препроцессоре и макросах (включая для асма) напару с недокументированными (не соответствующими документации) хаками, что неизвестно что во что раскрывается и под каким именем потом будет связываться-линковаться.

Я выше приводил заголовочник alloc.h, где для случая GNUC явно раскрывается как __builtin_alloca().

По документации _builtin* - это неполноценные функции и в коде их можно вызвать только как функции. Но как видно для __builtin_alloca это не так, и почему сделана такая лазейка - можно только догадываться.

А тут и гадать особо нечего. Функция «как бы есть». Т.е., в сам по себе стандарт С она не включена (прямо же сказано – «This function is not in POSIX.1.»), но она есть и довольно широко применяется на практике. Поэтому её реализацию оставили на компиляторе, а в /usr/include/alloca.h чётко сказали:

/* Allocate a block that will be freed when the calling function exits.  */
extern void *alloca (size_t __size) __THROW;

#ifdef	__GNUC__
# define alloca(size)	__builtin_alloca (size)
#endif /* GCC.  */

Т.е., для случая GNUC реализацию предоставит компилятор, а для остальных случаев берите где хотите (где сможете). Причём, «предоставит компилятор» под ту архитектуру, под которую собираем код. Если под интел, то под интел, если под ARM, то под ARM, т.к. здесь не оговрена единая универсальная реализация и всё может очень сильно зависеть от платформы.

В массе своей внутренняя кухня gcc стандартному пользователю-программисту на фиг двести лет подряд не сдалась, поэтому остальные функции этого семейства __builtin*, даже связанные с __builtin_alloca* по логике в простанство программиста не выводятся, выведена только __builtin_alloca() и всё.

Когда (и если!) alloca() занесут в стандарт, то она плавно перекочует скорее всего имено в стандартную системную либу. Но будет это или нет, это одному Господу и комитету по стандартизации С известно.

__builtin_alloca

Тебе же царь показал (царь - дурак, но он знает много достоверных фактов с пруфами) во что раскрывется __builtin_alloca. Это вполне может быть языковая конструкция для промежуточного языка gcc, не имеющая аналога в исходном языке си. По семантике, alloca - это как бы unique_ptr (из с++), такой семнатики нет в чистом си. Думаю поэтому царь упирается на то, что alloca не может быть функцией.

Нет. Не так.

Что не так? Да всё не так.

Тебе же царь показал (царь - дурак, но он знает много достоверных фактов с пруфами) во что раскрывется __builtin_alloca.

Он ничего не может показать в данном случае. И даже насрать во что она там раскрывается. И как.

Исходный постулат заключался в том, что я сказл что alloca() это функция и сослался на man 3 alloca. Дальше я откомменчу остальное общение, частично поклёванное уважаемым albatros:

мне насрать на то, что там говорит какой-то ман написанный идиотом для идиотов.

Оггада… И именно поэтому man 3 alloca говорит дословно следующее:

The alloca() function

И да, это именно функция, т.к. она имеет возвращаемое значение (макрос тоже может иметь, а может и не иметь). Но alloca() это именно функция:

The alloca() function returns a pointer

Я не вижу ровным счётом ничего из того, что здесь можно и нужно обсуждать дальше. Всё, что при таких раскладах можно «показать», это ор и прыжки местного дурачка. Забавно, да, но смысла тратить времени не вижу. =)))

По семантике, alloca - это как бы unique_ptr (из с++), такой семнатики нет в чистом си. Думаю поэтому царь упирается на то, что alloca не может быть функцией.

По семантике alloca()… Вы вообще не туда смотрите. Я выше приводил приблизительный пример как можно данную ф-ю реализовать на ассемблере. Я показал как данную ф-ю реализовали в патче для спарка32. Вы слишком усложняете процесс.

Ну а почему там оно упирается… Да мне насрать, чесслово. Я не диагност-психиатор. =))) У меня всё проще. Битики-байтики.

P.S. И да – обратите внимане, я не комментирую отдельные комменты. Смысла нет – один чёрт снесут.

царь - дурак

В школу сходил?

Я уже говорил о причинах. Во-первых никто в здравом уме не сделает из аллоки функцию. Данная обезьяна ничего о компиляторах не знает и блеешь херню вида «как ещё можно реализовать, если не через рантайм-говно?». Уровень развития обезьяны - первый класс начальной школы.

Во-вторых, существуют тысячи всяких разных callabi и не везде в принципе можно реализовать аллоку функцией. Да и это будет хак даже там, где можно. Потому как семантика функции в принципе изменится.

alloca

Семантически аллока в сишке нахрен ненужна. Там есть vla и (char[100500]){} - они мощнее.

Но в крестах проблема в том, что время жизни подобных выражений - выражение, а не конец функции. если мы напишем что-то типа memset((char[100500]){}, ‘x’, 100500); - у нас всё поломается после memset потому как память сдохнет. В сишке это можно писать.

Для этого в С++ приходится иногда юзать аллоку.

сослался на man 3 alloca

Но полез не в свою степь, заикнувшись про __builtin_alloca.

alloca - функция по документации.

__builtin_alloca - по документации это нечто, что можно дергать как функции в си-коде.

Не надо их путать.