Опять уязвимость в этом Линукс

нет, не сидят.

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

Я не помню о чём речь, но если я и выкладывал такой код

У тебя там использование значения указателя после free() было

который падал из-за не тех варнингов, то только в качестве примера к чему-то. И слово «жаловаться» тут не к месту.

И если ты реально можешь

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

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

который падал из-за не тех варнингов, то только в качестве примера к чему-то. И слово «жаловаться» тут не к месту.

Он не собирался из-за тех ворнингов. Тред был как раз про use-after-free и про то, что использование значения указателя после вызова free() – это UB.

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

В смысле? Тебе деньги не нужны?

У тебя есть статистика?

Он не собирался из-за тех ворнингов. Тред был как раз про use-after-free и про то, что использование значения указателя после вызова free() – это UB.

А ну вот, значит я там специально написал код для демонстрации дурости ISO-графоманов, у которых gcc к сожалению позаимствовало это поведение. Но вообще я всё ещё не помню ту ситуацию. Про то, что использование значения после free это якобы UB, я скорее всего из той темы и узнал. Это не особо нужная вещь и вряд ли где-то у меня встречалась, что впрочем никак не отменяет того, что делать её UB - это какая-то чушь.

В смысле? Тебе деньги не нужны?

Ох уж эти свидетели золотого тельца. Только одно у них на уме.

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

А откуда им ещё брать поведение? Из твоих фантазий? Из астрала? Или какие ещё варианты?

Но вообще я всё ещё не помню ту ситуацию. Про то, что использование значения после free это якобы UB, я скорее всего из той темы и узнал.

Вот ссылка на тред: Навеяно свежей дырой в Xorg. Можешь свои сообщения там посмотреть.

впрочем никак не отменяет того, что делать её UB - это какая-то чушь.

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

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

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

С каких это пор обычные меры безопасности стали параноидальными идеями? Linux следует парадигме UNIX DAC, и он согласуется со здравым смыслом - сложнее что-то сломать в системе, когда в основном сидишь под пользователем. К тому же, обычная практика для сервисов требовать нерутового пользователя, дропать capabilities после инициализации и т.д. Исключения м.б. и есть, но это именно исключения. В винде аналогично, просто у пользователя может быть как бы дополнительная роль админа (но это не значит, что все процессы исполняются под админом).

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

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

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

PS: Ну и да, соглашусь насчет рута, на домашней тачке имею(а от кого мне на домашней тачке прятать привилегии? только от себя пьяного)

myusername ALL=(ALL)NOPASSWD:ALL

Ты что-то зациклился на паранойе. Беспокоит тебя она?

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

cumvillain (07.02.23 18:54:19 MSK) фанат бюрократических си-стандартов https://www.linux.org.ru/forum/development/17122046

-Wall -Werror упадёт даже на if(a || b && c), рекомендуя ставить лишние скобки, и показателем наличия проблем оно никак не может считаться, это просто параноидальный (хотя есть ещё более строгие) режим поиска подозрительного кода. Предупреждать же про то, что код зачем-то использует значение указателя после free - вполне норм, это и правда подозрительно. Нарушений же в ходе исполнения программы (если убрать -Werror), даже с -O3, там нет. Так что gcc ни в чём не виноват.

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

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

Такая тенденция к сожалению имеется

Это не тенденция. Так было всегда со времён появления стандарта. Потому что C изначально не было хорошим языком, и вместо того, чтобы жёстко задать однозначное поведение и заставить всех ему следовать, авторы стандарта прикрыли жопу и напихали терминов типа UB во все поля. Ну, то есть, то что я написал является проблемой минимум лет 25.

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

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

Нет, специальный флаг нужен чтобы эти фичи были не все. По умолчанию (умолчание это -std=gnuXX, XX разное в разных gcc) они есть. Если сделать -std=c89 то фич будет поменьше, но всё равно будут. Думаю, фичи добавлялись по принципу их нужности в данный момент, например авторам самого gcc или авторам glibc (или ещё каких-то центральных GNU-проектов но что-то не вспоминаются сходу). И я не помню деталей, но помнится что всякое ненужное из ISO стандарта в gcc часто получало поддержку с большой задержкой. Часть из того, что gcc реализовали в своё время, позже добавляли в ISO. Часть - так и не добавили, но кого это волнует? Весь код долгое время писался именно под стандарт gcc, а не под ISO, и лишь в последнее время корпораcтическими усилиями ему организовали шланг-конкурента. И у gcc, несмотря на все эти UB в бумажках, вполне предсказуемое поведение в большинстве мест (часть их них регулируется флагами -f, которые в т.ч. меняются от уровня оптимизации).

