Fil-c: Rust killer

Но в rust тоже есть ub, верно?

Я не пойму что ты пытаешься донести.

Вот твоя фраза:

Your C or C++ software most likely compiles and runs in Fil-C with zero changes.

Т.е. все UB в языке на месте?

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

Fil-C, как я понял, не имеет ub связаных с памятью.

Или писать мусор в файл.

В приличных местах за такое канделябрами бьют.

А есть новизна: он собрал своим клмпилятором gnu/linux и запостил твит в X.

Встроенные в язык проверки приведут к первому варианту.

Это уж как повезет.

Вот именно.

Вот именно. Поэтому количество UB не имеет принципиального значения до тех пор, пока мы не касаемся моментов, которые выглядят потенциально корректными, а на самом деле таковыми не являются. Однако, мне почему-то кажется, что вы вряд ли о таких тонких материях как неиспользование std::start_lifetime_as говорите.

Языки с UB активно мешают заметить.

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

Резюмирую: C++ небезопасен. В нем легко отстрелить себе ногу. Более того, в нем есть моменты, когда неопытный программист даже не подозревает, что отстрел возможен. Поэтому C++ лучше не применять, когда такая возможность есть. Но когда к C++ все-таки приходится обращаться, то пенять C++у на счет наличия UB – ну это как обвинять масло что оно маслянное.

Memory Safety: Advanced runtime checks

Нет, это не rust killer.

Я говорил про provenance. Вряд ли оно как-то относится к топику. Но всё же дам пример проблем из-за provenance:

https://www.ralfj.de/blog/2020/12/14/provenance.html

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

#include <stdio.h>
#include <inttypes.h>

int main()
{
    // Два массива на стеке. Они могут располагаться непосредственно один за другим, а могут и нет.
    char p[1] = {0}, q[1] = {0};

    // Так называемый past-one указатель: указывает на объект после последнего в массиве 'p'.
    uintptr_t ip = (uintptr_t) (p+1);
    // Просто кастуем адрес 'q' в uintptr_t.
    uintptr_t iq = (uintptr_t) q;

    // Указатели могут быть либо равны, либо не равны, верно? Третьего не дано.
    if (iq == ip) {
        // Указатели равны, 'q' располагается непосредственно после 'p'.
        // Здесь: p[0] == 0, q[0] == 0.

        // Пишем значение через 'ip', который равен 'iq', т.е. указывает на 'q'.
        *(char *) ip = 42;

        // Здесь: p[0] == 0, q[0] == 42. Или нет?

        printf("%d\n", (int) q[0]); // Выводит 0 с -O3, ничего не выводит с -O0. Потому что не заходит в тело if.
    }

}

Не нужно это никому.

Дыряшникам ничего кроме их дыряшки не нужно и не будет нужно, они даже до lifetimebound дорасти не способны. Остальные переходят но современные языки, им не нужна дыряшка с заплатками. Ещё раз подчеркну что на rust переходят потому что это ох%нный язык, а не потому что безопасный. Безопасность там - всего лишь вишенка на торте языка, библиотеки, сообщества, тулинга и экосистемы.

Могло бы пригодиться чтобы собирать весь легаси дыряшечный код, и если разработчики не врут, но достаточно взять любой source based дистрибуив, поменять там CC/CXX заменить на их поделку, собрать, и всё соберётся. Но что-то про такое начинание у них на сайте не слова.

Memory Safety: Advanced runtime checks

А зачем платить за рантайме проверки, когда можно проверить в compile time и не платить?

achieves complete memory safety with zero escape hatches

Сильное заявление для васянского проекта.

Modern Tooling

Modern Tooling - это cargo и куча third party cargo-* модулей, начиная с базовых cargo build|test|bench|fmt|check (помним что стандартного способа собрать код на даряшке нет, да?) и заканчивая cargo llvm-cov|flamegraph. А компилятор это всего лишь компилятор.

Нужна ли борьба с borrow checker?

Никакой борьбы с borrow checker нет. Когда опытный программист пересаживается с плюсов на rust, ни одной ошибки от borrow checker он не увидит, потому что и так выполняет бч в голове, зная и понимая время жизни и владение объектов и ссылок на них, и не будет, например, мутировать коллекцию по которой итерируется, или перемещать объект на который есть живые ссылки.

