Hacker News Digest

Статья рассматривает проблемы ABI (Application Binary Interface) при обработке ошибок в программировании. Распространённое мнение, что заполнение информации об ошибках "бесплатно" из-за их редкости, неверно. Наивное составление ошибок из алгебраических типов данных (ADT) ухудшает "счастливый путь" выполнения кода. Объекты ошибок, рекурсивно составленные из перечислений, tend to be large, увеличивая size_of<Result<T, E>>, что заставляет функции по всей стеку вызовов использовать возврат больших структур через память. "Вирусность" ошибок означает, что даже одна большая ошибка на редко выполняемом пути ухудшает производительность везде.

Поэтому зрелые библиотеки обработки ошибок скрывают их за тонким указателем, как в Rust (failure и anyhow), но это требует глобального аллокатора, что тоже не бесплатно. Автор предлагает три подхода к возврату результатов: стандартный (как пользовательский тип), более умный (ABI как у T с зарезервированным регистром для E) и радикальный (полное совпадение ABI с -> T и разворот стека для ошибок). Последний, по мнению автора, может быть оптимальным, несмотря на отсутствие надёжных бенчмарков. Вывод: обработка ошибок должна быть специальной для компилятора, особенно в языках со средним уровнем абстракций.

• Адаптивные ABI для статически линкуемых программ могут оптимизировать производительность за счёт контекстного анализа использования функций.
• Проблема "вирусности" больших типов ошибок: даже редкие большие ошибки могут ухудшить производительность всего стека вызовов.
• Альтернативные подходы к обработке ошибок включают тонкие указатели с vtable (anyhow/failure) и разделение Result<T,E> при значительном различии размеров T и E.
• Добавление исключений в Rust вызывает споры: одни видят в этом угрозу производительности, другие — потенциальное решение проблем обработки ошибок.
• Checked exceptions в Java критикуют за необходимость изменения кода при модификации исключений, хотя другие видят в этом преимущество для надёжности кода.

Fil-C - реализация C и C++ с безопасной памятью, позволяющая существующему коду работать безопасно без изменений. Несмотря на молодость проекта и одного активного разработчика, Fil-C уже компилирует весь безопасный пользовательский Linux. Это форк Clang с лицензией Apache v2.0, который изначально был медленным, но после оптимизации работает всего в несколько раз медленнее оригинала. Тест с Bash показал практически незаметную разницу в производительности.

Основная сложность проекта - обработка указателей. Текущая реализация "InvisiCaps" разделяет указатели на доверенную "capability" и недоверенную "address" части, позволяя им соответствовать естественному размеру архитектуры. Для поддержки безопасности Fil-C использует другую внутреннюю ABI, чем Clang, что требует полной перекомпиляции проекта. При выделении объекта в куче Fil-C добавляет два слова метаданных для проверки границ доступа и хранения дополнительной информации о указателях.

• Fil-C — это компилятор C → C, добавляющий проверки безопасности памяти, но при этом оставляющий программы полностью совместимыми с существующим кодом и не требующий изменений в исходном коде.
• Проект разрабатывается в рамках Nix, что позволяет легко собирать любые пакеты с Fil-C, а также предоставляет кэш сборок.
• Обсуждение выявило, что Fil-C в первую очередь ориентирован на безопасность, а не на производительность, и что он не решает проблему безопасности в полном объеме, но является важным шагом вперед.
• Некоторые участники обсуждения выразили обеспокоенность по поводу того, что Fil-C может быть непрактичен из-за производительности, но другие отметили, что для некоторых приложений безопасность важнее производительности.