> Поэтому используете раст, где сплошные сказки про безопасность,

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

> а реальные механизмы сводятся к профанации?

А таки у сей есть слабые стороны...
1) Те доперли до данных фиксированой ширины. А не "int" е...чий! В сях этот рак вклинился очень глубоко. Поэтому в макросах, enum и проч возникает много вопросов "какой реально тип данных будет?!" и "безопасна ли такая математика вообще?". Особенно если учесть определение "int" в стандарте.
1.1) Благодать с НОРМАЛЬНЫМИ типами вроде uintXX_t - на макросы и enum не распостраняется! По крайней мере в цивильном и контролируемом виде.
2) integer promotion в си работает совсем не так как представляло себе большинство кодеров. Почему это должно быть через такой @нус для меня загадка. А ваш код переживает -Wconversion без единого варнинга? Скажите честно!
3) UB. Извините но в си это за гранью добра и зла, стандартизаторы упростили жизнь себе в ущерб остальным. Даже wrap "int" - ub?! Потому что было минимум 2 формата хранения signed? А сам "int" - что угодно, от 16 битов и далее со всеми остановками? И сколько кода готово все возможные варианты "int" без фаллаута схарчить?! Примрено нисколько?! Круто! А мы точно хотели такие стандарты и такой код? Потому что он разваливается от тыкания палочкой.
4) Переменная типа "enum" в си жрет любой хлам. Даже зачастую без варнинга. Круто, но можно это и получше сделать так то.
5) В сях аннотации массивов весьма декоративные. В функцию можно с кормить func(arr[10]) но реально это - указатель. Без малейшего намека на bounds checking. Продвинутые анализаторы в принципе могут поспорить с этим но по дефолту это так не работает и аннотация смысла не имеет. Можно через struct сделать - но тогда это крайне неэффективно будет.
6) Struct в си кстати отдельная боль. На уровне апей и абей профачено все что можно профачить. Поэтому если вы мечтали о структурированом апи, да еще с предсказуемым аби - забудьте. Хотя затрахавшиеся люди все равно стали нормальные апи с "struct" делать. Потому что неструктурированные апи без аннотации намерений кодера ведут к багам.
6.1) Битовые поля в оных. Это грабледром. Код который генерят компилеры ужасен. А определено это так что можно получить более 9000 грабель. Ряд кода на это кладет и все равно юзает. Потому что все остальные способы еще ужаснее. За это он становится непортабельным и этот арбалет - с термоядерным наконечником стрелы. Эта обугленная косточка - пятка кодера который пытался перенести сие на соседнюю платформу. Не прокатило.
7) Даже самый крутой статический анализатор не знает что вы намеревались дать в void* и было ли это валидно, и не порушит ли это память. Узнать это можно только рантайм чекерами типа asan, делающими из сей долбаный дотнет. А в математике указателей можно прострелить себе пятки более 9000 разных способов.
7.1) Сишники повернуты на сабмите неструктурированного хлама в функции и поэтому аргументы не подлежат какой либо автоматической проверке. Что ведет к морю багов.
7.2) И возврате такого же хлама. С тем же эффектом. В си вообще нельзя вернуть 2 значения по простому. На самом деле, правда, struct это позволяет. Но за это вас проклянут по линии ABI.
8) 1, 1U, 1UL и 1ULL это 4 довольно разные вещи. А 01 вообще - октальное число. Как и +/- 0 в плавучке. И граблями это может #%нуть мама не горюй.
9) Половину stdlib сей стоило бы запретить к использованию. Особенно олдовые функции работы с строками и неудачно сделанную аллокацию памяти где то забывают освободить, то дважды освобождают, то юзают после этого - и ничего хорошего конечно же не выходит.

...за последнюю неделю я зашиб минимум 2 ошибки работы с памятью (unchecked alloc) и чЮдную математику сабмитящую (в который раз!) в массив отрицательный "int" как индекс.

> О да, поэтому надо использовать раст, который разрабатывало 1,5 специалиста и орава
> студентов во время учебы.

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

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

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

>> И просто для понимания, по состоянию на сейчас в линух домерживают последние
>> оставшиеся патчи проекта RT_LINUX. Которые, как вы понимаете, совсем не для красоты.
> Как раз для красоты. Раст вызвал бурю негодования, а Линус как обычно
> решает проблему методом выживания -

RT_LINUX к раст не относится - но намекает что линух очень хотят юзать для управляющих систем толпа народа. Я один из таковых. А раст... некоторые кодеры ядра полагают что он им позволит лепить меньше багов и писать более читаемый и майнтенабельный код. И они имеют определенный пойнт.

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

Торвальдс и вся его шайка таки заинтересованы в отсутствии багов и неплохой работе своего кода. Я это вижу. И с сями это приблизилось к своим лимитам. В силу особенности конструкции сей. С11 немного улучшает это но - лишь маргинально. А у кернела есть более 9000 собственных костылей для компил-тайм чеков, воркэраундов сишной идиотеки и много чего еще. Это не значит что нас не задолбало i++'й раз изобретать вел с квадратными колесами.

> Только хруст не избавляет от багов, а только добавляет их.

Ну, пока он еще не в форме чтобы это делать. А его проблематика применительно к вон тому - еще не понята. Так что я не буду настаивать что он годен для critical систем. Но у него есть предпосылки есть ряд вещей сильно лучше чем си. А в сях эти проблемы кажется никто так и не будет решать.

>> В этом месте дидам надлежит познать тао antibug coding - или уйти.
> Так дедов нет уже. Не пишут они уже код. Деды это вы.

Нет, вон тот код с вон тем качеством - оставили таки мои предшественники. И я имею кое-что против такого уровня качества кода, такого структурирования апи, и проч. Потому что можно намного лучше. Но с сями это тяжко. Вплоть до того что if (i = 10) в сях может прокатить. И даже без варнингов если не повезет. Это ляп сразу на уровне дизайна конструкции ЯП.

> Для начала antibug coding должен быть читаемым, а не быть изотерическим ЯП
> с магическими символами из...начала двухтысячных.

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

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

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

>> Как исправивший ряд вулнов в их чудном коде говорю.
> Осталось дождаться пока ваше чудное исправление кто-то посмотрит и найдет в нем баг.

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

> И все это человеческие проблемы, которые раст может решить примерно никак.

А таки - какой-нибудь borrow checker или нормальные типы целых здорово снижают предпосылки для багов. На сях тоже можно сделать ряд забавных вещей - см что в рассылке сделали с GUARD для мутексов (почти RAII-style из плюсов но на сях). Однако уповает на гнутый экстеншн, в стандарте дефера для cleanup при выходе из видимости нетути. И вот так - в 20 раз меньше вариантов как облажаться с мутексом. А если его наимно попробовать как обычно в си - вот там можно откушать от души. И откушают.

> Только вот UB это по сути unsafe для разработчиков компиляторов. Но unsafe
> в расте это "модно и необходимо", а UB в си это "деды понаписали".

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