Кто «борется» с бч, тот без него просто лепил бы UB в плюсах, а в других языках (в том числе в сабже) рантайм падения и просто некорректную логику, и претензии к языку из той же серии как абсолютные новички борятся с ошибками компилятора, который требует скобки и не даёт сложить 1 и «foobar» (шучу, даёт).

Известны ли уже CVS с ошибками в unsafe блоках?

Известны CVE с ошибками и вне unsafe блоков, прикинь.

Но что-то про такое начинание у них на сайте не слова.

Как ни слова?

Вот, можешь сам собрать: Pizlix — безопасный по памяти дистрибутив GNU/Linux

Россыпь скриптов которая неизвестно что неизвестно чем собирает это совсем не то что я сказал. Что ещё за yolo-c? Почему она собирает им, а не fil-c? Если, согласно его заявлениям, это drop-in replacement для C/C++ компилятора, почему что-то нужно портировать?

I haven’t yet ported LLVM to Fil-C++, and so long as I haven’t, the compiler will have to be Yolo-C++.

Вообще конечно я скорее поверю что чатгпт исправит все ошибки в дыряшечном коде, чем что человек который валит в один каталог (!), в git репозитоии (!!) LLVM’а (!!!) вместе доку по LFS, тарболы зависимостей и сборочные скрипты, а также и пишет такое

You must have a swap partition at /dev/sda3. If you have one somewhere else (or don’t have one), then make sure you edit the various scripts in this directory (and its subdirectories).

может написать совместимый memory safe компилятор C.

Так просто, для понимания уровня:

2023-12-19 17:11 -0800 Filip Pizlo                              o it fucking compiled something
2023-12-18 19:44 -0800 Filip Pizlo                              o it compiles, wow                                                                                                                                                                                                          
2023-12-17 19:28 -0800 Filip Pizlo                              o wrote a bunch of shit
2023-12-16 16:14 -0800 Filip Pizlo                              o more cool ass shit
2023-12-16 16:05 -0800 Filip Pizlo                              o hit a fun issue
2023-12-16 13:53 -0800 Filip Pizlo                              o even more shit
2023-12-16 10:57 -0800 Filip Pizlo                              o more shit
2023-12-13 11:29 -0800 Filip Pizlo                              o more shit
2023-12-12 19:41 -0800 Filip Pizlo                              o more shit
2023-12-12 19:06 -0800 Filip Pizlo                              o more shit
2023-12-12 13:21 -0800 Filip Pizlo                              o more shit

с таким же успехом можно писать на Java

Практика показывается, что конкретно на Java никто писать не хочет

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

почему что-то нужно портировать?

Как минимум, найдутся любители пихать указатели в int64_t. libfuse такое предлагает, например.

Эх, @Obezyan в бане.

Грусть-печаль. Тут скоро никого не останется.

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

Это про коньяк по утрам?

Тнбе не важно твое образование.

Мне важно моё образование, поэтому я здесь.

Да, я предвзят, и скорее нахожусь на стороне «противников Rust»(это не отражает моей позиции, с моей точки зрения), но это вполне естественно, потмоу что я вижу, что пушится раст по причинам, не связанным с его невероятностью и исключительностью. Я 18 лет как пользователь GNU/Linux и наблюдал истории с pulseaudio, systemd и Wayland, история с Rust больше всего напоминает мне последнюю. (Не хочу сказать, что из Rust ничего не выйдет, что из pulse/systemd/W ничего не вышло, нет.)

Но я хожу по ссылкам, в отличе от тебя. Я тебе в новости на русском написал даже, что такое Yolo-C:

традиционный GCC (расположенный в префиксе /yolo/bin/gcc), так как ядро компилируется в режиме, который автор иронично называет «Yolo-C» (то есть без гарантий безопасности памяти от Fil-C).

Но ты не читаешь. Потому что у тебя горит жепа и религиозный фанатизм в глазах.

Не нужно это никому.

Это нужно тем, кого волнует memory safety. Fil-C даёт возмодность получить гарантии бОльшие, чем дают Rust и Go, без переписывания софта.

Если кому-то важна memory safety для снижения количества уязвимостей и нужен, например, OpenSSL или WebKit — альтернатив Fil-C у него НЕТ.

Ещё раз подчеркну что на rust переходят потому что это ох%нный язык, а не потому что безопасный.