Если нужен 100% стабильный результат, то можно выбрать эталонный компилятор (либо распространять его бинарником, либо организовать побайтово репродуцируемую его сборку) и компилировать всегда строго им. Компилятор может быть хоть из 90-х, главное чтобы для нужд проекта годился.

Нет, специальный флаг нужен чтобы эти фичи были не все. По умолчанию (умолчание это -std=gnuXX, XX разное в разных gcc) они есть.

Серьёзно? Я всегда думал, что там -std=c89/99/etc по-умолчанию. С другой стороны, я всегда руками более новый стандарт указывал.

Если нужен 100% стабильный результат, то можно выбрать эталонный компилятор

Такой компилятор сейчас ровно один и называется compcert. GCC и Шланг – это не стабильные компиляторы. То, что ты предлагаешь, это бомба замедленного действия, потому что такая «штобильность» никак не предотвращает UB в твоём коде. И когда рано или поздно компилятор придётся обновить (например, для поддержки новой платформы), можно огрести.

Тащемта поэтому сишку проще выбросить на мороз уже в как минимум половине случаев и взять язычок без этих «особенностей».

Такой компилятор сейчас ровно один и называется compcert. GCC и Шланг – это не стабильные компиляторы.

Любой компилятор будет стабильным если он зафиксированной версии зафиксированной сборки.

потому что такая «штобильность» никак не предотвращает UB в твоём коде

У стабильного компилятора точно не изменится поведение через 100 лет, и там где не было UB - оно не появится неожиданно. В частности, в gcc 12.2 использование значения указателя после free - не UB. В каком-нить gcc 53.1 возможно, вдруг станет (мало ли). Но если мы зафиксируем gcc 12.2 - то оно всегда будет не UB.

И когда рано или поздно компилятор придётся обновить (например, для поддержки новой платформы), можно огрести.

Это всё может быть, а может не быть. Я кое-что, как раз в целях стабильности, до сих компилирую vc97 (для оффтопика), которым я его компилировал давно на старте проекта. У него в дефолтных .h/.lib даже нет поддержки winnt5 (например доп. кнопок мыши и горизонтального скролла), но это можно подкостылить. Переход на какой-нить arm тут разумеется невозможен без полного рефакторинга, но и не нужен. Если gcc начнут выкидывать фокусы с внедрением UB в неожиданных местах - зафиксирую и его, никаких проблем. Только тут уже будет версия современная со всеми платформами.

UB - это понятие из стандарта. Стандарт определяет, что есть UB, а что - нет.

UB - это понятие из стандарта. Стандарт определяет, что есть UB, а что - нет.

Наш друг firkax отрицает стандарт языка. UB для него внедряют инопланетяне.

В частности, в gcc 12.2 использование значения указателя после free - не UB.

Дядя, ты точно знаком с языком C? То, что компилятор не выдает предупреждение, ещё ничего не значит. На целочисленное переполнение или разыменование NULL он его тоже может не выдать, но ты поди ж…

В общем-то, это жирная проблема языка, про которую я тебе раз 5 писал уже: список UB в одном только C занимает 13 страниц, и зачастую ты не знаешь, есть оно в твоём коде или нет. Пока он не упадёт где-нибудь. Язык C без UB был бы гораздо лучшим языком чем то что сейчас.

Я кое-что, как раз в целях стабильности, до сих компилирую vc97 (для оффтопика), которым я его компилировал давно на старте проекта. У него в дефолтных .h/.lib даже нет поддержки winnt5 (например доп. кнопок мыши и горизонтального скролла), но это можно подкостылить.

Знаешь, в твоём подходе что-то есть. Фильм «Крепкий Орешек» — он про таких как ты снят. Террористы высаживаются в дома сишных комитетчиков и заставляют их добавлять фичи в язык, и только последний представитель старой гвардии суровый firkax упорно сопротивляется их попыткам установить превосходство.

А теперь пойми, что стандарт - это не только ISO. Разные версии gcc - вполне себе тоже стандарты, и на мой взгляд более авторитетные. В ISO - UB, в gcc - не UB.

