PJ>А вот если бы тебя позвали, то все было бы по-другому?

А почему ты так уверен, что нет?

PJ>Совершенно правильный вывод. Вывод, что во всем виноваты люди совершенно бесполезный. Так можно было и дальше ассемблера не ходить.

Все ошибки с памятью, которые можно допустить в C++, давно известны. Неужели так трудно научить своих сотрудников их не делать? Да, лучше, если компилятор будет бить по рукам, если делаешь, что-то нетак. Но в приведённой статье есть более интересный момент

For complex C/C++ code bases, often there are only a handful of people capable of developing and reviewing the fix, and even with a high amount of effort spent on fixing bugs, sometimes the fixes are incorrect.

complex C/C++ code bases — сложный C/C++ код.
there are only a handful of people capable of developing and reviewing the fix — немного людей, кто в состоянии устранить ошибку.

Иными словами гугл подтверждает, что в их коде чёрт ногу сломит.

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


Кстати, там есть интересная ссылка на найденный баг в гугловом коде https://googleprojectzero.blogspot.com/2015/09/stagefrightened.html

Прежде чем начать читать статью, я пробежал глазами по коду. Первое за что я зацепился было это

if ((size_t)(mDataSource->readAt(*offset, buffer + size, chunk_size))
            < chunk_size)

Зачем понадобился каст в size_t? Для любого опытного С++ программиста любой каст это сразу же намёк, что что-то тут нетак. Что возвращает mDataSource->readAt ? Это int? А если он вернёт -1, а мы это скастим в size_t, мы получим 18446744073709551615 (если это 64 битная платформа). Это точно то, чего добивался автор?

Это реально трудно заметить, или у меня дар божий?