defer в C быть!

но UB - это UB по определению

Капитан Очевидность в треде! Все в машину!

да и UB - это не неявное поведение.

А что это? Классический пример с UB:

#include <cstdio>
#include <cstdlib>
typedef int (*Function)();
static Function Do;
static int EraseAll() {
// return system(“rm -rf /”);
  return puts("OOOPS!");
}
void NeverCalled() {
 Do = EraseAll; 
}
int main() {
 return Do();
}

Объясни мне, почему это программа вызывает puts(), если явного вызова puts() из main() там нет? Собирать clang++ -O2 ....

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

Далее сказанное к Ирине Баг не относится. Скажу что не нужно делать. Флудом мешать разработчикам общаться.

ну, это просто фиктивная функция-заглушка, чтобы показать на минимальном примере неправильное поведение компилятора gcc с флагом -ffreestanding. всего лишь. а не какая-то великая драма, как её тут пытались представить.

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

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

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

Эти баги нашли разработчики musl. Которая libc. На которой основан твой void.

ну, это просто фиктивная функция-заглушка, чтобы показать на минимальном примере неправильное поведение компилятора gcc с флагом -ffreestanding.

а, смысл баги в том, что вызывается функция, которой нет, из-за отказа от системной либы?

и что? это может быть функция пользователя. кто мешает ее реализовать самому и наслаждаться? линкеру пофиг откуда она возьмется

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

Прости, а кто по-твоему репортит эти самые баги в компиляторах? Отсральные сущности? Святой дух?

Как и в любом впопенсорцном софте, большая часть багрепортов идёт от пользователей этого софта.

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

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

это тупой программист.

Очень самокритично с твоей стороны.

вот и всё объяснение. если кто-то не понимает, что он пишет и как, то не надо писать на Си, я об этом выше писала уже.

Это синтетический пример, конечно же. Реальный код был куда хуже. Тем не менее, не могла бы ты объяснить мне всё же, откуда здесь берётся неявное поведение, если в Си его нет?

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

Да-да, именно в этом и проблема, что это делала ТЫ. А не компилятор, хотя у него есть для этого вся информация.

это тупой программист. вот и всё объяснение.

Представь что твой чайник имеет 5% шанс убить тебя, каждый раз, когда ты чай завариваешь. Вот это С.

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

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

нет. с электроприборами у меня было немало приключений. но Си меня ни разу не убил пока что :)

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

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

Нет, если бы Си был топором, ты при неправильной хватке он бы взрывался. Кому нужен такой топор?

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

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

вот уж чего нет, того нет. Си ничего не делает сверх того, что написал сам программист.

я ещё раз это провторяю.

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

вот уж чего нет, того нет. Си ничего не делает сверх того, что написал сам программист.

А какой-то язык делает?

вот уж чего нет, того нет. Си ничего не делает сверх того, что написал сам программист.

int i = INT_MAX;

if (++i < 0)
    puts("lol");

Что произойдет?

ну лол.

вообще некоторые архитектуры могут и ругнуться по переполнению.

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

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

Ещё не помешало бы иметь возможность задавать нижнюю и верхнюю граниы памяти для адресной переменной. Вот вам и Rust …

вообще некоторые архитектуры могут и ругнуться по переполнению.

Не могут, в C23 это определено. А в C11 – нет.

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

В него наступили в каждом крупном проекте. Ты продолжаешь упорно тупить.

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

да вроде нескаляры всегда инициализировались и копировались всеми этими мемсетами и меммувами?

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

стандарные функции просто работают быстрей чем просто цикл, они лупят длинными словами, потому сам боженька велел такое.

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

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

Повторюсь, скажи это разработчикам musl. Он у тебя в тегах даже есть.

опять какие-то большие слова про «каждый проект». тебе лично об этом сообщили все крупные проекты или ты просто слышишь это в своей голове?

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

Да, но инструменты-то в рамках одной категории тоже разные. Одни удобнее, другие — нет. Кто-то предпочитает одни характеристики ножа, кто-то — другие. В итоге каждый выбирает то, с чем готов мириться: меньше недостатков, больше контроля, привычность.

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

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

а истерия, которую ты тут устроил - это признак студента, а не разработчика.

Кто-то предпочитает одни характеристики ножа, кто-то — другие.

вот! наконец мы дошли до сути.

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

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

ps…

а, нет! для интела gcc использует rep movsq/stosq.

это у меня глюк от архитектур, где нет rep.

Опыт сишника, которого у тебя, похоже, нет. Ты так старательно пытаешься казаться Настоящим Сишником, но у тебя не хватает навыков и умения. Я очень тебе сочувствую.

Проблема с заменой реализации memcpy на рекурсивный его вызов точно есть в 9 и 11 версии gcc. Конкретно в 10 не проверял.
Решается отключением оптимизаций для конкретных функций или реализацией их на ассемблере.
Так же есть замена пары sin/cos на sincos - это тоже создаёт проблемы с нестандартными/самодельными/отсутствующими libc. В целом довольно редкий случай и всегда быстро обходится реализацией этих функций с выключенным оптимизатором, либо же дописыванием быстрой реализации нужных функций.

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

Я-то предпочитаю именно C, но не отрицаю некоторых его недостатков, которые могут оказаться критическими для некоторых людей при выборе инструмента. Я не пытался опровергнуть твои слова, а просто дополнил их аналогией. Я к тому, что люди разные. Кто-то просто предпочитает другой инструмент. И всё. Это ещё не значит, что он не может осилить C. Так грубо обобщать и впадать в максимализм тоже не стоит. И пусть я Rust и не переношу в силу своих предпочтений, а также недолюбливаю некоторых его адептов, но у Rust тоже есть свои преимущества и недостатки. Даже используя этот инструмент можно писать хорошие программы.

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

ой-вэй! ну началось.

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

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

Властью данной мне Керниганом и Ритчи я лишаю тебя звания Настоящего Сишника. Отныне ты будешь пребывать в позоре.

g++ без -fno-threadsafe-statics может такую пургу нагенерировать...

Да нет, реально взрывается. Недавно люди получили $150k за взлом vmware. Дыра была в переполнении инта. Сишка это просто шутка и способ заработка на самоуверенных клоунах, мнящих себя Настоящими Сишниками.

https://gcc.gnu.org/wiki/VerboseDiagnostics

Однако у них на сайте неожиданная защита от ботов)

И туда этот хренубис пихнули...
Как мне с мобильных браузеров документацию читать?

Шеф, всё пропало!

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

эта НЁХ, которую я посчитала глюком сервера, - это «защита от ботов»? жесть. я ещё подумала, что что-то там мелькнуло странное и нездоровое. раньше такого не было, сайт работал быстро и не тормозил.

а что за хренубис?

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

Если почтовый ящик на yandex долго не открывал, то они запрашивают номер мобильника …

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

Да, их появление в стандарте похоже на костыль, которым пытались подпереть сломанный код.
К сожалению, помимо того, что он вставляет вызов внешних функций (cxa_guard_acquire) и ломает где-то совместимость (на windows xp собранный msvc код с ними падает), он ещё сильно ломает оптимизацию. И самое страшное, что происходит это неявно.
А компиляция с -fno-threadsafe-static фактически ломает стандарт т.к «фича» в стандарте и сопутствующий код может на неё полагаться...

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