Организация ISRG (Internet Security Research Group), которая является учредителем проекта Let's Encrypt и способствует развитию технологий для повышения защищённости интернета, представила проект zlib-rs по созданию защищённого аналога библиотеки сжатия данных zlib. Код zlib-rs написан на языке Rust и распространяется под лицензией Zlib. Разработка ведётся с оглядкой на проект zlib-ng, развивающий высокопроизводительный вариант zlib. Проектом разработаны две библиотеки: zlib-rs с реализаций API zlib, не использующей unsafe-блоки; libz-rs-sys - надстройка с поддержкой Си API, содержащая код в режиме "unsafe"...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60970
С си проектами слинкуется?
> libz-rs-sys - надстройка с поддержкой Си API, содержащая код в режиме "unsafe".
Для некоторых, новость полностью читать – себя не уважать
Долго врубался в эту фразу, посмотрел код, оказался Си-интерфейс к zlib-rs
лол, зочем вообще тратить силы на zlib? есть же кое-как написанное, вот пусть и используется как легаси себе потихоньку. тогда было непонятно, а сейчас понятно: нужна низкая задержка/высокая скорость кодека/низкие требования к cpu и памяти? - Берём lz4. Для всего остального zstd.
Для PNG например.
> Для PNG например.WEBP lossless
и для браузера rfc1951 (deflate format)
Есть brotli и zstd
zstd нет много где на клиенте, а brotli и не на всех серверах из каропки
Так как раз удобно начать переписывать на безопасном языке, а оригинал то будет работать и дальше.
а кто вам сказал что переписанное будет без ошибок?мы так когда-то фронтенд переписали на тупескрипт, ошибок меньше не стало, даже больше - появились ошибки типов
Потому что на ЗЛибу завязано много чего, включая сторонние либы.
И если ее выкинуть, то куча всего поломается.
А у нас и так stable anything is nonsense)С другой стороны, никто не запрещает тебе взять lz4 и переписать)
https://github.com/PSeitz/lz4_flex
А существование библиотек miniz и libdeflate игнорируется?
У них есть фатальный недостаток™.
libdeflate это C 92.0% - т.е та же дыряшка только в профиль
тут можно спростить, а "нафига libdeflate если есть zlib", но я в теоремах Эскобара не очень разбираюсьminiz слегка получше, тк там используется с++, и возможно какая-то современная версия.
Но проблему, которую хотят решить создатели zlib-rs, он не решает полностью.
Игнорируется в каком контексте? Переписать их на rust? Ну перепиши. Или взять их вместо переписывания libz на rust? А что, они для этого написаны на rust? Или хотя бы не хрен знает кем, используются более чем в 1.5 игрушечных проектах, аудит проводился?
Пишу на rust по работе. Отличный язык. Но не для обычных программ пока что. Запилить микросервис для раскатки в контейнере на кубе - огонь. Но делать на нём апликухи для юзеров - нет. Пока не будет стабильного ABI, пока crate'ы не будут нормально работать shared object'ам без необходимости иметь по 40 различных версий одновременно, пока std::lib не наберёт достаточной мощи, чтобы отказаться от внешних crate'ов с самыми элементарными вещами - не готово для десктопа. Так же ждём захвата популярных crate'ов злоумышленниками с целью внедрения зловредов.Превращение своего проекта в нечто путём автомагической скачки, не глядя, всех зависимостей и зависимостей их зависимостей, не может в итоге закончиться чем-то кроме помойки (
> пока crate'ы не будут нормально работать shared object'ам без необходимости иметь по 40 различных версий одновременноАхахаха, это реально правда?
Не совсем. Есть поддержка стандартного FFI через C ABI, оно стабильное и с обратной совместимостью. Но на практике работать немного больно, т.к. доступны только примитивы, Box, Option, и ещё пару структур. Но через C ABI это в любом языке так будет.
То есть правда.
То есть, не совсем. Это означает, что частично.
> Не совсем. Есть поддержка стандартного FFI через C ABI, оно стабильное и
> с обратной совместимостью. Но на практике работать немного больно, т.к. доступны
> только примитивы, Box, Option, и ещё пару структур. Но через C
> ABI это в любом языке так будет.Я правильно понимаю, что ты предлагаешь двум нативным рустовым крейтам дружить через сишный FFI? )
как и всё остальное
В общем и целом, сказки примерно те же что с жабой и жс
> Эй, оно же интерпретируемое, оно по определению не может быть дырявым и уязвимым(тм)[для жс. Но годится для обоих]
> Эй, там ведь продвинутое управление памятью и карманный движок того кого надо
> Сам байткод не может исполняться на ЦП, т.е оно в принципе не может содержать дыр
> Ведь он не неограниченно-жирнющий, а его разрабы - не долб**ы(ты)Но вот теперь и раст ещё и компилируемый, героически спасает от дыр в ЯП где дыр точно так же не должно было быть в принципе
Но зачем ?
> Эй, оно же интерпретируемое, оно по определению не может быть дырявым и уязвимым(тм)[для жс. Но годится для обоих]И в чём они не правы? Чтобы сделать уязвимость на жс это нужно постараться. Практически все движки написаны на С++ и существуют давно, но что-то никто не берётся их переписывать на священную ржавчину.
Большая проблема где угодно начинается с JIT в том виде в котором он есть
Это, вроде бы, даёт и серьёзный прирост производительности, но проблема в том, что при желании можно даже под конкретное число тактов проца совершенно конкретные команды подстраивать( ведь заранее известно каков будет выхлоп по коду )Если глянуть исходники того же вебкита, то там обнаружится много интересного. Вплоть до подобий компиляторов под разные железки со своими ассемблерами. И всё начинается с жс
> пока std::lib не наберёт достаточной мощи, чтобы отказаться от внешних crate'овОчень надеюсь что этого не случится никогда. Иначе Раст ждёт участь питона с его огромной стд либой. Сегодня добавляют очень нужную штуку, а через несколько лет она уже никому не нужна, но поддерживать надо, из стандартной библиотеки просто так код не выкинешь
> иметь по 40 различных версий одновременно
Это ты про что? Можно пример?
> ждём захвата популярных crate'ов злоумышленниками с целью внедрения зловредов
Не только конкретно зловреды. Сами авторы могут внезапно превратить пакет в тыкву, по своему желанию.
От этого вообще непонятно как защищаться. Общая проблема для всех централизованных пакетных репозиториев (
> Это ты про что? Можно пример?Чел хочет линковать объектные файлы скомпилированные разными версиями раст компилятора, при этом чтобы структуры у него в коде были помечены как `#[repr(Rust)]`. Ну удачи ждать, чо, такое очень не скоро будет, это очевидно.
Это?https://github.com/rust-lang/rust/pull/114201/
>От этого вообще непонятно как защищаться. Общая проблема для всех централизованных пакетных репозиториевПускать новые версии в _централизованный_ репозиторий только после проверки независимым комитетом? Что-то вроде мейнтейнеров в дистрибутивах, мейнтейнеры репозитория. Тогда, даже если автор сойдет с ума, его диверсия не пройдет дальше его гита.
Просто никаких авторов не будет и всё.
> Что-то вроде мейнтейнеров в дистрибутивах, мейнтейнеры репозитория.А как это решает проблему? Ты начинаешь зависеть от прихоти мейнтейнера.
И от их компетентности, что на верное еще хуже.
Сильно тебе помогли мейнтейнеры в ситуации с xz?
> Сильно тебе помогли мейнтейнеры в ситуации с xz?Ну с xz всё же единственный случай за много лет. И в итоге мейнтейнеры в дистрибутивах оперативно откатили проблемные пакеты и они больше не могут попасть к пользователям. Так что как дополнительный рубеж, вполне может быть работоспособным.
Единственный ставший известным.
> Единственный ставший известным.доказывай.
>> иметь по 40 различных версий одновременно
> Это ты про что? Можно пример?Так чё тут примеров искать? Открой свой Cargo.lock файл и посмотри какие там зависимости зафиксированные. Очень удивлюсь, если у тебя не будет ситуевины, когда один и тот же крейт не будет присутствовать несколько раз. Например, у меня reqwest тянет одну версию крейта h2, а actix - другую. И это я ещё вычищаю зоопарк там, где можно подыграть версии крейтов так, чтобы они от одной и той же версии зависимости зависели. Так-то я как-то видел и по 5 версий одного крейта в Cargo.lock.
Чел про другое писал, походу.Но дублирование крейтов тоже имеет место быть. Я бы его расценивал как "необходимое зло". Всё же больше помогает, чем мешает. К тому же аффектит только скорость компиляции.
Если проект большой, то уже приходится обращать на это внимание, да
> пока std::lib не наберёт достаточной мощи, чтобы отказаться от внешних crate'ов с самыми элементарными вещамиАга, в C++ библиотека достаточно мощна, чтобы не использовать внешние либы. А в C так еще мощнее!
> автомагической скачки, не глядя, всех зависимостей и зависимостей их зависимостей, не может в итоге закончиться чем-то кроме помойки
Лол. Расскажи, как ты устанвливаешь зависимости в проекте на C++?
> Лол. Расскажи, как ты устанвливаешь зависимости в проекте на C++?Руками, осознанно - осёл. И тысячу раз думаешь: действительно это тебе нужно или нет? Выбираешь, проверяешь, решаешь и отвечаешь за зависимости и зависимости зависимостей ты, а не дядя левый, не ИИ.
Динозавры встречаются чаще, чем подобный подход, к сожалению. Обычный dev c трудом представляет, где его код лежит через полгода и что это код делает, про зависимости я просто молчу-)))
И кто мешает растовику тысячу раз подумать, включать ли очередной крейт в проект? И проверить эти зависимости и зависимости зависимостей, как в си/плюсах? И после проверки скачать это в локальный репозиторий и проект подключить только на локальный? И, так же как в си/плюсах, в случае обновлений, снова всё перепроверять и перекачивать в локальный репозиторий?> И тысячу раз думаешь
рассмешил, осел.
В отличие от многих современных языков в C и C++ зависимости - это целая эпопея. Это не строчку прописать в каком-то конфиге. Тут начинаются вопросы о том, как прикрутить. В линуксе с этим несколько проще, так как в роли централизации собственно, сам пакетный менеджер дистра выступает. А на винде тот ещё треш. Не редко в нишевых или не опенсорсных проектах нужные либы вообще в исходниках затягивают к себе в репу, а то и под местную систему сборки. Ещё и падчинг не редкий. Тут хочешь-не хочешь, треть либы само собой освоится
>В отличие от многих современных языков в C и C++ зависимости - это целая эпопея.вот ииенно.
сначала затягивают зависимости недедями, а потом годами боятся снова повторить этот челендж.
и имеем проекты с протухшими зависимостями.
>Ага, в C++ библиотека достаточно мощна, чтобы не использовать внешние либы. А в C так еще мощнее!Как будто это не так. GLibc может всё, на что способно ядро плюс ещё дополнительно засчёт комбинации возможностей системных вызовов.
Сколько софта в твоем дистре зависят сугубо от glibc и ни от чего больше?
>Как будто это не так. GLibc может всё, на что способно ядро плюс ещётак ты это объясни чуваку которому в расте стандартная либа недостаточно мощная
Пакетный менеджер системы, стрононние пакетные менеджеры (conan, vcpkg, xmake и т.д.). Руками можно поставить представь себе. CMake тоже может скачать и настроить проект в качестве зависимости.Что дальше?
> Пакетный менеджер системы, стрононние пакетные менеджеры (conan, vcpkg, xmake и т.д.). Руками можно поставить представь себе. CMake тоже может скачать и настроить ...Ну, вот. Теперь объясни, почему именно с Растом это вдруг стало проблемой.
Единая точка отказа.
>> Пакетный менеджер системы, стрононние пакетные менеджеры (conan, vcpkg, xmake и т.д.). Руками можно поставить представь себе. CMake тоже может скачать и настроить ...
> Ну, вот. Теперь объясни, почему именно с Растом это вдруг стало проблемой.Для меня не проблема, это как бы растовики сам считают проблемой пакетные менеджеры с++. Хотя я думаю растовики ничего сложнее hello world не писал на плюсах.
Мне на карго как человеку который пишет на С++ как хобби все равно :)
> Хотя я думаю растовики ничего сложнее hello world не писал на плюсах.Какие же вы ограниченные. И узнавать что-то, что противоречит вашему маня-мировоззрению, категорически не хотите. Даже жалко вас. Поспрашивай гугловцев, каких "hello world"'ов и сколько у них уже на расте написано. и Их мнения и планы насчет раста.
Первым языком который я изучал как раз был rust. После уже перещел на С++.
Причем тут ограниченность? Причем тут программисты из гугла? Если они хотят избавиться от С++ ну и бог с ними.
Я против раста ничего против не имею. Хороший язык да и пользуюсь терминалом alacritty каждый день.
Меня забавляют растовики которые топят за раст смешивая в одну кучу C и C++. и пишут что чуть ли hello world усыпан UB и течет. И я это замечаю, словно какая-то пропоганда против С++ и С.
> Пакетный менеджер системыWindows. Если только msys2, но там свои приколы.
> conanПервой версии был годным. Очень легко прикручивался почти к любой системе сборке. Во второй дичь нагородили. Ещё и bintray убрали. И вот недавно у друга: cmake + Conan + wsl2. Веселились неделю. Ну, то есть на порядок больше телодвижений.
> vcpkgВ принципе, хорош. Но последний раз, когда использовал, пакетов было маловато.
> xmakeНа сколько помню, это система сборки. К пакетным менеджерам отношения не имеет.
> CMake тоже может скачать и настроить проект в качестве зависимости.Особенно, когда зависимости не на CMake. Всё же мир C и C++ известен своим зоопарком симтем сборки
Но cmake может решить зависимости (скачать, подготовить и собрать).На счет зоопарка это да. Но все же есть пакетные менеджер и без жесткой привязке к одному пакетному менеджеру
>Превращение своего проекта в нечто путём автомагической скачки, не глядяДа еще и антибезопасно
Кстати, как там с симд? Как не взгляну, все висит плашка что симд доступно только в ночных сборках
> без необходимости иметь по 40 различных версий одновременноКаждый решает "ад зависимостей" по своему. Но если возникло 40 версий пакетов в сборке, то явно в зависимостях тухляк, который всё это и тянет.
> Превращение своего проекта в нечто путём автомагической скачки, не глядя, всех зависимостей и зависимостей их зависимостей, не может в итоге закончиться чем-то кроме помойки
И надо исправлять это.
> Превращение своего проекта в нечто путём автомагической скачки, не глядя, всех зависимостей и зависимостей их зависимостей, не может в итоге закончиться чем-то кроме помойки (Про "не глядя" это ты кому в упрёк ставишь? Инструментарию языка или разработчику? По моему это личный косяк разработчика, что он не глядя на зависимости добавляет их в свой проект, а потом ещё и обновляет на новые версии тоже не глядя. Ни какой язык, ни его инструментарий этот косяк решить не способен. Можно всё то же самое делать вручную, и тоже не глядя.
Инструментарий раста позволяет просмотреть все зависимости, зафиксировать их версии и чек-суммы. В итоге получится проект, защищённый от неожиданных обновлений или подмены кода зависимостей на что-то вредное.
> Инструментарий раста позволяет просмотреть все зависимости, зафиксировать их версии и чек-суммыТы не понимаешь, нужно ВИДЕТЬ111
А если серьезно, этот подход без проблем применяется любом языке с пакетным менеджером, хоть в Python, хоть в Go, хоть в JavaScript. Нюанс в том, что местные воины против Раста ни на одном из них не пишут, и потому из новости в новость обоечены повторять одну и ту же чушь...
Да никого из корпов не интересует десктоп, напилил сервисов, наклепал веба на реакте, опционально завернул в Электрон. Современные вычислительные мощности позволяют.
А зачем тебе использовать rust-abi разных версий вообще? Лично я знаю лишь один реальный случай, когда динамическая линковка раст в раст через раст в принципе используется. В bevy можно линковать нутро таким способом. Используется оно для ускорения компиляции и только для дебага. В реальном мире ты скорее хочешь либо статическую линковку, либо c-abi.Жирный std не нужен. Он итак содержит некоторое количество вещей, которых лучше бы там не было по разным причинам (впрочем не критично).
Если у тебя специфические требования к безопасности и нужен аудит зависимостей, то скачиваешь, проверяешь и следишь, чтоб Cargo.lock не менялся. Опять же никто тебе не запрещает всё скачать и в папочку положить, впрочем с этим лучше к психиатру обратиться.
> В качестве причины создания zlib-rs упоминается намерение предоставить вариант zlib, избавленный от потенциальных пробоем, вызванных ошибками при работе с памятьюНо ведь код на расте компилируется компилятором, написанным на C++. Вдруг там ошибки работы с памятью, которые приведут к неправильной компиляции безопасносного кода и вся безопасность пропадет?
Согласен, пусть сначала llvm перепишут.
> Вдруг там ошибки работы с памятью, которые приведут к неправильной компиляции безопасносного кода и вся безопасность пропадет?Предлагаешь сразу писать на C++, чтобы ошибки работы с памятью были в основной программе?
На современном C++ тебе ненужно использовать адресную арифметику. Используй std::vector для массивов, используй умные указатели или лучше только ссылки.
> На современном C++ тебе ненужно использовать адресную арифметику. Используй std::vector для массивов, используй умные указатели или лучше только ссылки.Действительно, как же инженеры из Google и Microsoft не догадались то такого простого и эффективного решения?
Каким образом название компании говорит о квалификации конкретного специалиста?-))
> Каким образом название компании говорит о квалификации конкретного специалиста?-))Ну, то есть, тысячи инженеров, пишущих более двух десятилетий софт на плюсах, оказались тупее опеннетного эксперта с его простым и эффктивным решением? Еще и язык новый придумали - вот идиоты же!
Так инженеры из Google пишут Chrome именно таким образом, а тебя спросить забыли ))
> Предлагаешь сразу писать на C++, чтобы ошибки работы с памятью были в основной программе?А ты предлагаешь все свои косяки списать на с++, с и железо, а раст провозгласить белым и пушистым. Клиентам насрать почему утекли данные. Они утекли из программы написанной на расте и что она там вызывала пох.
> А ты предлагаешь все свои косяки списать на с++Из новости:
> По данным компаний Microsoft и Google около 70% уязвимостей вызваны небезопасной работой с памятью.
Что ты об этом думаешь?
Кстати, да, эти 70% - мои личные косяки. Предлагаю списать их на C++, а Раст провозгласить белым и пушистым.
> Клиентам насрать почему утекли данные.
Хорошо, что разрабочикам не насрать, и они стараются перекатываться на более адекватные инструменты.
> Они утекли из программы написанной на расте
Когда утекли? Из какой программы? Ссылочку можно?
Разве компилятор хруста не сам себя компилирует уже давно?
Фронтенд на расте, а бэкенд - нет.
Если так, то это позор
Потому что каждый, кто пишет свой язык, в первую очередь добивается чтобы этот язык мог скомпилировать сам себя, т.е. написать компилятор на самом себе это такой своеобразный хеллоуворлд для дизайнеров языка
Не позор, а потому что нету смысла. Сейчас много языков компилируют в LLVM-IR: это существенно упрощает разработку компиляторов, и у тебя сразу бесплатно появляется поддержка кучи аппаратных платформ.
> Не позор, а потому что нету смысла. Сейчас много языков компилируют в
> LLVM-IR: это существенно упрощает разработку компиляторов, и у тебя сразу бесплатно
> появляется поддержка кучи аппаратных платформ.позор, позор. сдох llvm - сдох язык. впрочем, от языка у которого нет стандарта - слишком завышенные требования, да.
Отсутствие стандарта не делает язык плохим.
А вот наличие такого овностадарта как у сишки... лучше бы его вообще не было))Вот тут вам в ваш распрекраснейший "стадарт" еще UB напихали linux.org.ru/forum/development/17495219
То что раньше было ID стало UBдо С23
if new_size is zero, the behavior is implementation defined (null pointer may be returned (in which case the old memory block may or may not be freed), or some non-null pointer may be returned that may not be used to access storage). Such usage is deprecatedв C23
if new_size is zero, the behavior is undefined.Еще и обратную совместимость сломали.
> Еще и обратную совместимость сломали.а то у тебя дофига кода которому нужно было ТАК получать null pointer?
> позор, позор. сдох llvm - сдох языкоткрытый код не может сдохнуть - байтики никуда не пропадут.
>> позор, позор. сдох llvm - сдох язык
> открытый код не может сдохнуть - байтики никуда не пропадут.скажи это XFree86.
А что ей сделалось? На том железе и по сей день запустится.А с llvm в этом плане и еще проще, поскольку он куда меньше зависит от шта6ле нонсенсов.
Как работал так и будет. Добавить новую платформу ты к нему конечно не сможешь, ну так ты и сейчас не сможешь.
Сдох LLVM — это как именно? С двенадцатым ударом часов перестанут компилироваться исходники? Ну что ж, печаль, ляжем и умрём все тогда, наверное.
> Если так, то это позор
> Потому что каждый, кто пишет свой язык, в первую очередь добивается чтобыПозор - опять онанимным Ыкспердам, слашавшим звон.
"Компилятор на самом себе" совершенно не означает, что ты должен еще и переизобрести трансляцию в машкод всех возможных платформ.
Впрочем, ыкспрды ни о том, что байткод для LLVM <-> это "машкод для виртуального процессора" не слышали, ни о "чистом" бэкэнде на ржавом типа crane-lift (ест-но, поддерживающего заметно меньше архитектур), но им некогда - комменты сами себя не напишут ...
Компилятор раста 1.68 квалицифирован как безопасный для целей ISO 26262 (ASIL D) и IEC 61508 (SIL 4) https://ferrous-systems.com/ferrocene/
We plan to work on standards like DO-178C, ISO 21434, and IEC 62278 in the future.ждём DO-178C, думаю лет за 15 управятся
Ну так язык молодой, ему меньше 10 лет.
Как раз через 15, будет серьезный уважаемый язык, который используется в ядре и куче других сложных проектов.
А, кстати какие компиляторы СИ и С++ соответствуют этим стандартам?
Если кто-то знает, напишите какие.
> Ну так язык молодой, ему меньше 10 лет.rust edition 2021 вышел в октябре с версией 1.56.0, ему всего-лишь 3 года!!!
> Но ведь код на расте компилируется компилятором, написанным на C++Код на расте давным-давно компилируется компилятором, написанным на расте. С таким же успехом ты мог бы сказать что код, написанный на сишке (включая ++) компилируется компилятором, написанным на паскале (первая версия gcc была именно на нём написана, https://www.gnu.org/bulletins/bull1.txt пруфом, цитирую:
Although I have a portable C and Pascal compiler, it has a serious drawback: it is a very large program, and intrinsically cannot be made smaller. It is also very hard to bootstrap.
The problem is that most of the compiler is written in Pastel, a super-hairy extended Pascal, and it is also the sole compiler for that language. To make it smaller, we must eliminate the hair needed to compile Pastel; then we will not be able to compile Pastel, so it must all be rewritten into C.)
Эти утверждения можно было бы засчитать, если бы rustc на выходе генерировал машинный код, а не LLVM-IR. Но пока что для сборки нужен LLVM, а оно, внезапно, написано на плюсах.
Из таких соображений можно сказать, что все компиляторы, кроме C, написаны на С, т.к. они используют системные вызовы ядра операционной системы, которая написана на С.Компилятор раста написан на расте, а не на LLVM-IR или C++. Имея в наличии только LLVM у вас не получится собрать этот компилятор. Значит ваш вывод не верен. Что бы собрать современный компилятор раста, надо иметь уже собранный компилятор раста. Вероятно более старой версии, но тут проблема "яйца и курицы", которая есть у всех языков и каждый решает её как может.
От того, что компилятор генерирует машинный код для виртуальной платформы LLVM, он не перестаёт быть полноценным компилятором. Даже наоборот, он отлично вписывается в Unix-Way. Делает только свою работ - компилировать программы на Rust. А вот что бы эти программы работали на разных аппаратных платформах, то пускай этим занимается LLVM, который специально для этого и сделан.
> Вероятно более старой версии, но тут проблема "яйца и курицы", которая есть у всех языков и каждый решает её как может.И в самом начале цепочки увидим Ocaml, а не дыряшечку.
> И в самом начале цепочки увидим Ocaml, а не дыряшечку.Я бы скорее всего оптимизировал это тем, что положил в репу уже собранный бинарник со старой версией компилятора (под одну или несколько платформ). Ну и потом периодически обновлял эти бинарники, что бы не надо было делать 10 промежуточных сборок старых компиляторов, для того что бы самый новый собрался.
И написал бы в readme, что вначале было "ничего", а потом бог создал бинарник с компилятором раста.
> Из таких соображений можно сказать, что все компиляторы, кроме C, написаны на
> С, т.к. они используют системные вызовы ядра операционной системы, которая написана
> на С.Довольно опасное заявление. Трансляция - это перевод исходного текста в целевой машинный код. Для чего достаточно двух областей памяти - входной и выходной буфера. Если где-то там ещё вызываются mmap() или read()/write() - это такая мелочь, о которой странно упоминать.
Почему я всегда отстаю от жизни? Наверное я никуда не хочу торопится. Я долго писал на асме и паскале, т.к. паскаль в общем случае более строгий и дружественный язык, плюс под паскаль есть божественные IDE типа Delphi, которые соответствуют идеологии RAD. И вот когда я наконец начал изучать плюсы, все пересаживаются на раст.
только вот никто не пересаживается на раст
> только вот никто не пересаживается на растКак скажешь.
Как скажешь, как скажешь... Тебе виднее. Но... тут гугловцы какую-то чушь порют, немного противоречащую твоей Абсолютной Истине:(конец 2022-го, про раст в Андроид-разработке, кусочек из итогового резюме):
"Migrating away from C/C++ is challenging, but we’re making progress. Rust use is growing in the Android platform, but that’s not the end of the story. To meet the goals of improving security, stability, and quality Android-wide, we need to be able to use Rust anywhere in the codebase that native code is required.
...
As Android migrates away from C/C++ to Java/Kotlin/Rust, we expect the number of memory safety vulnerabilities to continue to fall. Here’s to a future where memory corruption bugs on Android are rare!"("Переход от C/C++ - сложная задача, но мы добиваемся прогресса. Использование Rust в платформе Android растет, но это еще не конец истории. Чтобы достичь целей повышения безопасности, стабильности и качества Android в целом, мы должны иметь возможность использовать Rust в любом месте кодовой базы, где требуется нативный код.
...
По мере того как Android будет переходить от C/C++ к Java/Kotlin/Rust, мы ожидаем, что количество уязвимостей, связанных с безопасностью памяти, будет продолжать снижаться. За будущее, в котором ошибки повреждения памяти в Android будут редкостью!")
(А тут уже современное время, пару недель назад, Ларс Бергстром (технический директор Google)):"Rust teams are twice as productive as teams using C++."
("Команды, работающие на Rust, в два раза продуктивнее команд, использующих C++")Но да, мы поверим двенадцатилетнему эксперту, что гугловцы даже и не подумают о пересаживании на язык, на котором писАть в два раза более продуктивно и программы получаются значительно более безопасными. Куда там тягаться разрабам софтового гиганта и техническому директору гугла с авторитетным мнением 12-летнго эксперта с опеннет.
> ("Команды, работающие на Rust, в два раза продуктивнее команд, использующих C++")В 2.0 раза или в 2.1 раза? Может в 2.2? будь в 2.5, они бы сказали "в два с половиной раза". Интересно, значит может быть и 2.4. Только вот непонятно, они бы округлили до 2.5, или в меньшую сторону до 2.0? Господи, а что если в 1.9? >_<
Знаешь, мне местная секта отрицателей раста напоминает то ли детей из дет.сада, то ли вовку-педофила
И вы, и дети, и вовка-педофил верите, что если вы закроете глаза, то то что вам не нравится исчезнет
Вы отрицаете реальность и хотите жить в своих фантазиях(как и в случае с вовкой для взрослых это признак шизофрении)
А факты таковы, что раст постепенно наступает и те кто не хотят изучать новое рано или поздно останутся наедине со своим ашотом и его принтером, у вас явно закрылось уже окно обучения новому и вы только и способны твердить, что все старое хорошо, а новое плохо
Если честно, то вас даже жалко
Жалкие старички(да, вам 40-50, но вы в башках своих уже дряхлые старики), которые надеются, что если закрыть глаза, то им станет по 18 и х** снова будет стоять
Все? Это фантастика.
К тому моменту, как освоишь плюсы, про раст уже забудут.
Вот это прям жизненная правда получается. За три эона - точно забудут.
(успеет ли он освоить плюсы - не факт, конечно)
Плюсы последних стандартов не проще раста, более того челу, который писал на плюсах в стиле начала нулевых, для полноценного использования С++ 23, к примеру, придется фактически учить язык с нуля.
Бред какой-то пишешь
Никто же не заставляет использовать всё, что есть в стандарте. Там есть разумные и очень полезные вещи, но есть и очень сомнительные. А кроме официального стандарта есть ещё важные дополнения в С++ в компиляторах GCC и Clang. Важно то, что есть самые разные возможности на любой вкус, а что из этого использовать - каждый решает сам, исходя из своей ситуации.
Было бы логичным продолжить с языком Ada. Очень похоже на Pascal. Скучаю иногда по нему.
Чего скучать? В gcc есть актуальный компилятор Ада.
И Modula-2 есть для скучающих по Паскалю.
Не думаю, что имея Дельфи, есть смысл лезть в какие-то плюсы. Тогда уж в C#!
> Код zlib-rs написан на языке Rustне написан, а переписан
Зачем переписывать, если есть vlang и можно транслировать в него? У vlang, кстати, есть некоторые функции безопасности из Rust.
Маркетинг.Переписать на расте для рекламы это легко, а вот когда дело касается разработки нового, человеко-непонятный раст обнажает всю ложь Лёни Голубкова. Но в интернетах да, честные джоны прям всё на расте пишут.
можно вообще на Dafny переписать с доказательством корректности.Rust предоставляет только ограниченное множество каких-то доказательных практик, причём сомнительных и плохо изученных + плюс гора агрессивного маркетинга.
>причём сомнительных и плохо изученныхВ чём конкретно есть сомнения, и как проявляется плохая изученность?
>плюс гора агрессивного маркетинга
А это в чём конкретно проявляется?
> А это в чём конкретно проявляется?Ну, например доходит до полной ...
Когда новости о двух разных проектах на этом сайте в одну новость запихивают.
То что всем нужно и про недоделанную никем неиспользуемую реализацию аналого на rust.
Снова переписывать...
https://github.com/memorysafety/zlib-rs/issues/49 как бы намекает, что от проекта пока есть одно название.
Но хоть CoC написали?
нет, у тебя есть шанс внести свой вклад в ценный проект!
(но readme.md уже таки да!)
Сделано задач 9 из 36. Как бы уже не только одно название
Лишь бы фигнёй страдать: https://docs.rs/deflate
А что, в zlib были какие-то проблемы с утечкой памяти или выходом за границы буфера?
Прочти новость дальше заголовка...
Ну и что там? "избавленный от потенциальных проблем" - т.е. от несуществующих проблем. А в программах на расте "потенциальных проблем", конечно же, нет.
> Ну и что там? "избавленный от потенциальных проблем" - т.е. от несуществующих проблем. А в программах на расте "потенциальных проблем", конечно же, нет.Ты все таки поднатужься еще чуток и дойди до третьего параграфа. Там как раз об уязвимостях в zlib.
Которых конечно же не будет в версии на Rust, совсем-совсем.
Просто ОЧЕНЬ сильно удивлюсь, если их там нет :)
Удивление к делу не пришьешь, добейтесь реальной ситуации, когда память потечет или ошибки появятся, тогда и обсудим.
> Удивление к делу не пришьешь, добейтесь реальной ситуации, когда память потечет или
> ошибки появятся, тогда и обсудим.Ставите на то, что это https://www.opennet.dev/opennews/art.shtml?num=56918 последняя была?
Ну ок.
> когда память потечет или ошибки появятся, тогда и обсудим.Лол, в смысле "КОГДА"?
CVE-2003-0107
CVE-2004-0797
CVE-2005-2096
CVE-2005-1849
...
CVE-2016-9842И это только уязвимости.
Думаешь он какой-то особенный?
Не, жлиб был дыряв как и любой сишный код.
А из прошлого века уязвимости есть?
CVE-2021-3999, которая старше 95 винды подойдёт?
> добейтесь реальной ситуации, когда память потечет или ошибки появятся, тогда и обсудим.Чукча не читатель? Третий параграф в новости...
Только он не отвечает на вопрос. В программах бываю ошибки - спасибо кеэп.
> В программах бываю ошибки - спасибо кеэп.Так это не просто ошибка.
Это классическая тупая ошибка работы с памятью.
Потому что дыряшечники как не умели в память 40 лет назад, так и сейчас не умеют.
Вот и выпрограммировают бесконечные CVE.
> zlib-rs с реализаций API zlib, не использующей unsafe-блоки;А это что?
`https://github.com/memorysafety/zlib-rs/blob/d61889d4a208e82...Вот тут
`https://github.com/memorysafety/zlib-rs/blob/d61889d4a208e82...
получается, переполнения буфера и сегфолты там небезопасны?
https://github.com/Speykious/cve-rs
Тут opennet.ru/openforum/vsluhforumID3/133278.html#28 уже обсудили))Там ниже ссылка на эпичный тред в их гите "а как же заставить его сломаться"
Так что давай, хейтерок, придумай что-то новое.
там чел не разобрал а заменил одну функцию другой, с другой сигнатурой, соответственно и типы получил другие, соответственно и компилятор начал орать на этот тип
Было &'a u8, ссылка, разрешена к использованию без unsafe
Стало *const u8, запрещена к использованию без unsafeЯ смотрел cve-rs, всё вполне логично и основывается почти всё на этом:
`https://github.com/Speykious/cve-rs/blob/ab0d48fd6e2f30a0cc9...В transmute, например, создаются ссылки на один участок стека, но разного типа. С одним типом заносим данные, читаем уже другим типом
> там чел не разобрал а заменил одну функцию другой, с другой сигнатурой,
> соответственно и типы получил другие, соответственно и компилятор начал орать наА ничего, что там не только "свой" тип null_mut использовался, но и transmute - тоже свой?
И намекает он тебе на обсуждение в гите, где целый консилиум собрали, чтобы получить настоящий и рабочий "оверфлоу" https://github.com/Speykious/cve-rs/issues/4
Это вопрос к автору новости/переводчикуУ него
"This repository contains 2 public crates
zlib-rs, a rust implementation of zlib with a safe rust API
libz-rs-sys, an unsafe C API"превратился в
"Проектом разработаны две библиотеки: zlib-rs с реализаций API zlib, не использующей unsafe-блоки; libz-rs-sys - надстройка для использования в приложениях на языке Си."
Вы все не о том рассуждаете. Проекта-то, по большому счёту и нет (кроме названия). Вот цитата со странички, на которую ведёт "главная ссылка к новости":"We're currently seeking funding to complete work necessary to make the initial implementation"
Оценивать это не буду, чтоб не удалили коммент.
Лол) Проорал конечно с этого)
Агрессивный маркетинг языка, теперь вот проект, где фигурирует этот язык явно клянчит деньги...
Мда, жаль(нет)
> Лол) Проорал конечно с этого)
> Агрессивный маркетинг языка, теперь вот проект, где фигурирует этот язык явно клянчит
> деньги...ruffle.rs вон даже и выклянчил. И что? Хватило только на эскопету с кривым стволом, да и к той патронов не найдешь.
В смысли что, им заплатиле. Или Вы думали там Васян субботним вечером под пивасик решил эту растятину вкурить?
А помнишь, как в 70ых(а в совке и в 80ых, помню как шизик придумавший ЕЯП строчил во все журналы по теме статьи, что ему нужно всего миллион рублей и он завоюет все славяноязычные страны своим языком) те кто придумывали разные языки агрессивно клянчали деньги?
Или "это другое"?
Забавно не только это. Забавно то, сколько хейтеров поставили плюсики. Вот оно, счастье. Проект на ненавистном языке не взлетел пока. Разве ж это не повод порадоваться. 🤦
>Проекта-то, по большому счёту и нет"Слона-то я и не заметил." (c) Последние правки были 4 дня назад.
>Вот цитата со странички, на которую ведёт "главная ссылка к новости"
А вот цитата из текста новости: "Проект находится в стадии разработки."
Это они грамотно, а то чего ещё удумале
//! the tests provide good coverage, the purpose of this fuzzer is to
//! discover memory safety issues in the SIMD implementations.
https://github.com/memorysafety/zlib-rs/blob/main/fuzz/fuzz_...погодите-ка, какие такие memory safety issues? O_o
А он мне говорит: "Пейн, я unsafe не вижу". А его и нет...
Осталось только понять - зачем оно?
Очередной писатель, не умеющий читать дальше заголовка?
> Очередной писатель, не умеющий читать дальше заголовка?Спасибо, что представился. Всё ещё сомневаешься?
Это был риторический вопрос. Всё и так понятно, глядя на твои изначальные недоумения.
> Например, в 2022 году в zlib было выявлено переполнение буфера при попытке сжатия специально подготовленной последовательности символов, которое позволяло эксплуатировать уязвимость через передачу специально оформленных входящих данных.Опять в дурке по недосмотру санитары включили инет.
Этому zlib уже лет 25+, и проще раз в 25 лет что то там в нём исправлять чем переписывать.
Я понимаю они бы взяли flash плеер, в котором каждую неделю по 5 зиродеев находили и его переписали, но нет, надо переписать то что проще и что в этом не нуждается.
> Этому zlib уже лет 25+, и проще раз в 25 лет что то там в нём исправлять чем переписывать.Хаха, ее уже 25 лет фиксят, и всё никак недофиксят.
И ничего что та конкретная проблема прожила не меньше 4 лет ("патч с исправлением уязвимости был предложен ещё в 2018 году, но разработчики не обратили на него внимания и не выпустили корректирующий выпуск")?
А либа используется дофига где и работает с сторонними данными в том числе.Это скорее выглядит как закладка, которую фикс которой разрабы сознательно проигнорили.
> они бы взяли flash плеер
Так взяли. Ruffle называется. И прекрасно работает в связке с Flashpoint (проект по сохранению флеш наследия).
> надо переписать то что проще
Так ведь проще переписать то что проще, не?
> и что в этом не нуждается.
Еще как нуждается! в ней дырки по 5 лет живут
Она 25 лет работает без проблем, а всё что там было - мелочи не мешающие никому.
> Ruffle называется.Ну вот и удачи в этом начинании :)
> Она 25 лет работает без проблем, а всё что там было - мелочи не мешающие никому.Боже, как же ты клоун...
Куча CVE с denial of service и code execution - это так "мелочи не мешающие никому".
Ты уже расписывал, что у тебя на компе ничего ценного нет. Вот и сиди на дыренях.
Но таких особенных не так уж много, нормальным людям нужно чтобы их комп не ломали после любого чиха.
У вас как в том анекдоте: "в теории мы миллионеры, а на практике наелись каках".Вы когда начнёте различать теоритические/фантастические истории от того что реально было использовано и причинило вред?
Нормальным людям пофиг, главное чтобы мобила звонила и котиков/порнуху показывала.
Учитывая что вы считаете нормальными тех у кого компы - от нормы вы очень далеки.
>что реально было использованоНу вот бывало, что у наших клиентов бд падала из-за проблем работы с памятью. Не сказать, что часто, однако же инциденты случались. СУБД на Си написана.
>Нормальным людям пофиг, главное чтобы мобила звонила и котиков/порнуху показывала.
Забавные у тебя представления о нормальности.
>Учитывая что вы считаете нормальными тех у кого компы - от нормы вы очень далеки.
И почему же? Подавляющее число бизнес-пользователей до сих пор сидят за компами.
Ну Вам нравится сишная версия библиотеки, так пользуйтесь ей! Вам кто-то мешает? Зачем хамить про дурку? Если Вам Раст не нравится - пишите сами новости про сишку!
> Я понимаю они бы взяли flash плеерНу, они хотя бы попытались...
Вышло вот как-то так: https://ruffle.rs/compatibilityИ ведь эти еще из лучших...
Эмулятор для окончательно сдохшей, давно окоченевшей платформы это как раз подходящая область применения данного языка. И справедливости ради, он даже почти работает.
не сдохшей, а старательно убитой группой лиц по сговору.И казалось бы, да, язык умеющий безопасТно, язык умеющий в вебасм ровно из того же кода что и в нативный бинарь без дополнительных трудозатрат, язык с миллионом библиотек для всего (ненужного) идеально подходит для этого случая.
Если бы он хотя бы "почти работал" ВОВРЕМЯ - наверное флэш никуда бы с сайтов и не делся, просто все заменили бы плагин на эмбеднутую wasm замену.
Но увы... нескучный йезычок оказался настолько чудовищно неудобен, что понадобилось пять лет на это вот ужепочтисовсемокончательнона67%готово. Больше чем у адобы заняло с нуля и в виде плагина под четыре несовместимые платформы.
Насколько я помню историю, адоба купила готовый стартап, а сам флеш начали пилить в конце 90х.И флеш убили не из за дыр, а скорее потому что это был закрытый стандарт который единолично контролировал адобе.
Фактически это означало что это был не свободный рынок а поляна адоба, и стоить на этом бизнес было слишком рискованно.
> И флеш убили не из за дыр, а скорее потому что это был закрытый стандартоткрытый, прикинь, открытый.
У меня до сих пор где-то лежит пдф с описанием формата. А ты думал, они там крутые хакеры а не просто кодеры-на-безопастном? И было аж две попытки запилить открытый плагин - обе никому не нужны, потому что кривое, косое, глючное и падучее (как всегда в этом вашем опенсорсии если чуть посложнее хеловрота и без денег ibm) было нахрен никому не надо при наличии оригинала.Фактически это означало что кто угодно может выложить свои приложения в обход "магазинов".
"В конце девяностых" был другой флэш - с action script v1, он нужен разьве что любителям ретроигрушек. (с ним у них, кстати, пошло лучше, и Language: 95% API: 76% - поэтому эскопета и работает... ну дырка в текстурах, подумаешь. Но это немного не совсем тот веб который мне лично хотелось бы сохранить.)
>не совсем тот веб который мне лично хотелось бы сохранитьИ ты лично что-то сделал, чтобы мир внял твоим хотелкам? Например, денег дал кому надо, ну или сам поучаствовал в разработке? Или всё, как обычно, сидим и ноем, ждём у моря погоды?
>>не совсем тот веб который мне лично хотелось бы сохранить
> И ты лично что-то сделал, чтобы мир внял твоим хотелкам? Например, денег
> дал кому надо, ну или сам поучаствовал в разработке? Или всё,к счастью, пока я изыскивал в дырявых штанах лишние 500 баксиков, которые можно было бы перевести авторам руфля (я тогда всерьез верил что у них получится) - мир обо мне позаботился и людям с неправильными паспортами стало нельзя переводить свои неправильные баксы.
> как обычно, сидим и ноем, ждём у моря погоды?
ну ты еще можешь наслаждаться escopeta.swf
(Но учти, тот лесник явно не на охоту ходит.)
>к счастьюТы же хотел что-то получить, а теперь не получишь. Это счастьем так называется у тебя? Гм...
>ну ты еще можешь наслаждаться
Да меня этот проект не интересует, от слова совсем.
>>к счастью
> Ты же хотел что-то получить, а теперь не получишь.я бы и так получил ровно то же самое недоделанное - но стал бы беднее на $500
> Да меня этот проект не интересует, от слова совсем.
как обычно. Ничего не интересует кроме твоих умных ворот. А когда заказы кончатся - пойдешь винду админить.
А они у тебя с таким подходам - кончатся скоро.
Да, мокро-медиа flesh был конфетка
Радует, что все больше и больше проектов переписывают на безопасные языки
Ну это да, а вот логические ошибки никто не отменял. Лишь бы у Раст разрабов не было иллюзий...
Иллюзий нет у всех, кто хоть раз читал растбук.
Так предельно ясно объясняются какие гарантии даются, а какие нет.
Напр. на memory leak гарантий не дается. И на логические ошибки тоже.
Тгда проще санитайзером по существующей кодовой базе пройти, вон даже у платных есть free-планы для open source.
Хочешь сказать, что сишники настолько беспомощные, что даже это сделать не могут и лажают постоянно? Соглашусь, пожалуй, это действительно можно только новым языком исправить, чтобы отпугивал беспомощных и неспособных даже такую простую вещь, как санитайзер осилить.
А пацаны из Гугла и Микрософт и не знали.