Вы не давали никакого «своего стека».

Запустите и проверьте.

Вы дали реализацию на malloc(), которая ни как не относится к сегменту стека.

Ну и замечательно. Я уже какой раз повторяю, что пользоваться «сегментом стека» не обязательно, всё и без него прекрасно работает.

И, кстати, довольно кривую.

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

А какая разница что Вы говорите?

Я уже какой раз повторяю, что пользоваться «сегментом стека» не обязательно, всё и без него прекрасно работает.

Какая разница что Вы пользуетесь динамическими массивами, т.е., пользуетесь всё тем же сегментом стека, если Вы ими просто пользуетесь, ровным счётом ничего не зная об этом? Если, кончно, пользуетесь динамическими массивами, да.

Потому что это минимальная демонстрация.

Ну, то есть, Вы показали какую-то бредятину, которая сперва тупо не компилировалась, а теперь ещё и полу-готовая и предлагаете мне:

Запустите и проверьте.

А зачем? Я и без Ваших недореализаций в курсе что есть сегмент стека и что им нужно (или не нужно, зависит от обстоятельств) пользоваться.

Зачем мне это высокохудожественное рукоблудие в Вашем исполнении? =)))

P.S. Ну и аноним вот хорошо подтверждает:

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

Да, так.

Огггадааа... =)))

Я не говорю, что «сегмента стека» нет, я говорю что в нём нет ничего особенного по сравнению с mmap и пользоваться им не обязательно.

Если не понимаете что это и зачем это, то да. Лучше не пользоваться. Тут Вы безусловно правы. =))) Но вот всё остальное (насчёт mmap()) то ложь.

Какая разница что Вы пользуетесь динамическими массивами

Какие ещё динамические массивы? В моём коде нет никаких динамических массивов.

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

Только на момент запуска процесса. После вызова SwitchStack, «сегмент стека» уже не используется. Если вас так смущает oldCtx, то можете его удалить и заменить LongJmp(oldCtx, 1) на exit(0), чтобы сегмент стека точно не использовался после SwitchStack. Контекст ctx в SwitchStack конструируется с нуля без использования сегмента стека.

В Вашем коде?

Какие ещё динамические массивы? В моём коде нет никаких динамических массивов.

В Вашем коде их нет, я поэтому и сказал – если конечно пользуетесь динамическими массивами. Но вот незадача – в моём коде они (как правило) есть.

Так что, про то и речь – показанную Вами говнину следовало бы обоссать и сжечь.

Только на момент запуска процесса. После вызова SwitchStack, «сегмент стека» уже не используется. Если вас так смущает oldCtx, то можете его удалить и заменить LongJmp(oldCtx, 1) на exit(0), чтобы сегмент стека точно не использовался после SwitchStack.

Я не знаю что это за таинственные заклинания. И к чему они здесь.

В Вашем коде их нет, я поэтому и сказал – если конечно пользуетесь динамическими массивами.

Проверил динамические массивы и даже циклы сообщений GUI, всё работает. Я вообще не понимаю почему они не должны работать, динамические массивы выделяются на куче, а не на стеке. alloca() тоже работает, проверено. И исключения с раскруткой стека работают (рантайм libgcc_s).

Я не знаю что это за таинственные заклинания.

То есть вы ничего не понимаете как на самом деле работает стек. Смогли выучить только мануалы для админов вроде rlimit.

А Вы забавный, да... Не отнять... =)))

Проверил динамические массивы и даже циклы сообщений GUI, всё работает. Я вообще не понимаю почему они не должны работать, динамические массивы выделяются на куче, а не на стеке. alloca() тоже работает, проверено. И исключения с раскруткой стека работают (рантайм libgcc_s).

Я взял тот говнокод, который Вы привели мне в качестве «доказательства», проверил. Ну, тот где Вы из musl попытались скопипастить чего-то. Выше в треде было.

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

Что именно Вы проверили – я без понятия. В какой система – тоже. Всё остальное из Ваших «доводов» смахивает на какую-то альтернативную реальность или на то, что Вы тупо не вкуриваете что Вы используете стековый сегмент даже не понимая того, что именно Вы используете.

Скажите, только честно (уже второму за день задаю этот вопрос) – Вы на… в игнор сами пойдёте или мне Вас направить? Потому как уже очевидно что в нормальных системах, для нормальных людей стековый сегмент есть и нормальные люди понимают пользоваться им или нет и как именно? Остальное это выглядит как попытка натянуть сову на глобус и хоть что-то брякнуть, пусть даже противоречащее текущей реальности (той, где мы про стековый сегмент на ЛОРе общаемся).