Я полагаю, что на rust, в основном, переходят потому, что его активно пушат. Пушили бы D, писали бы на D и нахваливали бы его GC, а на все аргументы говорили бы: ну пиши @nogc или -betterC. На Python очень многие перешли, потмоу что он прекрасен. Жаль, что не для всего, и теперь имеем что имеем. На C++ переходили, потому что он прекрасен. Жаль, что он так ужасен.

попытка наброса

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

Дыряшникам ничего кроме их дыряшки не нужно и не будет нужно, они даже до lifetimebound дорасти не способны.

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

но достаточно взять любой source based дистрибуив, поменять там CC/CXX заменить на их поделку, собрать, и всё соберётся.

И когда я показал тебе, что так и сделали, что ты ответил?

Россыпь скриптов которая неизвестно что неизвестно чем собирает это совсем не то что я сказал.

Вообще конечно я скорее поверю что чатгпт исправит все ошибки в дыряшечном коде, чем что человек … может написать совместимый memory safe компилятор C.

2023-12-18 19:44 -0800 Filip Pizlo o it compiles, wow

То есть ты начал отрицать реальность и «доказывать», что Filip Pizlo нуб и опозорился. Тебе надо, чтобы красиво оформлено, чтобы уверенно сказано, в корпоративном стиле всё так, желательно со сцены, под аплодисменты.

А зачем платить за рантайме проверки

Но Rust также имеет проверки в рантайме, это так?

, когда можно проверить в compile time и не платить?

Нельзя всё проверить в compile time, чтобы гарантировать memory safety, поэтому rust проверят в rt. Если есть unsafe блок, то там нет ct/rt проверок, это так?

Никакой борьбы с borrow checker нет. Когда опытный программист пересаживается с плюсов на rust, ни одной ошибки от borrow checker он не увидит, потому что и так выполняет бч в голове, зная и понимая время жизни и владение объектов и ссылок на них, и не будет, например, мутировать коллекцию по которой итерируется, или перемещать объект на который есть живые ссылки.

Старая байка про опытных программистов. Программисты лажают, регулярно лажают. Это норма. Это не «плохо» — это реальность.

Известны CVE с ошибками и вне unsafe блоков, прикинь.

Ты решил не отвечать на вопрос, потому что увидел угрозу для своей позиции? Это мы даже о небезопасном ABI не говорили ещё.

Ты глянь видео. Почти 2 часа, да, это сложно. Но там есть именованые чаптеры, мб кусочками посмотришь? То, что дядька говорит по темам, где я что-то понимаю (=думаю, что понимаю), согласуется с моим знанием. То, что дядька говорит по темам, где я понимаю слабо, звучит логично. Я не хочу верить дядьке, если он врёт и мне «нравится» его ложь! Я принёс видео на ЛОР, где много людей гораздо опытнее и умнее меня, которые, я надеюсь, могут скорректировать мои знания.

«Водку надо пить легулярно…» 😀

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

Только в unsafe подмножестве. Например, для разыменования указателя, пришедшего извне. В любом языке это либо невозможно в принципе, либо UB.

пока мы не касаемся моментов, которые выглядят потенциально корректными, а на самом деле таковыми не являются

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

то пенять C++у на счет наличия UB

Пенять цпп нет смысла, это состоявшийся язык. Пеняю на выбор цпп для новых проектов, пеняю Fil-C насчёт наследования этой черты.

вывод этого из «программы компилируются» некорректен.

Невозможно сделать совместимый с Си/Си++ язык, избавившись от UB. Иначе бы это давным-давно сделали.

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

Типа сложения чисел или unwrap-ов в Rust-е?

Пеняю на выбор цпп для новых проектов

А вас кто-то заставляет это делать?

Когда я последний раз про него слышал, у него производительность была в 2-4 раза хуже обычного C. Штука прикольная, когда у тебя есть код на C, который ты не хочешь переписывать, но в то же время хочешь сделать его безопасным. Но явно не конкурент Rust.

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

Этот «недоучка» написал Memory safe iBoot implementation, лежащий в основе самой безопасной ОС. И этот опыт вылился в создание Fil-c. Думается мне, что он на порядок умней всех в этом треде.

Старая байка про опытных программистов. Программисты лажают, регулярно лажают.

Потому им и нужен борроу-чекер, не так ли? Борьба с борроу-чекером - это борьба с собственными ошибками.

Типа сложения чисел

