C++ init-list: использование неинициализированных элементов для инициализации других не дает предупреждений

Ни g++ (4.4 и 4.6), ни clang++ (3.2), ни coverity с -Wall и -Wextra (+ некоторые другие) или -Weeverything соответственно не выдают мне предупреждение о следующем фрагменте кода:

class B {
    char *t2;
    char *t;

public:
    B() : t2(t), t(new char[100]) {}
};

По крайней мере, я бы ожидал небольшого предупреждения об использовании неинициализированных переменных (членов).

Есть что-то, что мне не хватает? Это разыскиваемый сценарий "без предупреждения". У меня есть (теперь была) по крайней мере одна ошибка в моем программном обеспечении, которую было трудно найти.

EDIT: как можно прочитать в этот новый вопрос Я понял, что coverity предупреждает об этой проблеме в некоторых случаях.


gcc c++ clang member-variables coverity
person Patrick B.    schedule 03.01.2013    source источник
comment
afaik только инструменты анализа кода, такие как valgrind, могут выдавать предупреждения в таких случаях.   -  person Piotr Tkaczyk    schedule 03.01.2013
comment
Coverity — это статический анализатор, который находит огромное количество неинициализированных использований переменных повсюду в коде, но не в этом. Это может иметь место только потому, что кто-то не поместил анализ пути в список инициализаторов. Мой вопрос в том, есть ли для этого веская причина или нет?   -  person Patrick B.    schedule 03.01.2013
comment
Если бы я это сделал, я был бы признателен за предупреждение.   -  person brian beuning    schedule 03.01.2013

Ответы (2)


arrow_upward
6
arrow_downward

Здесь нет веских причин не выносить предупреждение.

G++ недостаточно умен, чтобы диагностировать неинициализированные элементы в конструкторах, см. http://gcc.gnu.org/PR2972

У меня есть незавершенный патч, чтобы исправить это, и я надеюсь закончить «когда-нибудь в этом году».

Даже с моим патчем я не уверен, что G++ предупредит, потому что t2 инициализируется, но инициализируется неопределенным значением. Для компилятора отслеживать это не тривиально, но должно быть возможно (поэтому я удивлен, что даже Coverity упускает это из виду). Однако инструменты времени выполнения, такие как valgrind, делают это правильно.

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

person Jonathan Wakely    schedule 03.01.2013

arrow_upward
3
arrow_downward

Стандарт C++ говорит, что использование неинициализированных переменных приводит к неопределенному поведению. Это не требует, чтобы компилятор выдавал диагностику по этому поводу. Таким образом, получение предупреждения или нет — это вопрос QOI (качества реализации).

person user93353    schedule 03.01.2013
comment
Вы хотите сказать, что, например. gcc предупреждает о неинициализированной локальной переменной с параметрами -Wall и -O, потому что кто-то добавил для нее предупреждение, но никто еще не добавил его для моего случая? - person Patrick B.; 03.01.2013
comment
@ Патрик Б. Я говорю, что компилятор может демонстрировать поведение, которое вы описываете, будучи совместимым со стандартом. Но, как вы говорите, этот случай, вероятно, был упущен из виду или, возможно, предупреждение о неинициализированных переменных-членах было приоритетным как функция, отличная от предупреждения о неинициализированных переменных, не являющихся членами. Не знаю. - person user93353; 03.01.2013
comment
Хорошо, это подтвердит мою теорию об этой штуке. (PS: это был не я, кто проголосовал против, люди очень быстро голосуют против, а вопросы, связанные с голосованием, встречаются редко...) - person Patrick B.; 03.01.2013
comment
В случае с Clang добавление этого предупреждения находится в TODO-списке. - person Hans W; 05.01.2013
comment
@HansW, можете ли вы указать мне запись в списке TODO? Если доступно? - person Patrick B.; 05.01.2013
comment
@PatrickB.: Я думал о комментарии в lib /Sema/SemaDeclCXX.cpp:2307. - person Hans W; 06.01.2013