Вы даже в своём коде путаетесь. Рекомендовать Вам пересобрать всю Вашу систему с Вашим говнокодом я не буду, т.е. в том же GUI динамические массивы используются на всю голову. В прикладном софте тоже. Вы просто задолбаетесь со «своей» реализацией стекового сегмента. И, кстати, совершенно пофиг что Вы её реализовали – до Вас даже не доходит что компилятор сгенерировал код помимо Ваших очумелых ручек.

Ещё раз – умные люди в курсе как и что работает. Ну а рукоблудом законодательно быть не запрещено, хоть и выхлоп тут около нулевой. И тут не важно знаете Вы что-то от сегменте стека или нет. Как только использовали несуществующую в Вашей реализации alloca(), приплыли, т.к. сразу сегмент стека и использовали.

Да, всё верно – Вы не вкуриваете о чём вообще речь.

Итак, что скажете – в игнор по причине Вашей бестолковости или Вас иной раз стоит почитать?

Где Вы там нашли хоть что-то, похожее на реализацию alloca() и не спрашиваю.

«Реализация alloca()» делается компилятором при построении объектного файла. Двумя машинными кодами.

используете стековый сегмент

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

Где Вы там нашли хоть что-то, похожее на реализацию alloca() и не спрашиваю.

Она не нужна, стандартная реализация alloca() работает без проблем. Ей не нужен сегмент стека, достаточно манипуляций с ESP/RSP. У меня GCC инлайнит вызов alloca() (объявлен как define на __builtin_alloca) и в машинном коде только манипуляции с ESP/RSP.

в том же GUI динамические массивы используются на всю голову

И они прекрасно работают после SwitchStack. Отладчик показывает что код выполняется в новом стеке, выделенным программой, а не в стековом сегменте.

Итак, что скажете – в игнор по причине Вашей бестолковости или Вас иной раз стоит почитать?

Никто не заставляет вас меня читать. Игнорьте наздоровье. Оставайтесь наедине с вашим невежеством и культом сегмента стека. Свободу религиозных взглядов я у вас не отнимаю.

Вы всё правильно прочли...

«Реализация alloca()» делается компилятором при построении объектного файла. Двумя машинными кодами.

Вот только одно «но». Странным образом Вас ни кто не спрашивал как она реализована. =)))

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

Не. Вам осталось без включения недопсиолуха чуток меньше. А именно – начать читать маны. «Курить» не рекомендую. И теперь открываем man и читаем там:

The alloca() function allocates size bytes of space in the stack frame of the caller. This temporary space is automatically freed when the function that called alloca() returns to its caller.

И со всем остальным (я про маны вообще) у Вас всё получится. Я в Вас верю! =)))

=)))

Мало скобочек. Давай больше.

The alloca() function allocates size bytes of space in the stack frame of the caller. This temporary space is automatically freed when the function that called alloca() returns to its caller.

Осталось вам понять, что тут написано, да.

Кстати, где тут про стековый сегмент?

О как...

Она не нужна, стандартная реализация alloca() работает без проблем. Ей не нужен сегмент стека, достаточно манипуляций с ESP/RSP. У меня GCC инлайнит вызов alloca() (объявлен как define на __builtin_alloca) и в машинном коде только манипуляции с ESP/RSP.

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

А разговоров-то было… =))) Да, в том-то и проблема (я Вам об этом сразу прямо и сказал) что Вы нарукоблудили какую-то х… «ерунду» даже не понимая что и зачем Вы делаете. Т.е., стековый сегмент у Вас как был, так и есть. gcc с ldd, а так же системный загрузчик ld как работали, так и работают. И только Вы один такой а не сгенерить ли мне аналог стека? Сгенерить! А нафига, если к есть, Вы себе этого вопроса не задаёте.

Никто не заставляет вас меня читать. Игнорьте наздоровье.

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

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

Он стебется, имхо.

Вас ввело в заблуждение что там...

написано «stack frame», а не «stack segment»? Ну это то, чего нет в первом же приведённом Вами линке на исходники. Читайте маны. «Гугль любит Вас». =)))

Anon... Я Вас умоляю!

Не палите поляну… =)))

написано «stack frame», а не «stack segment»?

Осталось выяснить, что такое «stack frame». У вас получится. (Нет.)

Прекратите, немедленно, издеваться, мы вам поможем, если прекратите, ПОЖАЛУЙСТА.

Я сейчас расковыриваю многолетнее легаcи на php, работающее с текстами на языках Восточной Азии.

А в перерывах рою еще одно легаси на sh.

Мне вряд ли что-то поможет)

написано «stack frame», а не «stack segment»?

