видимо придется доклад править 🙂

Я был. Но разве он может поймать обращение не за границами стэка, а когда объект умер и на его месте уже новые данные лежат?

может. там есть вариант с карантином

Да я тут как раз скачал себе; они ещё улучшили remote debug on *nix

Попробую добавить этот момент в доклад

хм. Интересно. Спасибо, пойду поищу инфу об этом.

Это неверно. Если я знаю все ограничения платформы и явным образом соблюду контракт - эта функция становится полностью safe на конкретной платформе.

Моя основная задача тут - не дать коду скомпилироваться на платформах, контракт которых я не соблюл

а откуда ты знаешь, что ты знаешь все ограничения платформы?

есть гарантии языка, а дальше уже идет личное фантазирование и системное программирование.

так то да, если мы под конкретную систему и компилятор пишем, то UB это не только плохо, но и очень даже хорошо. потому, что в этом случае мы не пишем на С++, мы пишем на конкретном диалекте под конкретную платформу. если мы что-то не учтем (например, что добавилась вот такая вот оптимизация в бэкенд компилятора), то можем очень сильно огрести.

Ну, в идеальном мире ситуация примерно такая:

1) Самые низкоуровневые вещи (интринсики) предоставляют разработчики компилятора. Они уже ковыряются в деталях конкретной железки и бекэнда к ней.
2) Разработчики стандартной библиотеки под каждую из платформ пишут safe-обёртки, полагаясь на то, что разрабы компилятора не обманывают.
3) Core-разработчики проекта используют то, что предоставили люди из п.1 и п.2.
4) Обычные разрабы используют то, что выдали им Core-разрабы

В чём, собственно соль - если что-то пошло не так, нужно заглянуть лишь в unsafe функции/блоки кода в стеке вызовов, потому что только они могли что-то сломать.

И легче понять кто косячнул.

ну, тут как бы то есть UB же не только в чем-то для чего могут быть интринсики. тот же например ODR violation.

или если просто в памяти ковыряешься

вот есть у тебя объект в памяти, и для какой-нибудь платформы ты просто таки знаешь где там будет лежать rtti для него например. ну, или думаешь, что знаешь. и ходишь в ту память. а бац - а нету там того, но есть что-то другое.

Да, но ты знаешь кто виноват! Область поиска - unsafe функции/блоки. Просто ищешь все, а потом ищешь те, что используются в той области кода, которая у тебя сломалась)

это при условии, что ты выявил этот дефект на этапе тестирования

поскольку тут UB, то стрельнуть оно может в проде

при редком стечении обстоятельств

и будет очень хорошо, если приложение крашнется хотя бы

Ну, блин)) Весь код на C++ - потенциальный UB. В Rust (при корректной реализации компилятора) - UB только unsafe подмножество. Если стреляет что-то в С++ - область поиска - весь код. Если стреляет Rust - только подмножество)

Опять же, в Rust все потенциальные UB места ты должен обозначить явно. В С++ можно получить UB на ровном месте :)