Библиотека автора пока еще далека от CMSIS даже, т.к. нет работы с полями регистров (имена, R/W и R/O режимы, битовые маски). И совсем не сравнить с библиотеками на Rust, где для полей регистров на уровне типов указывается, есть ли вторичные эффекты при чтении/записи поля.
Но главное, что вендоры пока даже не пытаются исправлять SVD файлы, т.к. ими никто не пользуется. Перепутанные имена регистров, отсутствующая периферия, или наоборот несуществующая, RO поля, помеченные как RW и т.д.
Мало кто готов спуститься до этого уровня и поправить SVD файлы для нужного чипа. А вендоры не готовы принимать исправления. И пока это не поменяется, не возможно сделать автогенерацию кода регистров, и 99% разработчиков будут продолжать писать на С библиотеках вендоров.
В Rust кстати эту проблему решили тем что написали свой стандарт SVD. Ну и пишут с 0 SVD файлы, что довольно трудоемко, хотя они и выходят раз в 8 меньше файлов вендоров.
А я вам написал, что эти фичи eigen делают невозможным выбор оптимального варианта SIMD. И это в С++, где производительность - объект поклонения каждого программиста.
А вот в Rust выбрать можно, ценой некоторого увеличения кода. При этом нельзя (пока) сделать автоматический выбор, как в eigen.
Но вы упорно отказываетесь обсуждать суть проблемы. Кто же из нас демагог?
И прочитал еще раз. И все-равно мы там обсуждали "другие языки" и GC последние 6 сообщений как минимум.
Пробелмы поставки библиотек в бинарном формате это отдельная проблема. То что в расте это сделать нельзя говорит лишь об ограниченности раста и что он неприменим для вендоров блобов. Хотя скорее всего можно за сишным интерфейсом спрятать реализацию на расте, тогда возвращаемся к той же проблеме.
Разумеется можно:
crate-type = ["dylib", "rlib"]
Будет .so библиотека с кодом Rust без всякого C-API. И для вендоров всё хорошо.
Давайте начнём с того как вендор создаст dll на раст и что вы будете делать с ней?
В dll от вендора на практически любом языке не получится добавить санитайзеры, исходного когда тоже нет. Так что придется поверить вендору что с ней всё хорошо. И полагаться на гарантии компилятора. Например для CSharp я уверен что dll не портит память и не вызовет UB. Для Rust аналогично, если вендор мне ответит что там нет unsafe (разумеется если он не врет).
а что собственно страшного в переполнении signed int и в чем принципиальное отличие от того что в других языках оно defined behavior хотя и делает тоже самое?
А теперь заявляете:
меня мало интересуют синтетические примеры
Похоже вы не читали другие примеры по ссылке. Вычисление хэша строки тоже синтетический пример?
А бесконечные циклы и без переполнения знаковых могут случится и не только в С++
В других языках эти ошибки будет легко воспроизвести и поправить код. А в C и С++ UB приведет к гейзенбагу, который будет наблюдаться раз в год при определенном положении Марса в созведии Козерога.
Линуса значит, вот только то что он согласился на поддержку раста как языка для драйверов ни какого отношения к "не безопасности" C++ не имеет, и его претензии к плюсам в целом мне понятны и в большинстве своём обоснованы , но они опять же ни как не связаны с "не бесопасным кодом"
Речь вообще не про Rust. Его претензии к С++ и С привели к появлению опций в gcc, чтобы можно было отключить некоторые UB ключем компиляции. Ну а про Microsoft и Google вы совершенно случайно забыли ответить.
ты же знаешь что glibc в андроиде на C++ написан? и то что не проблема писать на С++ и иметь при этом внешний апи на C?
ну это только время покажет, эти мантры уже были за последние 30 лет и не раз так что очень слабо верится что что то изменится
Очнитесь и выгляньте наконец в реальный мир. Он совсем не такой как в 2000 году:
Cloudflare целиком на Rust переписались, в исходниках Android его уже столько же, сколько C, AWS несколько сервисов целиком переписали и не останавливаются (и сделали Firecracker целиком на нем, опенсорс менеджер микровиртуалок, на котором работают Lambda и Fargate), с голенга многие тоже переписываются. Я могу дать полный список известных мне проектов, там от MESA до Figma, Vercel и части бэка npm.js репозитория
Компилятор переносит умножение на 0x20000001 на строку выше. Результат умножения оказывается больше чем int max, и он выкидывает условие остановки цикла.
Если вы перечитаете ветку, то мы обсуждали в основном языки с GC. Кроме того речь шла про санитайзеры, причем тут вообще unsafe?
Конкретно в Rust компиляция всего дерева зависимостей идет из исходников со статической линковкой. И cargo build вам выкачает всё дерево зависимостей, грепайте.
Если же dll это обертка над С или С++, или от вендора, то в ней по определению нечего "грепнуть по unsafe", ведь в С++ никакого unsafe нет.
Очевидно что в других языках часть багов не возможна, другая часть приводит к обычному падению с ошибкой и стектрейсом. А доля гейзенбагов, невоспроизводимых в тестовом окружении гораздо меньше.
И это будет работать для всего дерева зависимостей, кроме тех которые обертки над С библиотеками. При этом в большинстве проектов вообще не будет зависимостей от С библиотек.
ну предположим нельзя но, хотя мне кажется можно найти нетривиальные кейсы когда CSharp взаимодействует с какими ни будь ресурсами типа COM, но ценой чего? добавления GC? потерями перфоманса или часовыми плясками во круг borrow checker чтоб он соизволил понять что тут всё нормально?
Вы уж определитесь, GC или borrow checker. Современные GC собирают очень шустро и могут не останавливать потоки для своей работы. Для абсолютного большинства задач это подходит.
Если вам не нравится GC и Rust, выбор довольно мал. Возьмите Zig.
а что собственно страшного в переполнении signed int и в чем принципиальное отличие от того что в других языках оно defined behavior хотя и делает тоже самое?
вот уж чьё мнение меня меньше всего интересует в вопросах "безопасности кода" так это агентства по слежке и созданию 0 day уязвимостей везде где сможет дотянутся.
Мнение Microsoft и Android (Google) для вас тоже ничего не значит? А как насчет Линуса Торвальдса?
в других языках же такого не бывает совсем, привет от Log4j. Но почему то все критически важные узлы чувствительные ко взлому и отказоустойчивости всё равно пишутся на C и С++
Они пишутся по: 1) Историческим причинам 2) Требованиям к FFI: библиотеку должно быть легко подключить к любому языку, так что С, но не С++ 3) Требованиям к памяти: нужно гарантировать, что память в памяти не останется важной информации после освобождения объекта
Но процесс идет, и например Android переписывает кучу своего кода с С и С++ на Kotlin и Java, а небольшие критичные куски на Rust.
Ты либо весь код собираешь с санитайзерами либо ни какой, мне трудно представить как собрать половину так половину сяк.
А мне легко. Просто зависимость лежит в dll, которая предоставляется ОС, или хуже того вендором. И попробуйте туда внедрить санитайзер.
И мы возвращаемся к тому, что вам надо пройти по всему дереву зависимостей и все их перекомпилировать с санитайзерами и другими защитами. И надеяться что ничего не сломается. В моем текущем проекте например 11 прямых зависимостей и 312 всего, нереально.
это какие и в каких что их прям "не может быть"? утечка памяти и ресурсов в целом в языка с GC вроде как не уникальное явление, так же как и выход за границы, обращение к неинициализированным данным, дедлоки и всё остальное.
Например use after free. Пропробуйте вызвать такую ошибку в C-Sharp или Java. Да и в Go врядли удастся.
Ну а уж UB при переполнении signed int я больше нигде не видел.
а в C++ какое то необычное падение и стектрейсы? или оно в случае ошибки берет и сносит ОС? если мы конечно сравниваем языки в одинаковых задачах
В С++ выход за границы массива в лучшем случае вызовет segfault, который расследовать несопоставимо сложнее, чем нормальную текстовую ошибку + стектрейс.
В худшем случае это запортит очень важные данные, которые запишутся в БД, или приведут к уязвимости и взлому. Или к гейзенбагу.
конечно аргумент ведь зачем они тратят усилия на всё это если cчитают C++ таким не исправимым, ну или там есть некий контекст все же, а не просто заявления в стиле "бегите глупцы"
И в зависимостях зависимостей проверяете?) Кроме того наличие тулинга не говорит о степени покрытия.
А баги вышеупомянутые крупные компании находят регулярно. Значит либо у вас уникальный набор зависимостей без багов, либо вы эти баги не замечаете.
Я так понимаю ошибок в 3rd-party на других языках ни когда не бывает?
Очевидно что в других языках часть багов не возможна, другая часть приводит к обычному падению с ошибкой и стектрейсом. А доля гейзенбагов, невоспроизводимых в тестовом окружении гораздо меньше.
Но пока что все эти же компании спонсируют cppcon и активно участвуют в собраниях комитета по стандартизации и развитию c++ и пропихивают свои пропозалы, а некоторые ещё и компиляторы зачем то свои пишут..
А так же спонсируют другие языки, конференции и т.д. Так что это не аргумент.
Придумал хороший пример: вызов в unsafe функции https://doc.rust-lang.org/std/ptr/fn.write.html по не выровненному указателю. В зависимости от архитектуры, данные могут записаться совсем не туда, куда вы ожидаете. И пошло-поехало.. И заметьте, всё это без оптимизаций, а только из-за того что компилятор поверил программисту в unsafe.
если написал уб, компилятор не будет следовать из того, что раз ты так написал, то уб там быть не может
А вот разработчики Rust считают по-другому (и я их полностью поддерживаю):
unsafe only means that avoiding undefined behavior is on the programmer; it does not change anything about the fact that Rust programs must never cause undefined behavior.
Компилятору приходится верить программисту, иначе практически ни одну оптимизацию не возможно было бы провести.
он честно упадёт в ошибку или выдаст неверный результат, а что с этим делать, уже проблема разработчика.
Нет, он может сделать с этим кодом что угодно, в т.ч. потому что Rust компилятор это фронтенд к LLVM. Кроме того описанное вами поведение нигде не гарантируется в документации, и я не представляю как вы пришли к такому выводу.
Но вы так и не ответили на вопрос: как вы в С++ контролируете что зависимости пользуются стайл-гайдами, тулингом и т.д?
И все эти проблемы которые он якобы решает через чур преувеличины и раздуты сообществом растоманов.
Проблемы кем только ни раздуваются: Microsoft, Android, АНБ, Linux и даже Unreal Engine. И они рекомендуют переходить на более безопасные языки в целом, а не только на Rust .
До const-generics сделать что-то отдаленно похожее на eigen в расте было нельзя совсем. Сейчас const-generic тоже могут мало, для поднятия на уровень типов приходится городить такие приколы
Да, const-generics пока все не очень. Надеюсь допилят.
Там сложение создаёт новую матрицу, а для всех симд операций отдельно захардкодены явные методы (если вообще захардкодены).
В eigen автоматически выбирается вариант симд, а в nalgebra нужно явно передать с использованием внешних ящиков. Не могу сказать что способ eigen всегда лучше (хотя он всегда проще), зависит от алгоритма. В некоторых случаях нужно подбирать размер симд операции (например AVX 4,8 или 16 слов) чтобы добиться максимальной производительности. https://www.rustsim.org/blog/2020/03/23/simd-aosoa-in-nalgebra/
Про новую матрицу не понял, поясните.
В nalgebra даже transpose() копирует матрицу, а transpose().transpose() делает две копии. В то время как в нормальном фреймворке эти операции не делают ничего вообще.
Ну это проблема в библиотеке, хз почему не реализовали.
В любом случае, nalgebra это был просто пример того, что библиотеки обычно не переписывают с С и С++ на Rust, а создают новые.
Как раз то что ансейф есть в 1/5 крейтов это ок. Я вам это и сказал в первом сообщении. А все остальные цитаты и выводы из поста что вы привели, - это уже потенциально реклама.
Значит я вас неправильно понял. Думал вы в негативном смысле написали.
то же самое может внезапно оказаться для оставшихся 80%
Но в те времена стандартная библиотека была гораздо хуже, и некоторые сейчас очевидные вещи нельзя было сделать без unsafe. По-этому распределение может быть в пользу пакетов с unsafe, но конечно надо проверять.
Скажите это растоманам которые бегают по гитхабу и создают ишью вида "consider rewriting in rust". Недавно один уникум даже в Qt багтрекере такое создал. Но наверное на созданиях тикетов деятельность по переписыванию на раст обычно и заканчивается =)
Я на Rust пишу с 2018 примерно, но по гитхабу так не бегаю) И я ни разу не видел чтобы переписали какой-то проект целиком на Rust (не исключаю что такое существует). Но видел много новых библиотек, аналогичных по функционалу уже существующим на С и С++, но с другим API. Например eigen в С++ и nalgebra в Rust. Хотя казалось бы математика везде одинакова.
Напомню ветка началась с обсуждения зависимостей. Вы жаловаолись что зависимости на си или си++ это плохо, они могут быть не протестированы санитайзерами, не следовать современным практикам и т п... А теперь оказывается "это обертки над С, но никто не жалуется" :-D
Я сейчас отлистал вверх и не нашел начало ветки от Arenos, похоже он удалил сообщение (пора уже делать скриншоты..). Но он заявлял что санитайзеры и современные практики для него лучше подходят, а компилятор Rust слишком сильно ограничивает. На это я ему и ответил, что
могут быть не протестированы санитайзерами, не следовать современным практикам и т п..
Так что я от своих слов не отказываюсь, а вы их вырвали из контекста. Я считаю что больше гарантий от компилятора это лучше. Но Haskel пока не освоил.
Библиотека автора пока еще далека от CMSIS даже, т.к. нет работы с полями регистров (имена, R/W и R/O режимы, битовые маски). И совсем не сравнить с библиотеками на Rust, где для полей регистров на уровне типов указывается, есть ли вторичные эффекты при чтении/записи поля.
Но главное, что вендоры пока даже не пытаются исправлять SVD файлы, т.к. ими никто не пользуется. Перепутанные имена регистров, отсутствующая периферия, или наоборот несуществующая, RO поля, помеченные как RW и т.д.
Мало кто готов спуститься до этого уровня и поправить SVD файлы для нужного чипа. А вендоры не готовы принимать исправления. И пока это не поменяется, не возможно сделать автогенерацию кода регистров, и 99% разработчиков будут продолжать писать на С библиотеках вендоров.
В Rust кстати эту проблему решили тем что написали свой стандарт SVD. Ну и пишут с 0 SVD файлы, что довольно трудоемко, хотя они и выходят раз в 8 меньше файлов вендоров.
А я вам написал, что эти фичи eigen делают невозможным выбор оптимального варианта SIMD. И это в С++, где производительность - объект поклонения каждого программиста.
А вот в Rust выбрать можно, ценой некоторого увеличения кода. При этом нельзя (пока) сделать автоматический выбор, как в eigen.
Но вы упорно отказываетесь обсуждать суть проблемы. Кто же из нас демагог?
Я вам развернуто написал что на мой взгляд в eigen хорошо сделано, а что плохо. И чего не хватает в nalgebra и Rust.
Вы же просто заявляете "eigen не выразим на расте", и отказываетесь от нормального обсуждения. Вот это неконструктивно.
По этому возвращаю вам обратно:
И прочитал еще раз. И все-равно мы там обсуждали "другие языки" и GC последние 6 сообщений как минимум.
Разумеется можно:
crate-type = ["dylib", "rlib"]Будет .so библиотека с кодом Rust без всякого C-API. И для вендоров всё хорошо.
В dll от вендора на практически любом языке не получится добавить санитайзеры, исходного когда тоже нет.
Так что придется поверить вендору что с ней всё хорошо. И полагаться на гарантии компилятора.
Например для CSharp я уверен что dll не портит память и не вызовет UB. Для Rust аналогично, если вендор мне ответит что там нет unsafe (разумеется если он не врет).
Перечитал. Не согласен.
Ага, бороться с зоопарком систем сборки, когда половина зависимостей настроена на динамическую линковку. Реально, но очень долго.
И все же что вы будете делать с dll от вендора?
Вы спрашивали:
А теперь заявляете:
Похоже вы не читали другие примеры по ссылке. Вычисление хэша строки тоже синтетический пример?
Ну а в реальной жизни полно уязвимостей, вызванных UB переполнения int, раздел Observed Examples
https://cwe.mitre.org/data/definitions/190.html
В других языках эти ошибки будет легко воспроизвести и поправить код. А в C и С++ UB приведет к гейзенбагу, который будет наблюдаться раз в год при определенном положении Марса в созведии Козерога.
Речь вообще не про Rust. Его претензии к С++ и С привели к появлению опций в gcc, чтобы можно было отключить некоторые UB ключем компиляции.
Ну а про Microsoft и Google вы совершенно случайно забыли ответить.
Если вот эта, то там от С++ одно название.
https://ru.wikipedia.org/wiki/Bionic_(библиотека)
Очнитесь и выгляньте наконец в реальный мир. Он совсем не такой как в 2000 году:
Компилятор переносит умножение на 0x20000001 на строку выше. Результат умножения оказывается больше чем int max, и он выкидывает условие остановки цикла.
Если вы перечитаете ветку, то мы обсуждали в основном языки с GC. Кроме того речь шла про санитайзеры, причем тут вообще unsafe?
Конкретно в Rust компиляция всего дерева зависимостей идет из исходников со статической линковкой. И cargo build вам выкачает всё дерево зависимостей, грепайте.
Если же dll это обертка над С или С++, или от вендора, то в ней по определению нечего "грепнуть по unsafe", ведь в С++ никакого unsafe нет.
И тем не менее компилятор Rust иногда размазывает UB по всей программе:
https://hyphenos.io/blog/2023/debugging-ub-unsafe-rust-code/
А вот позиция одного из разработчиков Rust, почему UB это необходимое зло: https://www.ralfj.de/blog/2021/11/18/ub-good-idea.html
Итак я привел вам:
- теорию
- документацию
- реальные примеры
- и даже позицию авторов языка
Вы же пока привели только рассуждения.
Это мы уже обсудили:
И это будет работать для всего дерева зависимостей, кроме тех которые обертки над С библиотеками.
При этом в большинстве проектов вообще не будет зависимостей от С библиотек.
Вы уж определитесь, GC или borrow checker.
Современные GC собирают очень шустро и могут не останавливать потоки для своей работы. Для абсолютного большинства задач это подходит.
Если вам не нравится GC и Rust, выбор довольно мал. Возьмите Zig.
Конкретно в переполнении ничего страшного. Страшно что это UB, а любое UB может сломать программу максимально странным способом: например конечный цикл может стать бесконечным!
Тут есть и другие примеры:
https://github.com/Nekrolm/ubbook/blob/master/numeric/overflow.md
Мнение Microsoft и Android (Google) для вас тоже ничего не значит? А как насчет Линуса Торвальдса?
Они пишутся по:
1) Историческим причинам
2) Требованиям к FFI: библиотеку должно быть легко подключить к любому языку, так что С, но не С++
3) Требованиям к памяти: нужно гарантировать, что память в памяти не останется важной информации после освобождения объекта
Но процесс идет, и например Android переписывает кучу своего кода с С и С++ на Kotlin и Java, а небольшие критичные куски на Rust.
А мне легко. Просто зависимость лежит в dll, которая предоставляется ОС, или хуже того вендором. И попробуйте туда внедрить санитайзер.
И мы возвращаемся к тому, что вам надо пройти по всему дереву зависимостей и все их перекомпилировать с санитайзерами и другими защитами. И надеяться что ничего не сломается.
В моем текущем проекте например 11 прямых зависимостей и 312 всего, нереально.
Например use after free. Пропробуйте вызвать такую ошибку в C-Sharp или Java. Да и в Go врядли удастся.
Ну а уж UB при переполнении signed int я больше нигде не видел.
В С++ выход за границы массива в лучшем случае вызовет segfault, который расследовать несопоставимо сложнее, чем нормальную текстовую ошибку + стектрейс.
В худшем случае это запортит очень важные данные, которые запишутся в БД, или приведут к уязвимости и взлому. Или к гейзенбагу.
Они считают что нужно поддерживать легаси код, но не рекомендуют писать новый на С++.
Вы можете с этим не соглашаться, но странно делать вид, что этих заявлений не было. Вот например от АНБ
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
И в зависимостях зависимостей проверяете?) Кроме того наличие тулинга не говорит о степени покрытия.
А баги вышеупомянутые крупные компании находят регулярно. Значит либо у вас уникальный набор зависимостей без багов, либо вы эти баги не замечаете.
Очевидно что в других языках часть багов не возможна, другая часть приводит к обычному падению с ошибкой и стектрейсом.
А доля гейзенбагов, невоспроизводимых в тестовом окружении гораздо меньше.
А так же спонсируют другие языки, конференции и т.д. Так что это не аргумент.
Пока не выразим. Но напомните мне, через сколько лет в С++ добавили шаблоны?
И вообще это неконструктивный подход. Я тоже могу сказать, что embassy не выразим в С++. Просто потому что системы типов разные.
Придумал хороший пример: вызов в unsafe функции https://doc.rust-lang.org/std/ptr/fn.write.html по не выровненному указателю. В зависимости от архитектуры, данные могут записаться совсем не туда, куда вы ожидаете. И пошло-поехало..
И заметьте, всё это без оптимизаций, а только из-за того что компилятор поверил программисту в unsafe.
А вот разработчики Rust считают по-другому (и я их полностью поддерживаю):
https://doc.rust-lang.org/reference/behavior-considered-undefined.html
Компилятору приходится верить программисту, иначе практически ни одну оптимизацию не возможно было бы провести.
Нет, он может сделать с этим кодом что угодно, в т.ч. потому что Rust компилятор это фронтенд к LLVM.
Кроме того описанное вами поведение нигде не гарантируется в документации, и я не представляю как вы пришли к такому выводу.
Но вы так и не ответили на вопрос: как вы в С++ контролируете что зависимости пользуются стайл-гайдами, тулингом и т.д?
Проблемы кем только ни раздуваются: Microsoft, Android, АНБ, Linux и даже Unreal Engine. И они рекомендуют переходить на более безопасные языки в целом, а не только на Rust .
Вот это уже предметное обсуждение.
Да, const-generics пока все не очень. Надеюсь допилят.
В eigen автоматически выбирается вариант симд, а в nalgebra нужно явно передать с использованием внешних ящиков. Не могу сказать что способ eigen всегда лучше (хотя он всегда проще), зависит от алгоритма. В некоторых случаях нужно подбирать размер симд операции (например AVX 4,8 или 16 слов) чтобы добиться максимальной производительности.
https://www.rustsim.org/blog/2020/03/23/simd-aosoa-in-nalgebra/
Про новую матрицу не понял, поясните.
Ну это проблема в библиотеке, хз почему не реализовали.
В любом случае, nalgebra это был просто пример того, что библиотеки обычно не переписывают с С и С++ на Rust, а создают новые.
Значит я вас неправильно понял. Думал вы в негативном смысле написали.
Но в те времена стандартная библиотека была гораздо хуже, и некоторые сейчас очевидные вещи нельзя было сделать без unsafe. По-этому распределение может быть в пользу пакетов с unsafe, но конечно надо проверять.
Я на Rust пишу с 2018 примерно, но по гитхабу так не бегаю) И я ни разу не видел чтобы переписали какой-то проект целиком на Rust (не исключаю что такое существует).
Но видел много новых библиотек, аналогичных по функционалу уже существующим на С и С++, но с другим API. Например eigen в С++ и nalgebra в Rust. Хотя казалось бы математика везде одинакова.
Я сейчас отлистал вверх и не нашел начало ветки от Arenos, похоже он удалил сообщение (пора уже делать скриншоты..).
Но он заявлял что санитайзеры и современные практики для него лучше подходят, а компилятор Rust слишком сильно ограничивает. На это я ему и ответил, что
Так что я от своих слов не отказываюсь, а вы их вырвали из контекста.
Я считаю что больше гарантий от компилятора это лучше. Но Haskel пока не освоил.