Почему авторы ООП-языков предпочитают пилить костыли для частных plain data классов (dataclass/NamedTuple в Python, data class в Kotlin, record в Java и C#, case class в Scala, Data в Ruby) вместо того, чтобы сделать общий механизм для реализации протоколов/интерфейсов вроде deriving в Haskell?
🤔15🤡6💯4👍3
Forwarded from Programming sucks
The goal isn't to write more code faster. It's to build better software.
(с) https://addyo.substack.com/p/the-70-problem-hard-truths-about
(с) https://addyo.substack.com/p/the-70-problem-hard-truths-about
Substack
The 70% problem: Hard truths about AI-assisted coding
A field guide and why we need to rethink our expectations
💯6👍3🤔1
#prog #rust #rustreleasenotes
Вышла версия Rust 1.84.0! Как всегда, тут только некоторые вещи, а остальное в полных заметках о релизе.
▪️Когерентность — свойство системы типов Rust: для любой наперёд заданной пары трейта и типа существует не более одного impl-а этого трейта для этого типа. Очень важное свойство, которое позволяет генерировать код и не беспокоится, что один и тот же метод будет означать разные вещи в разных местах кодовой базы. Новыйпорешатель трейтов trait solver (нет, не chalk, хотя и вдохновлён им) теперь используется для проверки когерентности. С точки зрения программиста это означает, что компилятор теперь корректно находит больше перекрывающихся impl-ов и корректно различает больше impl-ов, которые точно не перекрываются. Если вы пытались соорудить какую-то type-level фигню, которая не работала из-за
▪️
▪️У трейт-объектов, составленных из
▪️Я уже ссылался на статью про различие place expression. Так как непосредственно разыменовывание указателя не является UB — UB может являться последующая конвертация из place expression в value expression — взятие
▪️Косвенно связанное изменение — добавили линт на образование сырого указателя, который немедленно становится висячим из-за того, что указывает на дропнутое временное значение. Это расширило предыдущий аналогичный линт, который предупреждал о сыром указателе из временной
▪️Как я уже ссылался, касты между указателями и числами имеют на удивлению неоднозначную семантику — главным образом потому, что для корректной оптимизации кода с указателями надо знать их происхождение (provenance), а эта информация при касте из указателя в число теряется, и её потом неоткуда взять при обратном касте из числа в указатель. В стандартную библиотеку добавили API для манипуляции с адресами указателей, которые более явны насчёт того, что при этом происходит с provenance. Подробнее в документации на указатели.
▪️На примитивных численных типах стабилизировали метод isqrt, возвращающий округлённый вниз квадратный корень. Для знаковых чисел этот метод паникует на негативных значениях. Для обработки этой ситуации можно использовать checked_isqrt, который возвращает
▪️cargo теперь может выбирать версии зависимостей, принимая во внимание их MSRV (minimum supported Rust version). Это opt-in, но будет использоваться по умолчанию в третьей версии резолвера зависимостей, которая будет использоваться по умолчанию в edition 2024 (стабилизация в следующей версии!)
Вышла версия Rust 1.84.0! Как всегда, тут только некоторые вещи, а остальное в полных заметках о релизе.
▪️Когерентность — свойство системы типов Rust: для любой наперёд заданной пары трейта и типа существует не более одного impl-а этого трейта для этого типа. Очень важное свойство, которое позволяет генерировать код и не беспокоится, что один и тот же метод будет означать разные вещи в разных местах кодовой базы. Новый
conflicting implementations...
, хотя вроде как должна — попробуйте сейчас. И да, это означает, что ваш код, вероятно, компилировался по недосмотру из-за бага компилятора, как derive-visitor (не волнуйтесь, там код уже поправили).▪️
#[deny(lint_name)]
внутри #[forbid(lint_name)]
теперь работает и продолжает запрещать lint_name
, и нет, это не позволяет переопределить forbid
. Само по себе не очень полезно, но это изменение хорошо для макросов, которые генерирую код с #[deny]
в контексте, где действует #[forbid]
. Предупреждения на это не выдаётся (к моему неудовольствию).▪️У трейт-объектов, составленных из
Trait + AutoTrait
, при приведении теперь можно отбрасывать части, которые не соответствуют авто-трейтам. Например, теперь компилируется этот код:trait Trait {}
fn upcast(x: &(dyn Trait + Send)) -> &dyn Send { x }
▪️Я уже ссылался на статью про различие place expression. Так как непосредственно разыменовывание указателя не является UB — UB может являться последующая конвертация из place expression в value expression — взятие
&raw {, const}
(или, аналогично, addr_of{, _mut}!
) от результата разыменовывания сырого указателя всегда является безопасной операцией. Да, даже если указатель null. Взятие адреса от доступа к полю place expression остаётся в общем случае unsafe
, поскольку это требует, чтобы указатель был в пределах выделенной под значения указываемого типа памяти.▪️Косвенно связанное изменение — добавили линт на образование сырого указателя, который немедленно становится висячим из-за того, что указывает на дропнутое временное значение. Это расширило предыдущий аналогичный линт, который предупреждал о сыром указателе из временной
CString
. В коде отмечается, что у линта пока есть false negative, так что целиком полагаться на это пока не стоит. С другой стороны, там же указаны конкретные операции, которые пока не проверяются, так что стоит ожидать увеличения полноты этого линта в будущем.▪️Как я уже ссылался, касты между указателями и числами имеют на удивлению неоднозначную семантику — главным образом потому, что для корректной оптимизации кода с указателями надо знать их происхождение (provenance), а эта информация при касте из указателя в число теряется, и её потом неоткуда взять при обратном касте из числа в указатель. В стандартную библиотеку добавили API для манипуляции с адресами указателей, которые более явны насчёт того, что при этом происходит с provenance. Подробнее в документации на указатели.
▪️На примитивных численных типах стабилизировали метод isqrt, возвращающий округлённый вниз квадратный корень. Для знаковых чисел этот метод паникует на негативных значениях. Для обработки этой ситуации можно использовать checked_isqrt, который возвращает
None
для негативных значений. У NonZero
этот метод тоже есть, но почему-то только для беззнаковых оборачиваемых типов.▪️cargo теперь может выбирать версии зависимостей, принимая во внимание их MSRV (minimum supported Rust version). Это opt-in, но будет использоваться по умолчанию в третьей версии резолвера зависимостей, которая будет использоваться по умолчанию в edition 2024 (стабилизация в следующей версии!)
👍9❤3🤯1
Forwarded from Таня Дмитриева пишет…
LinkedIn - это Tinder наоборот.
Девушки пишут задротам, а те им не отвечают
😂
Девушки пишут задротам, а те им не отвечают
😂
😁35
Forwarded from Технологический Болт Генона
Опубликован релиз утилиты для синхронизации файлов Rsync 3.4.0, в котором устранено шесть уязвимостей. Комбинация уязвимостей CVE-2024-12084 и CVE-2024-12085 позволяет клиенту добиться выполнения своего кода на сервере. Для совершения атаки достаточно анонимного подключения к серверу Rsync с доступом на чтение. Например, атака может быть совершена на зеркала различных дистрибутивов и проектов, предоставляющих возможность загрузки сборок через Rsync. Проблема также затрагивает различные приложения для синхронизации файлов и резервного копирования, использующие Rsync в качестве бэкенда, такие как BackupPC, DeltaCopy и ChronoSync.
. . .
Для упрощения проверки обновления серверов до новой версии Rsync номер протокола в выпуске Rsync 3.4.0 повышен до 32.
. . .
CVE-2024-12084 - запись за пределы выделенного буфера через передачу некорректной контрольной суммы, размер которой превышает 16 байт.
CVE-2024-12085 - утечка содержимого неинициализированных данных из стека (по одному байту за раз) при выполнении операций сравнения контрольных сумм некорректного размера.
В Rsync 3.4.0 устранены уязвимости, позволявшие выполнить код на сервере и клиенте
https://www.opennet.ru/opennews/art.shtml?num=62557
Rsync contains six vulnerabilities
https://kb.cert.org/vuls/id/952657
ЗЫ Ссылка на твит со скрина
https://x.com/KirillKorinsky/status/1879265433658020062
🥴11👍3🤯1