Дядя, ты точно знаком с языком C? То, что компилятор не выдает предупреждение, ещё ничего не значит. На целочисленное переполнение или разыменование NULL он его тоже может не выдать, но ты поди ж…

Дело не в предупреждении, а в том, что free(p);printf("%p",p); в актуальных и более старых версиях gcc ведёт себя как надо: печатает адрес только что освобождённого блока памяти.

На целочисленное переполнение

Я так понимаю, речь про знаковое, поскольку беззнаковое нигде не UB. На это у него есть настройка в явном виде: -fwrapv. Если она включена (это дефолт), то знаковое переполнение ведёт себя предсказуемо, считая что MAX+1 = MIN. Если она выключена (например ключом -fstrict-overflow или -O2 без нейтрализующего -fno-strict-overflow) то оно считается UB.

разыменование NULL

Разыменовывать NULL не надо, но вроде бы в -O0 можно вполне быть уверенным что оно его действительно сделает как чтение/запись по нулевому (в x86) адресу. В -O2 вроде бы уже могут быть фокусы. Не вникал т.к. мне не нужно.

Да бога ради. Но тогда лучше не использовать (английский) язык ISO стандарта, чтобы людей не вводить в заблуждение. Не «UB», не «ID» и т.д., а какие-то свои слова. И на вопрос, на чем программируешь отвечать «на gcc12-c++». Как-то так что ли…

Слова «UB» и «C» не являются собственностью ISO-комитета, так что не надо тут. Издавать стандарты на язык C можешь хоть лично ты сам, вопрос только в том насколько твои стандарты будут кому-то интересны. Стандарт, поддерживаемый gcc - интересен практически всем (даже clang был вынужден его поддерживать во многом), а вот стандарт ISO - в основном теоретикам.

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

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

Это не «у меня», а у людей. Если речь про какой-то «стандарт GCC», вот, что поддерживает GCC:

https://gcc.gnu.org/onlinedocs/gcc/Standards.html

Никакого «GCC Standard» там нет, но постоянно упоминается ANSI/ISO.

Дело не в предупреждении, а в том, чтоfree(p);printf("%p",p);в актуальных и более старых версиях gcc ведёт себя как надо: печатает адрес только что освобождённого блока памяти.

Это не важно. Целочисленное знаковое переполнение тоже ведёт себя как надо, пока не начинает вести как не надо.

Разыменовывать NULL не надо, но вроде бы в -O0 можно вполне быть уверенным что оно его действительно сделает как чтение/запись по нулевому (в x86) адресу. В -O2 вроде бы уже могут быть фокусы. Не вникал т.к. мне не нужно.

Конечно могут. И даже будут. Например, может быть вызвана функция, которую на самом деле никто не вызывал. Но это всё явные случаи UB, про которые все знают. Есть ещё куча более забавных вещей. Например, бесконечный цикл без условий – UB. Или то что указатели нельзя просто так сравнивать друг с другом. У сишников часто от этого мозг лопается, но так написано в стандарте и так реализованы компиляторы. И поэтому C – очень плохой язык.

Ну и что? На той странице указано соответствие между разными ISO-стандартами, и флагами компилятора. Свою реализацию языка они официально стандартом не называют, но по факту так и есть.

Это не важно. Целочисленное знаковое переполнение тоже ведёт себя как надо, пока не начинает вести как не надо.

Да что ты несёшь, я тебе конкретную настройку для переполнения указал, в сообщении на которое ты отвечаешь.

Конечно могут. И даже будут.

Я в курсе, и что с этого?

бесконечный цикл без условий – UB

Что значит «без условий»? Условие всегда есть, явное или не явное (неявное - только в for). И разумеется это не UB, если речь про реальные компиляторы.

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

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

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

Что значит «без условий»? Условие всегда есть, явное или не явное (неявное - только в for). И разумеется это не UB, если речь про реальные компиляторы.

void f(void) {
  for(;;);
}

Я про такой код. Скажи привет UB. Даже в реальных компиляторах.

Вообще, мы тут опять столкнулись с той проблемой, что ты не знаешь определение термина UB в C, и поэтому несёшь пургу.

Это не «без условий» а «без тела», хотя и условий у него конечно тоже нет. Ну это не нужный код, пофиг на него. Выглядит как попытка завесить программу ценой сожранного ядра проца. Даже в оригинальном проце х86 линейки там должна была быть инструкция hlt, а в современном случае - какой-нить sleep(). Впрочем зачем его понадобилось делать UB я не знаю.

