Комментарии 124
А на чём писать тогда операционные системы, драйвера, программировать микроконтроллеры?
Думаю, за Rust не заржавеет )).
ИМХО, но язык пока не прошёл проверку временем.
На расте без использования unsafe большую часть этого кода писать не получится. А unsafe снимает все гарантии безопасного использования памяти. Какой тогда смысл кроме использования более хайпового языка?
Берем современный C++, выключаем исключения и rtti, обмазываем абстракциями использующими RAII. Бьем по рукам за использование сырых указателей без причины, запрещаем использовать UB, про любой референс задаем вопрос "кто владеет объектом и когда его удаляет?", и получается отличный безопасный для памяти код.
unsafe снимает все гарантии безопасного использования памяти.
Это неправда.
без использования unsafe большую часть этого кода писать не получится
Впрочем, если развенуть это высказывание, то будет много кода без unsafe. Чем меньше уязвимая поверхность кодовой базы, тем лучше.
Берем современный C++
Контроля заимствований и лайфтаймов для ссылок - нет. Запрета на алиасинг памяти - нет. Весь код - потенциально небезопасен. Чтобы с этим всем выжить, выход один:
Бьем по рукам
Отказываемся от автоматизации в пользу когнитивной нагрузки и неизбежных багов.
Правда. Unsafe позволяет разыменовывать сырой указатель. В этот момент любые гарантии памяти исчезают напрочь, потому что для сырых указателей borrow-checker не работает и не должен.
Думать о владении и времени жизни нужно всегда, если речь не идет о языке с GC. Да и там иногда приходится. Это вопрос дизайна и архитектуры. Вот только, без контроля со стороны компилятора, можно просто заложить в код инварианты, которые обеспечивают корректность, соблюдать их, и делать только те действия, которые корректны с точки зрения этих инвариантов. А с контролем, зачастую нужно отрефакторить весь код так, чтобы весьма консервативный и ограниченный компилятор согласился с тем, что с доступом к памяти в нем, на самом деле, все в порядке.
Контроль заимствований и времени жизни — это прекрасно. Но как только появляется долгоживущий стейт, на который нужны референсы из нескольких мест, не дай бог еще и циклические (а на низком уровне, на самом деле, этого весьма дохрена) все превращается в сражение с компилятором и переписывание всего вокруг, пока не получится сделать то, что без контроля заимствований и времени жизни просто работает.
долгоживущий стейт, на который нужны референсы из нескольких мест, не дай бог еще и циклические (а на низком уровне, на самом деле, этого весьма дохрена)
А можете привести конкретные примеры?
В этот момент любые гарантии памяти исчезают напрочь, потому что для сырых указателей borrow-checker не работает и не должен.
Внутри unsafe-контекста borrow-checker продолжает работать для ссылок, например. То есть потенциально небезопасная работа будет ограничена непосредственно этим, скажем, сырым указателем, а прочий код будет под контролем, невзирая на окружающий unsafe.
без контроля со стороны компилятора, можно просто заложить в код инварианты...
с контролем, зачастую нужно отрефакторить весь код так......
То есть идеоматичный код придется писать в обоих случаях.
Вот только думать о владении и времени жизни гораздо проще для небольших кусков кода, а не для всех 100%. Ну если конечно вы не робот, который всё делает идеально. Я вот не робот.
Практика показывает, что компиляторы проверяют код лучше людей, и что ошибаются все люди, независимо от опыта.
Кроме того лучше написать чуть более медленный код, но в котором компилятор автоматически вставил проверки. А 95% тормозов убрать оптимизацией тех самых 5% кода.
Контроля заимствований и лайфтаймов для ссылок - нет.
безотносительно "полезности" и адекватности этих вещей, если начать перечислять чего нет в расте, то можно до вечера тут сидеть
Отказываемся от автоматизации в пользу плуга и тройки лошадей, ул скорее )))
запрещаем использовать UB
Вот бы еще средний программист всегда знал, где у него UB возникают. Все равно что запертить допускать баги. Причем сразу в asm, и заодно необходимость в выскоуровневых языках отпадает.
Прикольно. Вы пишете про отказ от исключений и не получаете за это кучу минусов, как я. Видимо, не под той статьёй высказался)
С плюсами вопрос интересный. Надо, чтобы не программист это отключал, а компиляторы по умолчанию.
Хайп вокруг новых заменителей С не очень понятен. Наверное, тут имеет место простая не компетентность тех, кто принимает такие решения. Взял сишную либу - небезопасно. Обмазал её сверху голанговым интерфейс - все, стало безопасно)
На D и Ada
D и Ada существуют уже давно, и, если бы у них были какие-то действительно весомые преимущества перед мейнстримными языками (а не какие-то "сферические в вакууме") с точки зрения, так сказать, конечного разработчика, то индустрия бы давно их широко использовала без всяких там указивок от американских бюрократов. Но этого не случилось - Ada еще кое-как используется, да и то в основном теми, кто пишет софт для американского Минобороны (ведь это именно оно профинансировало его создание в свое время, так что деваться некуда), а D вообще "забытый ныне язык, некогда подававший надежды".
Да, но нет. Как видно на примере Rust, в качестве действительно весомого преимущества там прежде всего воспринято то, что он самый новый. В индустрии в принципе есть некий культ новизны и невротическая боязнь остаться позади, потому и.
В качестве примера того, что если кто надо скажет сверху, то пойдут и сделают, есть пример замены ObjC на Swift; там, правда, помогает то, что я выше написал про Rust.
Что касается Ada, то там есть всё то, что есть в Rust -- ссылки/указатели с временем жизни и неплохой borrow checker, в Ada/SPARK посильнее, чем в Rust будет, а еще встроенные в язык экторы (которые рантайм может превратить в аналог горутин), да и мейлбоксы с каналами несложно организовать, пакетный менеджер, деструкторы при поддержке компилятора, ну и так далее. Есть даже некоторые реализации примитивного GC, правда, в Ada он нужен куда реже, там компилятор достаточно умен, чтобы гораздо свободнее протаскивать локальные переменные. В принципе, его можно воспринимать как более безопасный Си, как и D, просто он не модный.
В качестве примера того, что если кто надо скажет сверху, то пойдут и сделают, есть пример замены ObjC на Swift; там, правда, помогает то, что я выше написал про Rust.
Apple, конечно, "продавил" использование Swift, так сказать, командно-административными методами, но лишь в рамках собственной экосистемы. За пределами этой экосистемы Swift практически не используется, он (по крайней мере, на данный момент) так и остался всего-навсего нишевым языком, не сумев пробиться в мейнстрим. Впрочем, и его предшественник ObjC тоже был нишевым по большому счету.
Именно из-за этих тенденций с указами правительства Apple тоже начала суетиться и уже форсят в swift мультиплатформу.
Они её давно "форсят", свифт под линупс уже лет 8 как есть, под винду поменьше, года 4, но не взлетает каменный цветок без админресурса (а если для взлета чего-то необходим админресурс, то это, в общем-то, нехороший признак). Году в 2016 были ещё мрии, что свифт станет first-class языком для Android по аналогии с iOS, но опять же не взлетело.
Rust, Haskell, Idris, Agda...
На FORTH 🤣
Глупому вопросу - глупый ответ!
А может тут как раз про бизнес системы, её пишут более грамотные спецы, проверяют лучше, это сильно не тоже самое, что бизнес система, которую пишут индусы без контроля. А потом хакнуть её гораздо проще. Звучит вполне здравомысленно, если все под это не грести.
А "Правительство США" нельзя было в заголовке написать? Кликбейт наше все?
Из заголовка я решил, что речь про Россию и не понял что будет с ПО под астра линукс сэ
Это все равно, что говорить парикмахерам какими ножницами они должны стричь клиентов))) Маразм в правительствах по всему миру только обостряется)
А я кстати говорю... Ну т.е. я говорю "ножницами а не машинкой", но если бы я предпочитал конкретный тип ножниц, то и их бы просил, почему нет.
Следующая стадия - приносить инструменты с собой. Дальше - стричься самому (цирюлю, кстати, себя машинкой).
Вы ж не правительство. Вот если правительство будет говорить, чем вас стричь...
Но при этом государство через СанПиН обязывает парикмахеров дезинфицировать инструментарий:
9.17. Для предупреждения распространения парентеральных гепатитов, ВИЧ-инфекции, туберкулеза, а также других инфекционных и паразитарных заболеваний, проводится дезинфекция рабочих инструментов по режимам, эффективным в отношении возбудителей этих инфекций.
9.17.1. Зажимы, бигуди, колпаки и сетки для химической завивки волос, шапочки для мелирования моют под проточной водой с моющими средствами.
9.17.2. Расчески, щетки, ножницы для стрижки волос моют под проточной водой, дезинфицируют в бактерицидных излучателях, зарегистрированных в установленном порядке и имеющих инструкцию по применению, или в растворах дезинфицирующих средств.
9.17.3. Съемные ножи электрических бритв протирают дважды (с интервалом 15 минут) тампоном, смоченным 70° этиловым спиртом.
Так это обычно просто разные услуги за разный ценник. И заодно отвечая на комментарий выше: правительство для того и существует, чтобы "говорить парикмахерам, какими ножницами стричь". Вопрос только в том, чем обосновано такое вмешательство. Левой пяткой или тем, что какой-нибудь вид ножниц там чаще приводит к порезам. (Аналогия условна, понятно)
бывают клиенты которые хотят только горячие ножницы
Не совсем. Это как говорить парикмахерам вместо опасной бритвы использовать джилет.
интересно через сколько лет "внезапно" выяснится, что кто то финансово заинтересованный и связанный с неким языком rust проталкивал эти идеи
Угу, там и Microsoft с C# и Oracle с Java трутся где-то рядом
Вся эта популярность Rust, проталкивание его везде где можно и не можно. То очень на то похоже.
А почему бы и не проталкивать, если плюсы не хотят развиваться быстро и в нужном направлении?
А может плюсы развиты сколько надо и сверх того, просто культура программирования и написания кода упала ниже плинтуса. Вся эта хрень с заменой МИТовских и Стенфордских хардкорных программистов на дешевых забугорных индусов (собирательно) ради экономии на зп видна невооруженным взглядом на Вин11 и прочем современном ПО. Проблема не в ЯП, проблема в бюрократии, "эффективных менеджерах" и кривых руках.
А может не развиты. Чтобы понять, развиты или нет, достаточно взглянуть на новые фичи в стандартах. Всё отстаёт лет на 10 от других языков, хотя нет никакой проблемы взять лучшее из других языков, а худшее объявить deprecated и сделать так, чтобы программист мучался, пытаясь подключить фичи, которые опасны и без которых легко обойтись. Отдельный идиотизм - вкручивание костылей в язык, которые потом либо выпиливаются (сборщик мусора), либо получают более понятную альтернативу (SFINAE и концепты)
По вашей логике Ассемблер ещё более развитый. Позволяет абсолютно всё. Смысл новых языков программирования наоборот в том, чтобы программист не пытался контролировать всё на свете. Так что здесь проблема конкретно в том, что позволяет ЯП из коробки.
По поводу настоящих или не очень, я каждый день вижу код, который был написан в 90-х так называемыми настоящими программистами (я по всем приметам не настоящий). И по инерции эти "настоящие" до сих пор пишут на плюсах в сишном стиле, не освобождают память правильно (привет проекту gutenprint, он же gimp print), не знают, что float нельзя сравнивать без приближения (привет всё тому же проекту). Надо меньше сидеть на месте и ворчать, аки старый дед, а больше развиваться.
а вы пробовали на rust писать код с системными вызовами? А какой-нибудь lru cache на rust написать без Ref<Box<<<<<<<<<<..... >>>>>>>>>>>?
Хотябы это уже ставит под сомнения его безопасность. Не говоря о борьбе с компилятором, когда невозможно из-за концепции владения/заимствования вообще без костылей дописать код в уже существующем коде.
Не знаю как там в OS. Но я, например, пишу под микроконтроллеры (stm32, esp32, nrf), которые на несколько ступеней ниже операционной системы. Весь код построен на прерываниях, DMA и RTOS.
Так вот, на Rust код превосходит С++ по всем параметрам: читаемость, безопасность, библиотеки, инструменты. Достаточно упомянуть простой факт: драйвер для конкретного датчика на Rust ровно один универсальный, подходит для любого семейства микроконтроллеров (см. https://github.com/rust-embedded/embedded-hal). На С++ же полный зоопарк.
Справедливости ради, год назад в библиотеках было похуже. И текущая отличная ситуация - это из-за отсутствия старого кода и обратной совместимости с ним.
Насколько я знаю, для stm32, esp32 драйверы от производителей написаны на си, а не на с++. Это касается и cmsis, и hal, и espidf с rtos.
На rust даже высокоуровневые библиотеки не полностью реализованы для всех семейств перечисленных контроллеров. А api очень агрессивно менялся в разных версиях, что приводит к поломкам при обновлении крейтов.
А что касается linux, я ради интереса написал на мерзком с++ код, использующий прерывания /dev/rtc и аналогичный на безопасном rust. На rust код так и не осилил настройку частоты прерывания и его корректное использование. Но зато там была пачка unsafe. На с++ код завелся сразу. Это пример из личной практики.
Насколько я знаю, для stm32, esp32 драйверы от производителей написаны на си, а не на с++. Это касается и cmsis, и hal, и espidf с rtos.
Есть другие реализации на С++, например Platformio. От производителей пишут на С для совместимости.
На rust даже высокоуровневые библиотеки не полностью реализованы для всех семейств перечисленных контроллеров.
https://github.com/embassy-rs/embassy
Часть высокоуровневых библиотек вынесены в отдельные репозитории, например https://github.com/esp-rs/esp-hal
А api очень агрессивно менялся в разных версиях, что приводит к поломкам при обновлении крейтов.
Как он может меняться, если эти библиотеки реализуют трейты из embedded-hal? Может вы вспоминаете давние времена, когда embedded-hal был версии 0.3?
А что касается linux, я ради интереса написал на мерзком с++ код, использующий прерывания /dev/rtc и аналогичный на безопасном rust. На rust код так и не осилил настройку частоты прерывания и его корректное использование. Но зато там была пачка unsafe. На с++ код завелся сразу. Это пример из личной практики.
Вы не правильно понимаете безопасность в Rust. Работа с прерываниями на любом языке будет unsafe по своей природе. Над этим кодом в любом языке надо писать safe обертку, и использовать её из прикладного кода. Rust просто дает инструменты, которые разделяют эти 2 этапа.
Мой пример из личной практики: драйвер тепловизора для async/await, работает по прерываниям через интерфейсы I2C и SPI. Запускал на Raspberry Pi4, кросскомпиляция на amd64 делается ровно 2 строчками (сравните с С и С++).
На весь проект 3 unsafe. Можно и без них, но будет лишнее копирование картинки. Впрочем возможно в std уже что-то завезли, и сейчас можно без unsafe.
Так у вас не драйвер один, а api. Внутри в любом случае будет проверка на партномер мк.
Это то же самое, что сказать - язык arduino лучше c/c++, язык простой, драйвер один на огромное число мк
Всё таки пройдите по ссылке embedded-hal и прочитайте что это.
Внутри в любом случае будет проверка на партномер мк.
В драйвере нет никаких проверок на партномер МК, ему вообще без разницы какой МК, и даже без разницы архитектура ARM это или RISC-V.
Пример такого драйвера: https://github.com/copterust/mpu9250. Обратите внимание на зависимости. В них ничего нет про МК и библиотеки для него:
[dependencies]
embedded-hal = "0.2.3"
bitflags = "1.0"
libm = { version = "0.2.1", optional = true }
Это то же самое, что сказать - язык arduino лучше c/c++, язык простой, драйвер один на огромное число мк
На с++ можно было бы сделать так:
1) абстрактный класс с методами работы с SPI например - аналог embedded-hal
2) реализацию этого класса для esp32 - аналог esp32-rs
3) драйвер для датчика MPU9250, в который передается ссылка на абстрактный класс из п.1
В итоге будет точно также один драйвер на любой МК и архитектуру.
Это то же самое, что сказать - язык arduino лучше c/c++, язык простой, драйвер один на огромное число мк
За цать лет в С++ этого не сделали и, вероятно, уже никогда не сделают. Я не знаю, что помешало. Вероятно просто не смогли договориться про общий универсальный API.
А в Rust уже есть, работает, и пишется много нового кода (я не призываю переписывать старый код).
HAL это как раз абстрактный уровень, не привязанный к МК.
Вы понимаете как периферия в МК устроена? В разных МК периферия устроена по своему, она висит на разных адресах и биты в адресах везде устроены по своему.
Как я понял, низкоуровные либы тут, каждая под отдельный МК:
https://github.com/rust-embedded/awesome-embedded-rust
А по поводу, есть ли на C/C++ некий общий драйвер: как пример Zephyr RTOS, оно вроде как более менее живое.
Вообще потуг было очень много, но они просто особо никому не нужны оказались, такие вещи неплохи для домашних поделок, но в ответственных решениях или сами пишут или уже есть своя внутренняя экосистема
HAL это как раз абстрактный уровень, не привязанный к МК.
Вот именно. Но в С и С++ почему-то в каждом HAL свой API.
Вы понимаете как периферия в МК устроена? В разных МК периферия устроена по своему, она висит на разных адресах и биты в адресах везде устроены по своему.
Понимаю. По-этому под каждое семейство МК написана своя реализация embedded-hal, о чем я писал выше.
А по поводу, есть ли на C/C++ некий общий драйвер: как пример Zephyr RTOS, оно вроде как более менее живое.
Прямо на сайте у них написано "750+ Boards Supported". Остальное не поддерживается, например любая кастомная плата. И в 99% случаев нужно делать именно кастомную плату.
Вообще потуг было очень много, но они просто особо никому не нужны оказались, такие вещи неплохи для домашних поделок, но в ответственных решениях или сами пишут или уже есть своя внутренняя экосистема
А как же переиспользование кода? Разве не лучше чтобы было 1-2 драйвера на гитхабе, которые пилят всем миром. Чем 1-2 на каждое семейство МК (итого штук 20), каждый со своими багами.
Вы либо за "повторное использование кода", либо против, уж определитесь.
P.S. То что в мире С и С++ на МК не прижилось "повторное использование кода" не говорит о том, что сам принцип плох.
Нет, дело именно в плюсах. Это настолько кривой язык, что на нём практически невозможно писать безопасно, даже если очень хочется
Почитайте Джоэла Спольски как раньше учили НАСТОЯЩИХ программистов (а не дешевых кодеров) и какие вещи эти программисты придумывали. MapReduce ни один современный кодер на питоне не придумает, в принципе. Там другой уровень серого вещества нужен.
Ну, одни дегенераты уже доигрались с "зелёным переходом", сделав свое производство неконкурентоспособным, удачи и этим с такими начинаниями, бгг.
P.S. А когда подобные баги на "безопасных языках" встанут на поток, бюрократы напишут очередные бумажки составят очередные дорожные карты по переходу на очередные "чудо-языки", которые, конечно же, уж в этот-то раз точно решат все проблемы на свете.
Скорее всего, это очередная диверсионная деятельность. Как тот закон о коровьем выхлопе, например, который фактически похоронил животноводство вряде стран... А учитывая, что за США инициативы повторяют многие страны - так вообще красиво выходит: у себя мы строгий закон приняли, но в одобреных барином конторах следить за его исполнением не будем, зато за всеми остальными следить будем пристально, блокируя их работу.
мне вообще иногда кажется что весь этот зоопарк языков развели или разводят специально чтобы отучить весь мир от исходных С/С++. На них продолжит только микрософт работать так как ему можно, он очень давно работает на них, ему можно доверять. И микрософт будет всем остальным ИДЕ написанные на С++ продавать недорого. Как говорил один мой американский коллега: "У нас много работы, мы всем нужны. Все замечательно."
Ведь Си-подобный псевдо код у них даже в стандартах получил распространение.
У микрософт уже в ядре есть части написанные на rust )
New Windows 11 build ships with more Rust-based Kernel features
---
ну и то что они в целом про rust говорили
Microsoft: Rust является 'лучшим шансом' в отрасли программирования безопасных систем / Хабр
Microsoft переписывает код ядра и некоторых библиотек Windows на языке Rust. Но зачем? / Хабр
Microsoft постепенно переходит с C/C++ на Rust для создания своего инфраструктурного программного обеспечения. И вдохновляет других гигантов индустрии программного обеспечения задуматься о том же.
Опять же может цель то именно в этом: "вдохновлять других", мы же не знаем. А для этого надо демонстрировать некоторую активность. Потом чтобы написать ИДЕ под Раст придется что-то понаписать на Раст.
В Android еще в 2022 году 21% нового нативного кода писали на Rust (сейчас больше). Тоже чтобы просто "вдохновлять людей"?
про Андроид я не знаю, про ХармониОс у меня вот такая информация. Они, вроде как, родственники были на каком то этапе.
Ваша ссылка только дополнительно подтверждает правильность подхода.
Белым по черному написано, что баг исправлен путем переписывания unsafe блока на нормальный.
Если ты разрабатываешь критически важный софт, аудит зависимостей даже сейчас является обязательным требованием.
Делать аудит usafe кода когда он выделен явно очевидно проще.
Ctrl+F unsafe и погнали.
+100
Пожелание-то благое, но ничто не помешает всё в unsafe запихнуть... :)
Такая регуляция хуже самой глючной программы. От этого ПО будет еще глючнее. Намного.
А аргументы будут или это опять голословное утверждение?
Проектирование комитетом никогда до добра не доводило. Стандарты – да. Регулирование – нет. Проектированием безопасности должны заниматься инженеры. Какие еще аргументы?
Как минимум потому что при переносе логики на другой язык будут возникать ошибки. Возможно, это будет настолько дорого и забагованно, что даже нецелесообразно
Таки шо, линукс всё?
автомобиль тоже средство повышенной опасности, надо тоже запретить, куда смотрит правительство?
Мдас… хорошо хоть не приказали, на сколько дюймов погружать управляющие стержни в активную зону. Сложно управлять тем, в чём ни хрена не разбираешься :-D
Но я вот не берусь сказать, «как надо», потому что управляемая система слишком сложна для того, чтобы её одной барской указивкой улучшить. Даже будь на месте «барина» — я. Интересное дело получается, потому что дурак с инициативой свою инициативу протолкнёт, а понимающий человек — нет, потому что осознаёт адскую сложность этого всего. А они такие «мы сотворим ритуал обеспечения безопасности и всё станет безопасно». Менору надо или своя есть?
Тут не всякая комиссия поможет, тут целый институт нужен. Причём не сертификаты раздающий и не за соблюдением ритуалов следящий, а реально работающий над предметом. Откуда у них вообще эта больная идея, что основную опасность представляют промахи индекса мимо массива? Основная опасность — неверная модель объекта управления. Большинство техногенных катастроф из-за того, что идеально написанный код управляет совсем не тем, чем он, как он думает, он управляет.
Ну прямо как они сами, чесслово.
А я поддерживаю, они не говорят что использовать, а говорят что НЕ использовать и почему. Ничто не мешает, в теории конечно, собраться комитету по стандартизации це и це++ и принять измения в языке которые сделают их хотя бы безопасней чем сейчас, а в идеале достаточно безопасными. И внезапно, тогда никто не будет против использования этих языков. Это прекрасный анальный зонд в головы представителей комитета который показывает чем именно им нужно заняться на следующих митингах и самое прекрасное в этой истории они уже начали этим заниматься.
Изменения в стандартах вокруг безопасности памяти + жёсткие требования по дорожным картам заставят вендоров наконец то перейти с це++11 сразу на какой нибудь це++29, а иначе тюрьма. Это ли не благо?
Изменения в стандартах вокруг безопасности памяти + жёсткие требования по дорожным картам заставят вендоров наконец то перейти с це++11 сразу на какой нибудь це++29, а иначе тюрьма. Это ли не благо?
Повышение безопасности кода еще можно было бы назвать "благом" (причем понятие "безопасности" - это не только и не столько "безопасность памяти", но и всякие RCE в результате insecure deserialization, command injection, чем особенно славятся всякие "безопасные по памяти" скриптовые языки и т.п., да и банальных ошибок в логике работы типа TOCTOU тоже хватает), но само по себе требование "перейти с це++11 на язык X", пусть даже в роли X выступает условный "це++29" - это, честно говоря, не выглядит как благо, а выглядит как чисто формальная подмена цели средством, и не факт, что годным.
P.S. Не удивлюсь, если все вообще сведется к наличию правильно оформленной бумажки с дорожной картой класса "ишак, шах или Ходжа" "у кого надо", обладатель бумажки сможет брать заказы у барина, а остальные желающие - нет. И это в лучшем случае, я вон выше не просто так вспомнил про "зеленый переход", а другой коллега - про "закон о коровьем выхлопе".
P.P.S. Чтобы не быть голословным, приведу небольшой пример. Вот некий гражданин решил переписать стандартную юниксовую утилиту whoami на "безопасном языке раст". Безопасность памяти и все такое. Но внезапно сбылось это. Причем если бы этот гражданин писал на C, и просто взял бы описание этой структуры из системного хедера вместо использования своей доморощенной структуры, то ничего подобного бы не произошло.
Это прекрасно, вы уже давно записались в хейтеры раста - это ни для кого не секрет. Я так и не понял в чем конкретно вы обвиняете Раст в этом случае? Вы хотите сказать, что использование не правильного хидера в православной сишечке по щучьему велению внезапно не приведет к проездам по памяти? Это конечно же смешно. Да щас вы начнёте крутить свою шарманку по 100500 кругу Раст придумали квадроеберы и он не нужен. Ну раз вам не нужен то проходите мимо не задерживайтесь. Вам то вообще какое дело до того что там в пендостане эти убогие говорят? Вам лично кто запрещает пользоваться чем хотите?
Раст великолепен, у него много своих проблем, но заявленные проблемы безопасности памяти он решает прекрасно это не значит, что это вершина мысли и нельзя лучше или без тех ограничений что в расте. Подобные заявления пендоских силовиков важны т.к. очень серьезно стимулирует правильных людей в правильном направлении.
Оставьте хаджей с баринами скрепной России это там такая традиция, а у этих после прошлой подобной стимуляции уже в це++26 таки приняли бан на неинициализированные переменные. Дебаты на эту тему я помню ещё 10 лет назад смотрел на Ютубе и пока их конкретно так не вжучили надежд на эти изменения просто не было. Одним уб меньше и на этом никто не собирается остановливаться, на очереди сабскрипт и т.д. Это и есть причина почему переход с копролитов на современный стандарт зачастую автоматом фиксит то, что раньше было уб ценой небольшого замедления.
Без изменений не бывает улучшений, ваша позиция - надо просто писать правильно, а не правильно не писать - не работает и никаких изменений не предполагает поэтому в принципе ничего улучшить не способна. Ананизаторы что статические, что рантаймовые бесполезны для выявления проблем. Статические просто несут чушь в 99% случаев поэтому надо либо отдельного товарища который сможет это фильтровать либо как у большинства всем пофигу на это. Я тыщу раз видел как вносятся изменения что бы тупо заткнуть глотку компилятору что бы он не ругался БЕЗ решения самой проблемы на которую он жалуется. Рантайм хоть полезен когда уже проблема вылезла, но не помогает предотвращать новые проблемы. Другими словами все другие способы уже перепробовали - не работает.
Одним уб меньше
Тут один убавят, там пару добавят, ибо оптимизации. Так что "звери - не аргумент".
Я так и не понял в чем конкретно вы обвиняете Раст в этом случае?
Я никого ни в чем не обвиняю, а просто демонстрирую, что "переписыввние с языка X на язык Y" не означает автоматически само по себе никакого увеличения "бизапастности", скорее наоборот. А знаете, что самое смешное? Вместо того, чтобы научиться на своей ошибке и применить какой-то кодген, гражданин в качестве "решения проблемы" просто воткнул "специальный случай" для illumos рядом с остальными доморощенными структурками. То есть, буде его творение запущено на ещё каком-то флаворе unix (назовём его условно huesOS), где структурка опять будет отличаться, но в какую-нибудь другую сторону, то опять получится молчаливый попил чужой памяти.
Вы хотите сказать, что использование не правильного хидера в православной сишечке по щучьему велению внезапно не приведет к проездам по памяти?
В "православной сишечке" в данном конкретном случае простое использование системного хедера решает проблему на 100% вне зависимости от системы, да.
Оставьте хаджей с баринами скрепной России это там такая традиция
Ну, ясно.
Раст придумали квадроеберы
Такого я ещё не слышал, но, раз вы так говорите... :)
В "православной сишечке" в данном конкретном случае простое использование системного хедера решает проблему на 100% вне зависимости от системы, да.
Ну тут уже проблема прямой совместимости Раста с Сишкой. И по сути, если они запилят нормальный interop, то этой проблемы не станет.
Вроде не так давно Сишное Linux Comunity жаловалось, что они сами не будут править эти самые структуры в расте. Кароче цирк
использование системного хедера решает проблему на 100%
Расчехляйте вашу магию, готов посмотреть какой вы Гудини - что насчёт так сказать кросс компиляции. В данном случае платформа таже, а вот ос другая. Если вы собирете бинарь на одной оси и запустите его на другой то будет то же самое оно будет "работать" и кораптить память. Это как раз зоопарк сишных хидеров и есть суть проблемы. Я не знаю где живёт и есть ли вообще центральная репа этой сишной утилиты, но очевидно различия в структуре полей нужно описать в этом центральном хидере и заифдефить их. А так получается в каждой оси свой клон, т.е. по факту другое приложение и то что в сишешчке конкретно в этом месте работает замена хидера на правильный это просто везение. Это как я щас возьму напишу свою прекрасную ось реализую какой нить метод не так как все, но совместимо по АБИ, а потом приду к вам с претензией чей-то ваша утилита у меня не работает, я ж ей даже правильные хидеры указал и даже пересобрал у себя, странно будет не правда ли? Я к тому что правильные хидеры тоже ничего не гарантирует если семантика не верная, а не верная она потому что я свой клон сделал зависимостей, а предьявляю претензии вам.
Я прекрасно понимаю почему чел впарил ифдефы и забыл про проблему - генерация ффи не бесплатная и в общем случае не гарантирует тоже ничего. Если у него все и так работало без генерации то ради одной странной ОС добавлять ее не разумно. Вылезут ещё одни такие альтернативно одаренные со своим видением прекрасного ну вкатит ещё один ифдеф после нового бага делов то. Я бы сказал это вообще совершенно нормальный процесс портирования, точно такой же как и в сишечке.
Я у себя делал генерацию там много граблей и подводных камней.
Такого я ещё не слышал, но, раз вы так говорите... :)
Я тоже раньше такого не знал, вот выучил новое модное молодежное слово применяю по возможности :)
Расчехляйте вашу магию, готов посмотреть какой вы Гудини - что насчёт так сказать кросс компиляции. В данном случае платформа таже, а вот ос другая. Если вы собирете бинарь на одной оси и запустите его на другой то будет то же самое оно будет "работать" и кораптить память. Это как раз зоопарк сишных хидеров и есть суть проблемы.
Так в этой растоутилите и без какой-либо кросс-компиляции все поломано. Тупо собираешь непосредственно на целевой ОС, просто "неожиданной", и получаешь сегфолт.
Я не знаю где живёт и есть ли вообще центральная репа этой сишной утилиты, но очевидно различия в структуре полей нужно описать в этом центральном хидере и заифдефить их.
Аналогичная сишная утилита просто использовала бы системный хедер pwd.h из /usr/include (ну или если говорить про кросс-компиляцию - то из /usr/include соответствующего библиотечного дерева для target platform), вот и все. И сразу имела бы структуру правильного размера непосредственно из первоисточника.
А так получается в каждой оси свой клон, т.е. по факту другое приложение и то что в сишешчке конкретно в этом месте работает замена хидера на правильный это просто везение.
Какое же это "везение", это стандартный способ работы с платформозависимыми типами - все берется из системных хедеров. Например, time_t из time.h кое-где 32-битный, а кое-где 64-битный. В сишечке просто подключается "местный" time.h из /usr/include и используется time_t оттуда, код типа:
#if defined(TARGET_BOLGENOS)
typedef int32_t time_t;
#elif defined (TARGET_HUESOS)
typedef int64_t time_t;
[...]никто в здравом уме не пишет. А этот гражданин делает у себя именно это.
Это как я щас возьму напишу свою прекрасную ось реализую какой нить метод не так как все, но совместимо по АБИ, а потом приду к вам с претензией чей-то ваша утилита у меня не работает, я ж ей даже правильные хидеры указал и даже пересобрал у себя, странно будет не правда ли?
Какая же тут "совместимость по АБИ", если набор полей в структуре, которую этот метод использует, разный на разных платформах? Такую совместимость никто не обещал.
Если у него все и так работало без генерации то ради одной странной ОС добавлять ее не разумно. Вылезут ещё одни такие альтернативно одаренные со своим видением прекрасного ну вкатит ещё один ифдеф после нового бага делов то.
А еще говорят, это "мемори ансейф" языки во всем виноваты :) Да с таким подходом к написанию портабельного кода вообще ничего не поможет. И это еще хорошо, если баг обнаружится более-менее сразу, а не будет тихо пилить память в ожидании своего эксплуататора.
Я бы сказал это вообще совершенно нормальный процесс портирования, точно такой же как и в сишечке.
Неа. "Совершенно нормальный процесс портирования" в сишечке предполагает использование хедеров из целевой платформы по максимуму, а своих каких-то доморощенных ифдефов - по минимуму.
Я у себя делал генерацию там много граблей и подводных камней.
Ну что тут скажешь... This is very unfortunate :)
Эээ... а ядро Linux тоже надо срочно переписывать?
лучше бы обязали выпускать обновления ОС для телефонов хотя бы 6 лет
А вариант исключительно один - это Rust? Ни Go, ни Java, ни C# использовать нельзя?
Я сразу понял, что в комментах будет жарко :) Но
CISA открыла период общественного обсуждения своего руководства до 16 декабря 2024 года. Пожалуйста, посетите Федеральный реестр, чтобы оставить комментарии.
пошел смотреть комменты туда, а там их всего 38шт :(
Да мы "гусские" больше обеспокоены безопасностью америки :)
Карго-культ "надо всё переписать" выходит на новый уровень)
критически важное программное обеспечение должно отказаться от C/C++ к 2026 году
Ммм, не совсем.
У компаний есть время до 1 января 2026 года, чтобы составить планы по обеспечению безопасности памяти <...> отсутствие опубликованной дорожной карты по обеспечению безопасности памяти к 1 января 2026 года опасно и значительно повышает риск для национальной безопасности
К 2026 году компании должны придумать как они будут отказываться от C/C++ в течении неопределенного времени.
А там или шах помрёт, или cpp2 зарелизят, или Safe C++ в стандарт завезут.
Возможно добавят доп проверки для работы с памятью в статических анализаторах, уже что то. Ту же встройку и за 10 лет не перепишешь, там же все таки суровые ограничения по памяти и цене железок.
Вот тут шла речь о дискетах, я долго думал, что вообще можно сделать в критически важной ж/д инфраструктуре сравнимое по надёжности — и вот что-то как-то очень трудно придумать что-то, что столь же сложно свалить какой-нибудь пандемией autorun-вируса. Дыры везде находят, и чем глубже они зарыты в реализации сто сорок пятой абстракции тридцать козлятого стандарта, тем они внезапнее и труднее их устранить.
А какая-нибудь атмега, читающая расписание с пятидюймового флопа, в принципе произвольный код исполнять не умеет. Прочитала, вывела на сегментный дисплей, контрольную сумму сравнили со стикером на флопе — и попробуйте эту систему каким-нибудь обновлением мастдая или дырявым уефи уронить. Да хотя бы даже нарочно её уронить попробуйте…
А сейчас эту встройку кааак переведут на модные, стильные, молодёжные SoC, без всяких ограничений по памяти и цене, в которых вместо одной точки отказа будет десять тысяч, любая из которых рушит всё и сразу…
Если они не умеют обеспечивать безопасность памяти в Сях много лет уже как — то им немножко нечего делать в критической инфраструктуре.
Я в своём первом проекте после института повесил микроконтроллер динамической аллокацией строки сообщения — сразу научился так больше не делать.
Не, ну мой софт и по сей день можно повесить неудачными данными на входе — но такое я позволяю только в инструментальном софте, который должен максимально много сказать о системе. Ему не дозволяется только зависать при определённых неисправностях вместо диагностики. После выдачи достаточной информации для ремонта — пусть хоть что делает.
Правда, я уже давненько не видел, чтобы он вис/падал — но никаких особых мер против этого не предпринимал.
—————————————————
На самом деле там штука стрёмная с этой памятью… вот пришёл пакет данных от датчика, датчик неисправен, заголовок больше всей оперативки, контроллер повис, Стояджер погиб. Плохо? Ужасно. Что надо делать? Ну уж наверное не механически защищать массив от выхода за пределы! Что там в этой куче дерьма от неисправного датчика? Что будет, если мы механически защитим массив, не задумываясь, что там вообще приводит к выходу за пределы? Да то же самое. Шлёпнем его об Луну.
Мой опыт говорит, что это всё в 99% случаев — опасное лечение симптомов и маскировка проблемы. Да, надо защищать важные модули от разрушения их кода и данных каким-то сглюкнувшим маловажным модулем. Это может помочь. Но это — 1%. Остальные 99% — ситуации, которых просто надо не допускать, проверив данные и значения до того, как начали что-то с ними делать. Иначе даже спасённая память ничем нам не поможет, будет как в «Луке М…» — «п… спасла, зато башка с дырою», пардон за мой французский. Или причиной был глюк в коде — но мы всё равно мертвецы с таким кодом, он не даст нам правильные результаты, без которых мы врежемся в Луну. Или причиной был отказ железа — но мы его вовремя не диагностировали, доверились битым данным и произошло то же самое. Оставшиеся ситуации, когда глюк был в коде кофеварки, и она испортила код управления реактором — да, там бы защита памяти помогла. Хрен с ней, с кофеваркой, сдохла и сдохла, зато реактор жив.
Но процент кофеварочного кода в критическом программном обеспечении настолько ничтожен, что таких случаев — один процент от общей массы. И тут пришла указивка градусникам никогда не показывать больше 37.2, тогда никто не будет болеть %) идиёты…
Любой язык опасен, так как можно сболтнуть лишнего. Даже если поотрезать все языки остается проблема с языком глухонемых! То есть следующий этап отрезать руки :(.
Как страшно жить!
Rust for linux Rust for USA
Замечательно -- пусть сперва кончатся, переписывая всё на ржавчине, а затем сдохнут, пытаясь успеть за сырым языком (ну или выследить и посвязывать тех, кто его "развивает" без малейшего понимания того, чем живёт прод).
C/C++ это стандартные языки, без них только на вообще не безопасном ассемблере писать, или Питоне. Linux че как там? Брехня все это...
С/C++ требует хорошо обученных специалистов с достаточно высокой оплатой труда, это не уровень школы и Python. Так как в США постоянный кризис, видимо у них банально нет денег и других условий нанимать такое количество специалистов которое нужно. Вот они и хотят перейти в более простую и дешевую игру. И да, конечно за это кто-то заплатил - там вообще не бывает в коммерческой сфере, что бы просто так кто-то такие движения совершал в информационном пространстве. Cue prodest - это точно просто кому-то выгодно, у C/С++ в отличие от Java нет корпорации которая бы могла лоббировать что-то, а есть просто открытое глобальное сообщество состоящее из разных элементов, в том числе из комитета по стандартизации. Но в мире с C/C++ они ничего сделать не смогу, это базовые системные языки. Альтернативой может быть ассемблер - но он слишком муторный и еще менее безопасный.
Lisp не?! XD
Да у них там очередная кампания - https://habr.com/ru/news/842994/
В начале августа Управление перспективных исследовательских проектов Министерства обороны США (DARPA) анонсировало проект TRACTOR (Translating All C to Rust) для разработки программного транслятора для автоматического преобразования проектов на языке C в представление на языке Rust. В рамках проекта TRACTOR планируется улучшить качество автоматического перевода кода с языка C на Rust, задействовав методы машинного обучения для достижения уровня результирующего кода на Rust, близкого по стилю и качеству к коду, написанному опытным программистом, и использующего, когда это возможно, безопасные методы для работы с памятью без включения блоков и функций, помеченных ключевым словом unsafe.
Предполагается, что развиваемый транслятор TRACTOR позволит решить проблему с безопасностью старого кода на языке C и избавиться от потенциальных уязвимостей, вызванных небезопасной работой с памятью и неопределённым поведением.
Fil-C - компилятор для языков C и C++, гарантирующий безопасную работу с памятью
В комментах там кстати правильная мысль проскочила - Fil-C можно использовать для отладки и выявления проблем, а потом перекомпилировать на C\CPP.
Есть еще пара интересных проектов:
https://github.com/GaloisInc/ivory
https://github.com/leepike/Copilot
Если раст настолько наше все, почему для него так мало литературы? Например если посмотреть на амазоне в разделе Computers & Technology, для:
Rust Book results 389
Go Book results over 10,000
C# Book over 3,000 (явно надо еще добавлять всякие net.core и т.д.)
C++ Book over 7,000
Java Book over 9,000
Python Book results over 10,000
На наших маркетплейах тоже шаром покати: книга с крабом 2018 года, с боксером 2023, в этом году добавился медвед. Все.
Для языка на котором вот вот "все перепишем" и существует он уже давно, как то очень тухло.
Это больше похоже на эпопею с электромобилями, все туда кинулись, дсв позапрещали, теперь сидят в убытках и света впереди не видно.
Публикации
Правительство США: критически важное программное обеспечение должно отказаться от C/C++ к 2026 году