Стековый кадр не имеет отношения к сегменту стека и создание стековых кадров прекрасно работает на своём стеке. Для создания стековых кадров вообще ни рантайма, ни ядра не нужно, весь код генерирует компилятор (PUSH EBP; MOV EBP, ESP и т.д.).

Вам аноним уже всё сказал.

Я же могу заметить только то, что если Вы воспринимаете меня как гугль, то я Вам соболезную.

И да, по непрекращающимся попыткам недотроллинга от человека, приводящего оффтоп в качестве «примера» моё первоначальное желание отправить Вас на х… в игнор, в общем, было вполне правильным.

Что я и делаю. В игнор, значит в игнор. =))) Поясню – это чтобы не испытывать чувство, называемое «испанский стыд», когда тупняк включаете Вы, а за linux-программирование и elf-файлы с POSIX в Вашем «исполнении» стыдно мне.

Спасибо за понимание, удачи в начинаниях. =)))

Я сейчас расковыриваю многолетнее легаcи на php, работающее с текстами на языках Восточной Азии.

А в перерывах рою еще одно легаси на sh.

Мне вряд ли что-то поможет)

Этточно… Но хоть я Вам и могу посочувствовать (нет, у меня даже вебня и та на С), это не отменяет моего решения. =)))

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

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

Я не знаю что Вы смотрели.

Я специально смотрел генерируемый машинный код и в нём мне всё понятно и предсказуемо.

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

Далее. Вам мало того что не было стыдно выложить нерабочую версию, Вы даже не извинились за то, что в форум выложили откровенное говно. Пересобрать с этим говнокодом всю систему и заменить реализацию stack segment или, если угодно, то stack frame, даже и не пытайтесь – не выйдет. Что именно Вы доказали? Да то, что путаете реализацию ADT типа stack и то, что сгенерировал Вам компиль и линкер.

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

Но знаю, возможно Вы не туда смотрели и просто в глаза долбитесь. Японские сексуальные перверсии мне не интересны. Но лично меня насторожило то, что Вы занялись рукоблудием (читай – онанизмом) вместо того, чтобы как любой нормальный человек просто использовать существующие механизмы. Да, до Вас что-то начало доходить когда Вы внезапно заметили что alloca() как работал, так и работает вне зависимости от выписываемых Вами кренделей. Но нет, рукоблуды-затейники не интересны.

Спасибо за понимание. В игнор однозначно.

В современных архитектурах процессоров

Строго говоря, это не «архитектуры процессоров», а набор инструкций конкретного CPU. В 2К21 между этими терминами есть разница. И да, в нём могут отсутствовать специализированные команды для работы со стеком.

А что не так?

Крестокод в моей сишечке.

Где там крестокод, ты о чем?

В некоторых ISA с историей, например в s390, не было специальных инструкций и регистров для стека, начиная с середины 1960-х. Программы, которым нужны stack frame’ы, организуют их программно, используя доступные инструкции и регистры общего назначения.

https://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_s390.html#PARAMETERPASSING

не касаясь остального.

А вот это вот сразу так далеко, что отсюда не видно даже. =))) Обычно С-программисты всё-таки, умнее железа и софта и сами знают как грамотно использовать распределение памяти. Вообще, на мой взгляд, все попытки изобрести новые, безопасные языки программирования, да ещё и со сборкой мусора, которая работает сама по себе, вне контроля программиста, это попытка защитить идиотов от самих себя. Нет, не защитите. Любые языки со сборкой мусора это АдЪ, треш, угар и немного, буквально для придания чуточки пикантности, содомiя. В одном флаконе.

Слишком сильное («Любые языки со сборкой мусора это ...») утверждение.

Скорее «Почти все».

правильно приготовленная сборка мусора действительно так же(т.е сопоставимо) удобна как наличие аппаратных указателей вершину стека и прочего mmu частично уменьшающих у «Обычно С-программисты» рутинность.

правильно приготовленная сборка мусора действительно так же(т.е сопоставимо) удобна как наличие аппаратных указателей вершину стека и прочего mmu частично уменьшающих у «Обычно С-программисты» рутинность.

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

Ну да. Соглашусь.

Слишком сильное («Любые языки со сборкой мусора это …») утверждение.

Скорее «Почти все».

Вы правы. Это я «в пылу полемики», как говорится. =) Хотя, и не совсем. Пока не видел толково сделанную сборку мусора. Тут бы ещё научить сборщики мусора работать в моменты наименьшей нагрузки на систему. Но они этого не умеют. В результате что есть то и есть и тормоза включаются в самый неподходящий для этого момент. Хоти чтобы лучше было, а выходит как всегда.

А вот здесь...

я лично думаю что:

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