что ты не знаешь определение термина UB в C

UB - это ситуация «нельзя полагаться на результат компилирования данного кода».

У тебя какая-то терминологическая каша в голове

Нет, просто я не теоретик.

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

У любой реализации тоже есть спека, даже если она нигде не написана. А вот спека на ЯП, у которой нет референсной реализации - это не особо полезная вещь.

У любой реализации тоже есть спека, даже если она нигде не написана.

Это как?

И поэтому C – очень плохой язык.

Да, но ничего лучше со сравнимым уровнем поддержки пока не придумали.

Это не «без условий» а «без тела», хотя и условий у него конечно тоже нет.

Вообще, там написано «бесконечный цикл без побочных эффектов». То есть вот такой код тоже UB:

void f(void) {
  unsigned i = 0;
  for(;;) {
    i++;
    if(false)
      break;
  }
}

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

UB - это ситуация «нельзя полагаться на результат компилирования данного кода».

Не совсем. UB – это ситуация, когда нельзя полагаться на результат компиляции всего модуля. А не только проблемного куска.

Да, но ничего лучше со сравнимым уровнем поддержки пока не придумали.

Поддержки чего? Отстрела жопы программисту? Поддержки при попадании на доску почёта CVE, когда другие программисты подходят и говорят: «Да, чувак, как я тебя понимаю»?

Поддержки разного железа (x86, ARM, …) и отпимизаций под него.

Поддержки разного железа (x86, ARM, …) и отпимизаций под него.

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

Кстати, до того же Фортрана сишке всё ещё срать и срать в плане поддержки железа.

С появлением LLVM это уже неактуально.

LLVM на чём написан? На наследнике Си – C++, наследуя его недостатки.

LLVM на чём написан?

Да вообще насрать. LLVM – это такая штука, которая преобразует LLVM IR в код целевой платформы. На чём он написан, должно парить разрабов LLVM и больше никого. Ты ещё блин взбухни тут на чём LibreOffice написан и попытайся туда C++ притянуть.

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

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

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

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

Плохо, да. А возникнуть он может и без рефакторинга как результат всяких ifdef по разным фичам компилируемой проги. Но, думаю, всё же тут UB опять только в стандарте, а на практике, если даже такое поведение компилятора (порча кода из-за такого места) обнаружится - его авторы компилятора, несмотря на все эти оправдания, посчитают багом и исправят. Хотя не проверял, да.

Ой. Это что, царская риторика? Краденый рантайм?

Но, думаю, всё же тут UB опять только в стандарте, а на практике, если даже такое поведение компилятора (порча кода из-за такого места) обнаружится - его авторы компилятора, несмотря на все эти оправдания, посчитают багом и исправят.

Или не исправят. Компиляторщики любят слать всех нахрен, ссылаясь на стандарт.

Кстати, нашёл вот такое: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm

А вот пример как это работает: https://github.com/llvm/llvm-project/issues/60622. Там подтверждают, что и в GCC тоже.

Как видишь, твои ожидания и реальность очень сильно расходятся.

Там всё-таки именно полностью пустой цикл. И вряд ли авторы gcc будут слать нахрен например авторов glibc, когда те споткнутся о проблему неадекватной компиляции.

А вот по первой ссылке интересные детали - оказыется это введено ради «в С++ нужно, не делать же для С отдельную логику», что очень печалит.

А ещё там в разделе «The technical issue: loop optimization» неявный мерж двух циклов в один, такая логика мне тоже не нравится.

Там всё-таки именно полностью пустой цикл.

Это предельный случай. if(false) будет выкинут оптимизатором и у тебя появится такой же пустой цикл в лёгкую.

И вряд ли авторы gcc будут слать нахрен например авторов glibc, когда те споткнутся о проблему неадекватной компиляции.

Авторы glibc сами любят слать нахрен всех. Один только Ульрих «STOP REOPENING» Дреппер чего стоил!

А ещё там в разделе «The technical issue: loop optimization» неявный мерж двух циклов в один, такая логика мне тоже не нравится.

Ах.. ну раз тебе не нравится, то надо отменять! Хехехехе..

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

Это предельный случай. if(false) будет выкинут оптимизатором и у тебя появится такой же пустой цикл в лёгкую.

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

Авторы glibc сами любят слать нахрен всех.

Посторонних - может быть. А своих (GNU) наверно всё-таки нет.