>>> Неинициализированные переменные (Uninitialized Variables) 1,374 / 1,692
> Неужели так сложно инициализировать переменные начальными значениями?Иногда сложно. Случаются такие гадостные ситуации, когда инициализация объекта означает, например, выделение памяти и открытие файлового дескриптора. Естественно, что такая инициализация происходит пошагово, вероятно между "шагами" появляются какие-то вычисления (размер памяти под выделение, или приведение имени файла к каноническому), вычисления могут порождать исключения... Кроме того, можно представить себе большой массив int'ов, который либо после выделения надо заполнять дефолными значения, либо не забыть потом заполнить настоящими. Иногда дефолтных значений нет: логика программы говорит о том, что массив должен быть заполнен специально вычисленными числами. В такой ситуации, лучше не изобретать никаких дефолтных значений: в такой ситуации, если какой-то элемент массива в процессе вычислений будет пропущен и не заполнен, и впоследствии будет произведено чтение из этого элемента, то это можно отловить valgrind'ом. Если же запихнуть дефолтное значение в этот элемент, то valgrind будет считать переменную инициализированной и не ткнёт носом в ошибку.
В общем и целом, чтобы надёжно избавиться от неинициализированной переменной как класса ошибки, который может привести к уязвимости, надо перелопачивать понятие переменной, уходить от C/C++ понимания переменной, и использовать понимание в стиле Pascal, когда любая переменная может либо хранить какое-то значение, либо быть неинициализированной. И генерировать runtime-исключение, в случае попытки чтения неинициализированной переменной. Но этот подход, как вы понимаете, имеет свои недостатки (переменная перестаёт быть просто ячейкой памяти, и C перестаёт быть кроссплатформенным ассемблером), и эти недостатки неприемлимы ни для С, ни для C++, в общем случае.
ps. Да, и здесь ведь ошибка "неинициализированная переменная" детектится в результате статического анализа кода. И у меня, например, нет уверенности в том, что какой-либо пристойный стиль программирования позволяет обойтись без таких "ошибок". Тут бы valgrind'ом пройтись следом, и посмотреть что скажет анализ времени выполнения. Вовсе не факт, что каждая такая "ошибка" на самом деле ошибка, а не вполне себе работоспособная и здравая задумка программиста.
