История изменений
Исправление hateyoufeel, (текущая версия) :
А будет новый LLVM учитывать оптимизацию при чтении освобождённого указателя, она и Rust затронет. Выбор LLVM влечёт за собой багосовместимость с C/C++.
Што? Нет, не влечёт. То, что LLVM написан на плюсах, нифига не означает, что весь код, который он генерит, тоже на плюсах или как-то подчиняется плюсовым правилам по UB. Не пиши уж полной хероты тут, пожалуйста. Все эти преобразования кода вокруг UB происходят во фронте компилятора, то есть в Clang. LLVM – это бэкенд, он про это всё знать не знает.
Исправление hateyoufeel, :
А будет новый LLVM учитывать оптимизацию при чтении освобождённого указателя, она и Rust затронет. Выбор LLVM влечёт за собой багосовместимость с C/C++.
Што? Нет, не влечёт. То, что LLVM написан на плюсах, нифига не означает, что весь код, который он генерит, тоже на плюсах или как-то подчиняется плюсовым правилам по UB. Не пиши уж полной хероты тут, пожалуйста. Все эти преобразования кода вокруг UB происходят во фронте компилятора, то есть в Clang. LLVM – это бэкенд, он про это всё знать не знает.
Дыры чаще связаны не с UB, а с тем, что разработчик не учёл какой-то вариант входных данных и не предполагал намеренно злобного пользователя.
Особенно дыры типа use-after-free, как в сабже.
Исправление hateyoufeel, :
А будет новый LLVM учитывать оптимизацию при чтении освобождённого указателя, она и Rust затронет. Выбор LLVM влечёт за собой багосовместимость с C/C++.
Што? Нет, не затронет. То, что LLVM написан на плюсах, нифига не означает, что весь код, который он генерит, тоже на плюсах или как-то подчиняется плюсовым правилам по UB. Не пиши уж полной хероты тут, пожалуйста. Все эти преобразования кода вокруг UB происходят во фронте компилятора, то есть в Clang. LLVM – это бэкенд, он про это всё знать не знает.
Дыры чаще связаны не с UB, а с тем, что разработчик не учёл какой-то вариант входных данных и не предполагал намеренно злобного пользователя.
Особенно дыры типа use-after-free, как в сабже.
Исправление hateyoufeel, :
А будет новый LLVM учитывать оптимизацию при чтении освобождённого указателя, она и Rust затронет. Выбор LLVM влечёт за собой багосовместимость с C/C++.
Што? Нет, не затронет. То, что LLVM написан на плюсах, нифига не означает, что весь код, который он генерит, тоже на плюсах или как-то подчиняется плюсовым правилам по UB. Не пиши уж полной хероты тут, пожалуйста. Все эти преобразования кода вокруг UB происходят во фронте компилятора, то есть в Clang. LLVM – это бэкенд, он про это всё знать не знает.
Исправление hateyoufeel, :
А будет новый LLVM учитывать оптимизацию при чтении освобождённого указателя, она и Rust затронет. Выбор LLVM влечёт за собой багосовместимость с C/C++.
Што? Нет, не затронет. То, что LLVM написан на плюсах, нифига не означает, что весь код, который он генерит, тоже на плюсах или как-то подчиняется плюсовым правилам по UB. Не пиши уж полной хероты тут, пожалуйста. Все эти преобразования кода вокруг UB происходят во фронте компилятора. LLVM – это бэкенд, он про это всё знать не знает.
Исправление hateyoufeel, :
А будет новый LLVM учитывать оптимизацию при чтении освобождённого указателя, она и Rust затронет. Выбор LLVM влечёт за собой багосовместимость с C/C++.
Што? Нет, не затронет. То, что LLVM написан на плюсах, нифига не означает, что весь код, который он генерит, тоже на плюсах или как-то подчиняется плюсовым правилам по UB. Не пиши уж полной хероты тут, пожалуйста.
Исходная версия hateyoufeel, :
А будет новый LLVM учитывать оптимизацию при чтении освобождённого указателя, она и Rust затронет. Выбор LLVM влечёт за собой багосовместимость с C/C++.
Што? Нет, не затронет. То, что LLVM написан на плюсах, нифига не означает, что весь код, который он генерит, тоже на плюсах.