Код и так должен быть максимально упрощён. Если иерархия вызовов представляет собой какой-то несусветный адок, то скорее всего что-то не то с архитектурой приложения. У меня иной раз складывается мнение что мы разучились писать сложные приложения простыми средствами, если честно.

Речь идет о перекладывании рутинных задач на гц.

Да что в паре malloc()/calloc() и free() ещё можно упростить-то?

Код и так должен быть максимально упрощён.

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

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

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

Это как раз причина почему питон взлетел среди ученых - он (благодаря сборщику мусора) позволяет сосредоточится на предметной проблеме, а не заниматься изучением API и разными нюансами, которые не имеют отношения к решаемой проблеме.

Это разные подходы.

среди ученых

Это один подход. Грубо говоря, «посчитал-выкинул». Ну, если очень грубо говоря.

Мои же софтины могут жить в системе 24/7. Пока система вообще включена. И тут приходится крайне вдумчиво «обрабатывать напильником» так, чтобы мой софт не мешал остальному софту работать. Поэтому к проектированию приходится очень аккуратно относиться и не только лишние зависимости за борт, а и ещё массу вопросов решать.

В качестве примера, что называется, «пямо из-под рук». Сейчас пишу некое веб-приложение. Да, на С как обычно (в смысле обработки http(s) запросов ни php ни python, ни кто не дали ровным счётом ничего нового, кроме утяжеления экосистемы приложений и тщательно замаскированных ошибок). По условиям мне нужно для отдельных действий уведомлять пользователя по почте. В принципе, я могу это сделать как минимум тремя разными способами:

• Прямо из потока, где что-то произошло слать через libesmtp почту пользователю.

• Создать отдельный поток, который из нескольких потоков будет собирать почтовые отправления и рассылать их пользователям.

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

Конечно я воспользуюсь последним вариантом, т.к. в памяти держу то, что система может масштабироваться в дальнейшем. А городить огород с RabbitMQ или ещё чем вообще не охота. Можно упростить. Т.е., выставить этот отдельный демон на другой машине, подцепить надзираемый им каталог по NFS, этот каталог поставить на «просмотр» через fanotify или inotify и горя не знать. Появилось что-то в каталоге, создали поток, считали файл, отправили его по почте.

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

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

Абсолютно точно. И с остальным согласен. Да, где-то сборщик мусора и не нужен от слова совсем или даже вреден, но и говорить, что гц не нужен совсем - тоже неправильно, где-то он может быть очень полезным.

Сейчас, к сожалению...

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

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

И чаще всего она занята чем-то типа «сама себя обслуживает».

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

Но чаще всего наоборот вредят – расхолаживают головной мозг программиста.

Тут не соглашусь. Вреда от них не больше чем от АКПП.

Да. В психологии.

К сожалению, я пришел к выводу, что причина этого лежит в психологии человека.

И кодом или железом этого не исправить. Только метелить за говнокод по-взрослому. Отучать от косяков путём фиизического насилия или тренировок. Подход «а я написЯл и оно вроде работает» должен искореняться. Потому что «написЯл», да оно не учитывает особеностей окружения, где будет работать, это называется «наговнокодил».

Вреда от них не больше чем от АКПП.

Проблема в том, что есть универсальные языки и есть «нишевые» («днищевые» тоже есть, но их в расчёт не берём). Вроде, АКПП это крайне удобно, но если человек внезапно сядет на «ручку», то поехать ему будет крайне сложно. Т.е., он не понимает почему его «самобеглая коляска» едет так, а не иначе. Его просто не научили пониманию процесса. Сейчас в ВУЗах, к сожалению, слишком мало и неправильно обучают «системообразующему» языку С. Выпускник (адепт того или иного языка) свято верует в то, что его язык прозволяет просто чудеса творить. Но если мы меняем ему предметную область, то начинаются судорожные гугления решения.

Так что, понимать как устроены memory pools надо. И как реализуются те же ADT. И как можно (а как не нужно) использовать чистое внутрисистемные средства (те же dnotify). Тут проблема в том, что что бы там ни звиздила добрая тётушка-фея от «индустрии», ровно в двадцать четыре ноль-ноль, карета супер-языка со многими возможностями может внезапно стать тыквой, кони крысами и самое главное, надо приглядывать чтобы тампакс не стал опять кабачком. =)))

Только метелить за говнокод по-взрослому.

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

Так что, понимать как устроены memory pools надо.

Однозначно, наличие сборщика мусора никак не отменяет необходимости в этом. То, что человек не знает, как работает подсистема памяти это не вина сборщика мусора.

В общем-то мы с вами об одном и том же говорим, просто смотрим с несколько разных сторон.

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

=)

в куче или в стеке?

Что такое куча у вас в плюсах?

Владимир 123