Свежие комментарии

Хо-хо, тут через последний clang прогнали FreeBSD и понаходили вот такого:

struct X { ... }

struct X *obj;

memset(obj, 0, sizeof(obj));

И это после многих лет жизни с gcc -Wall -Werror

1) "Декларация с печатью" к порядку ведения/заверения КУДиР ведь полюбому никак не относится, не так ли?

2) Я на всяк случай в этом году заверил, благо это 5 минут, а форма книги всё равно старая, место для подписи предполагается. Насчёт полностью электронной отчётности, кстати, ничего вроде не менялось - всё равно надо в конце года распечатывать, прошивать, подписывать и складывать в архив.

Ну собственно да нормальный цикл использования таких штук это до/после компиляции или хук на коммит

а ты отечественный продукт, у них еще радуга в логотипе и много постов на хабре, не пробовал? вроде не так плох

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

насчет того, что это шум я не согласен, если честно, это как миннимум плохой стиль.

большой практики с плюсами и анализаторами у меня нет, но вот с перлом чего мы только не находили благодаря перл-критику :)

> Так ведь при тестировании все вылезет.

Вот конкретно в этом for-е и printf-е все как-то работало, цикл рвался внутри еще по одному условию, а в принт не приходили данные больше 32 бит, то есть ошибки увидел только с -Wall. Да, достаточно редкие ошибки, и у нас почти такая же история - есть чужие .h-файлы которые выдают кучу нелепых варнингов. Но с -Wall -pedantic пытаюсь собрать хотя бы раз в месяц, мало ли чего?

> Оно это ловит и правильно ловит, но с моей точки зрения - это false positive.

Валгринд, кстати, меня тоже в некоторых местах раздражал, казалось что слишком уж умничает железяка чертова. Но потом, подумав, понял что правильно он возмущается. Теперь стараюсь как-то его умиротворить. В некоторых местах, само собой, не получается, BerkeleyDB например что-то там не инициализирует, pthreads текут и т.п., но по возможности стараюсь чтоб было без предупреждений

А как народ умудряется без -Wall хотя бы иногда (а лучше еще и -pedantic для верности)? Я недавно вылавливал совершенно адовые ошибко-опечатки, которые глазами трудно заметить, типа "for (...;;<условие>)" или какие-то ошибки в snprintf-спецификаторах. Ну, можно, наверное, идеально писать, но это же не всем дано. Но это и правда не часто как-то нужно.

А вод динамический valgrind, в режиме проверки памяти/текущих ресурсов - прекрасен. Ну, опять же, кто-то, наверное, делает все c RAII, аккуратненько и с первого раза, но я так не умею, от первого знакомства с валгриндом вообще аж вспотел, настолько много всего текло и вообще удивительно как работало

повторюсь -- достаточно определить layout и Layout1 через енум, после этого даже ифы работают

Ну то есть идея в том, что
- при регулярном использовании мы обнаружим багу *раньше* и потратим на ее исправление меньше сил
- а на готовом проекте - смысла мало, т.к. он уже работает и доля ложных срабатываний будет слишком большой?

Интересная мысля, надо ее подумать.

> Но в реальной жизни бывает два вида layout - и это явно прописано в вызывающем коде. Т.е. у машинки достаточно данных, чтобы сообразить, что это не 'High impact', а просто неаккуратненько.

Э, нет, батенька, не согласен я с вами тут.
Это сегодня явно прописано строго два варианта вызова и никаких больше. А завтра в проект придёт новый чувак, которому поставят задачу сделать третий лейяут и он имеет полное право не знать о таком неявном свойстве кода, посему будет честное обращение к неинициализированной памяти.
Это очень правильный ворнинг, имхо. Это не "неаккуратненько", это мина на будущее расширение.
Я бы переписал тот код как свитч с throw exception по дефолту.

> С этим я не хочу спорить - формально машинка права, а по факту в этих unsigned short живут размеры картинки и до 32767 они в ближайшие годы не дорастут.

))) "640кб хватит всем!", "до 2000-го года ещё много лет, успеем поправить!" :)
Ну, т.е. понятно, что машина-то всех тонкостей domain specific не знает, посему имхо тоже вполне правильно ругается.

> В частности, любимый коффиновский метод проверки диапазона значений 0..N одним действием машинка просто не чует:

А чо-как ругается? Вполне нормальный метод, имхо...

По вопросу: я специально не использую, но обычно ставлю студию на наивыший уровень ворнингов и если что возникает - стараюсь или переправлять, или если однозначно в данном случае не нужно - подавлять. Несколько раз меня эти варнинги ОЧЕНЬ спасали от тяжелого и трудноуловимого дебуга, поэтому просто принял для себя решение по возможности сразу писать правильно и таки прислушиваться в варнингам. Хотя специально отдельными тулзами обычно не пользуюсь. Согласен с тем, что в идеале это надо делать системным образом, но по моему опыту даже вот такое эпизодическое следование мне лично здорово помогало.

Нет никакого апстрима. Это именно contributed, конкретно в LibRaw.

Я с благодарностью такие куски кода принимаю, но что я при этом думаю - я никому не скажу!

отправь патчи в апстрим!
кстати, достаточно просто enum

а в твоем случае надо просто переписать через case и enum и варнинга не будет.

а, вот в таком разе я особо не сравнивал, но мне показалось что примерно одинаково, все же.

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

Но в данном наборе исходников - ошибки нет, да.