Перевод документа Safer Usage Of C++, выложенного в общий доступ командой Chromium/Chrome из компании Google и активно обсуждаемого на Reddit. Текста много, но, думаю, C++ программистам будет очень полезно почитать.
Здравствуйте, jul_nevermind, Вы писали:
_>Перевод документа Safer Usage Of C++, выложенного в общий доступ командой Chromium/Chrome из компании Google и активно обсуждаемого на Reddit. Текста много, но, думаю, C++ программистам будет очень полезно почитать.
высказана довольно смелая мысль "мы наш, мы новый stl построим". Лично я эту мысль разделяю. Rust наступает, а коммитет каждый год выпускает фичи с тоннами UB.
Здравствуйте, jul_nevermind, Вы писали:
_>Перевод документа Safer Usage Of C++, выложенного в общий доступ командой Chromium/Chrome из компании Google и активно обсуждаемого на Reddit. Текста много, но, думаю, C++ программистам будет очень полезно почитать.
И чего там интересного? Обсуждаются какие-то проблемы прошлого века:
Examples include use after free (UAF), double-free, use before initialization, and use after move (UAM). Temporal safety violations often look like type confusion. For example, the program mistakenly uses a recently-freed Dog object as if it were a Cat object
Смарт указатели даже в стандарте давно. Эти из Google примерно на 20 лет отстают от современных подходов.
Здравствуйте, B0FEE664, Вы писали:
BFE>И чего там интересного? Обсуждаются какие-то проблемы прошлого века:
как минимум гистограмма распределения ошибок. Статистика занятная. Особенно посмотреть на процент data race и процент статей и докладов, как их обходить Я конечно понимаю, что это интереснее, чем проблема протухших ссылок, но тенденция занятная.
BFE>Смарт указатели даже в стандарте давно. Эти из Google примерно на 20 лет отстают от современных подходов.
уже 20 (10) лет этот код приводит к UB
std::unique_ptr<Foo> f;
f->foo();
и "современный" подход заключается в том, чтобы закрыть глаза на этот вид проблем.
SP>и "современный" подход заключается в том, чтобы закрыть глаза на этот вид проблем.
Что мешает Google использовать свои умные указатели везде, которые будут проверять такие инварианты и не давать делать инициализацию по умолчанию ?!
Почему тогда они до сих пор пишут так (пример из webrtc.lib):
???
И это типичный Google код из Хрома. Вот пойди разберись что здесь передается как ссылка, а что для захвата владения
Они уже из простого интернет протокола HTTP сделали штуку (HTTP3) которую хрен реализуешь на коленке и будешь вынужден использовать кусок Хрома, причем не важно, нужна тебе секьюрность или нет. WebRTС — монстр, внутри которого наслоения всех протоколов за последние 40 лет. Всё технологии за которые берется Google превращаются в инструмент для решения бизнес задач Google, не пригодными ни для чего другого.
BFE>>Смарт указатели даже в стандарте давно. Эти из Google примерно на 20 лет отстают от современных подходов. SP>уже 20 (10) лет этот код приводит к UB SP>[ccode] SP>std::unique_ptr<Foo> f; f->>foo();
Но ведь это не use after free, священную войну против которого объявил гуголь.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, sergii.p, Вы писали:
BFE>>И чего там интересного? Обсуждаются какие-то проблемы прошлого века: SP>как минимум гистограмма распределения ошибок. Статистика занятная. Особенно посмотреть на процент data race и процент статей и докладов, как их обходить Я конечно понимаю, что это интереснее, чем проблема протухших ссылок, но тенденция занятная.
Если набирать по объявлению и код-ревью не делать, то так и будет. Что там занятного?
BFE>>Смарт указатели даже в стандарте давно. Эти из Google примерно на 20 лет отстают от современных подходов. SP>уже 20 (10) лет этот код приводит к UB SP>
SP>std::unique_ptr<Foo> f;
f->>foo();
SP>
SP>и "современный" подход заключается в том, чтобы закрыть глаза на этот вид проблем.
Вообще-то смарт указатели не ограничиваются стандартом:
... safe_ptr::operator ->()
{
if ( nullptr == m_ptr )
{
m_ptr = new T{};
}
return m_ptr;
}
однако если вам такое надо, значит процесс тестирования у вас поставлен криво.
Здравствуйте, ononim, Вы писали:
O>Но ведь это не use after free, священную войну против которого объявил гуголь.
я и не говорил, что это UAF. Гугл заявил, что в стандарте дофига UB. Причём иногда просто необоснованного. Точнее обоснованного как раз: не хотели производительность просаживать. Вот из-за этих плёвых проверок мы отстреливаем ноги по сей день.
Здравствуйте, velkin, Вы писали:
SP>>"мы наш, мы новый stl построим".
V>Для всего остального есть Boost.
так буст же — калька stl (точнее наоборот). Что он делает лучше? Итераторы отлично инвалидируются в обоих библиотеках, use after move прекрасно себя чувствует что при белых, что при красных. В общем, скрипач boost не нужен
SP>я и не говорил, что это UAF. Гугл заявил, что в стандарте дофига UB. Причём иногда просто необоснованного. Точнее обоснованного как раз: не хотели производительность просаживать. Вот из-за этих плёвых проверок мы отстреливаем ноги по сей день.
И чем лучше подстановка пустого объекта? Тем что апликуха не упадет в данном конкретном месте, а юзер будет потом недоумевать, куда пропали его данные?
С тем же успехом можно заменять на NULL guard page в адресном пространстве на RW регион, вечно заполненный нулями.
Как много веселых ребят, и все делают велосипед...
SP>чего? Мне кажется, вы додумываете какие-то высказывания за меня и с ними же спорите
Ну я отчегото подумал что вы за все хорошее и хотите std::uniqnue_ptr всегда возвращал поинтер на валидный объект, сконструированный дефолтным конструктором например.
Ну а насчет UB.. UB при обращении к нулевому указателю конечно плохо. Надо чтоб поведение было достаточно четко определено — в таком случае апликуха должна падать
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Ну я отчегото подумал что вы за все хорошее и хотите std::uniqnue_ptr всегда возвращал поинтер на валидный объект, сконструированный дефолтным конструктором например. O>Ну а насчет UB.. UB при обращении к нулевому указателю конечно плохо. Надо чтоб поведение было достаточно четко определено — в таком случае апликуха должна падать
В Debug скорее всего assert вылетит
Ну и самому надо, когда получаешь что-то неизвестно откуда, по-хорошему всё тоже assert'ами обкладывать
Здравствуйте, Videoman, Вы писали:
У>>В Debug скорее всего assert вылетит
V>Тоже так думал, проверил — во всяком случае MSVC, тупо разыменовывает нулевой указатель, что является UB. Интересно, почему нет assert ?
Ну, под виндой будет системное исключение, а не UB
V>>Тоже так думал, проверил — во всяком случае MSVC, тупо разыменовывает нулевой указатель, что является UB. Интересно, почему нет assert ? У>Ну, под виндой будет системное исключение, а не UB
В линуксах тоже. Но фишка в том, что изза того что формально это UB, то компилятор может творить разную чернуху, например, видя что разыменовываемый указатель точно равен nullptr, — он теоретически может выкинуть нафиг код обращения, как ретурн в соседнем топике