Что с ним не так? Переполнение не является UB, если что, компилятор не начнёт выдавать безумные оптимизации, если увидит что-то вроде if (a+1 < a)

unwrap-ов

Это unwrap-то выглядит невинно? Да его можно буквально grep-ом найти в кодовой базе любого размера. Попробуй так проделать с лайфтаймами объектов в цпп.

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

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

Возможно, тебя уже задолбали этим вопросом, но кто у тебя на аватарке?

Какая-то вампирша. Оригинал тут (pixiv.net). Мне просто понравилась картинка, какой-то истории за ней вроде бы нет.

Переполнение не является UB, если что, компилятор не начнёт выдавать безумные оптимизации, если увидит что-то вроде if (a+1 < a)

Тогда зачем компилятор добавляет проверки в Debug-сборках?

Это unwrap-то выглядит невинно?

Если unwrap-ы не выглядят невинно, то зачем их используют? Чтобы громче падало?

Что с ним не так? Переполнение не является UB, если что, компилятор не начнёт выдавать безумные оптимизации, если увидит что-то вроде if (a+1 < a)

Возможно я не очень понял, о чём ты пишешь, но он буквально это и делает: https://godbolt.org/z/zYrer5oY7 т.е. он просто выкидывает тело условного оператора. Если заменить int a на unsigned a то условие остаётся.

Иными словами компилятор считает, что условие a + 1 < a никогда не является истинным, если переменная a является знаковым целым числом. Хотя, конечно же, на практике это может случиться.

Возможно я не очень понял, о чём ты пишешь, но он буквально это и делает: https://godbolt.org/z/zYrer5oY7

Тов.unCORr говорит про Rust.

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

Иначе бы это давным-давно сделали.

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

Был бы умнее, вуз бы закончил.

КГ/АМ

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

Он его закончил. Он кандидата не получил.

Нормальные сообщения к коммиту для своего фанового проекта, а не вот эти высеры от ИИ с выдуманной деятельностью

• feat
• feat
• feat
• feat
• blabla
• blabla

Особенно если реально там надо поменять две строчки, для фикса надо было.

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

лежащий в основе самой безопасной ОС

Ты хотел написать самого модного зонда?

Безусловно, такие проверки приведут к скачку производительности, что очень понравится писателям критически чувствительных к задержкам приложений. Ну что сказать, ново, оригинально, молодёжно!

Проверки не приведут, потому что это константный оверхед. Приведёт сборщик мусора. А проверки выхода за границы есть также в Rust, хотя там оверхед меньше. Видимо, авторы Rust тоже ВУЗ не закончили.

P.S. Автор где-то декларироал, что язык подходит для real-time приложений? Python вполне себе существует несмотря на паузы из-за GC.

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

Да его можно буквально grep-ом найти в кодовой базе любого размера. Попробуй так проделать с лайфтаймами объектов в цпп.

Особенно приятно грепать падающий unwrap() в зависимостях твоего проекта. Когда ты сам пишешь код, то всё ок. Но когда это говно прилетает по библиотекам, тут просто туши свет.

Тогда зачем компилятор добавляет проверки в Debug-сборках?

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

то зачем их используют?

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

побочный эффект от работы оптимизаторов

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

UB, отключаются ключом

UB нельзя отключить, он либо есть, либо его нет.

Особенно приятно грепать падающий unwrap() в зависимостях твоего проекта.

Конечно, приятно. Сразу знаешь, что не нужно брать эту фигню в зависимости. Куда сложнее с либами на цпп, где не погрепаешь на предмет отсутствующего где положено std::start_lifetime_as.

Ты свой софт стандартом компилируешь? Ну тогда страдай на радость графоманам.

Я компилирую gcc, у gcc UB зависит от опций компиляции. В частности, уже упомянутое if(a+1<a) для signed может устроить UB если включён режим -fstrict-overflow и не может если -fno-strict-overflow. В режиме -fno-strict-overflow знаковая арифметика делается детерминистично как и беззнаковая. Всмысле что signed int32 2147483640+10=-2147483646 всегда и строго.

Ну и конечно же все разумные люди этот strict-overflow всегда выключают. В том числе Линус где-то прямо писал (то ли про неё то ли про аналогичный генератор UB с указателями -fstrict-aliasing) что это вредительская фича компиляторов/стандартов и её следует игнорировать.