Проверка Chromium спустя три года. Ну и как оно?

[qark]

Случай №5 - прекрасная иллюстрация преимуществ использования std::find или range-based for.

[ncr]

Случай №9 — прекрасная иллюстрация того, что operator== должен уметь генерироваться компилятором, и то, что это добавили только сейчас — это какой-то позор.

[IGR2014]

Случай #8 - прекрасный пример почему следует использовать std::filesystem. Достаточно было бы file_extension() и поиск по std::array<std::string_view> из расширений

[qark]

В std::array с тем же успехом может накопипаститься одно расширение.

[IGR2014]

Да, согласен. Просто не хотелось в такую простую функцию тащить std::unordered_map/std::set

[domix32]

Код-то скорее всего из времён, когда в помине не было.

[needleshaped]

Спасибо за статью. Но были ли зарегистрированы баги?

[Mixxxxa]

Да, отписали на баг-трекер Chromium. Тикет 1275942.

[zmc]

Возможно не по теме, но все же спрошу — перестали отрабатывать псевдо-ссылки.
В качестве пример, Алиэкспресс -> Профиль -> Заказы. Хоть затыкайся, срабатывает только
такая последовательность: правый клик и потом уже левый, такое впечатление что какие то заморочки с keyup/keydown/release/etc.
Дистр один, void, на разных машинках.

[koct9i]

Случай N4 - валидный код, никакого null-pointer dereference там нет.

[qark]

Объясни.

[Mixxxxa]

Действительно, здесь мой косяк, спасибо за внимательность. Более опытные коллеги подсказали, что в этом случае, скорее всего, падения не будет, т.к. происходит взятие адреса. Так что да, код - валидный, но опасный из-за наличия неопределенного поведения в выражении &natp->user, когда natp является нулевым указателем. Более подробно похожий случай разбирался в статье "Разыменовывание нулевого указателя приводит к неопределённому поведению".