| 1.1, Zenitur (?), 23:14, 24/09/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Хм. Оказывается, возросшее количество находимых ошибок символизирует не то, что код стал хуже, а что сообщество лучше ищет ошибки!
| | |
| |
| |
| 3.6, Zenitur (?), 01:05, 25/09/2009 [^] [^^] [^^^] [ответить]
| +/– |
Я о том и хотел сказать, что увеличение количества найденных ошибок связано не с тем, что новый код хуже, а в том, что ищут лучше.
| | |
|
| 2.3, hatelinux (?), 00:08, 25/09/2009 [^] [^^] [^^^] [ответить]
| –3 +/– | |
>Хм. Оказывается, возросшее количество находимых ошибок символизирует не то, что код стал хуже, а что сообщество лучше ищет ошибки!
тоесть качество ошибок растет
это радует
| | |
|
| 1.4, ffsdmad (??), 00:09, 25/09/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
похоже они пиарят свою систему путём прогонки ей над OpenSource
но интересно, не уж проприетарчики пользуются услугами подобных компаний, разве не проще просто не проверять, всё равно ни кто не знает
| | |
| |
| 2.5, pavlinux (ok), 00:59, 25/09/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вы можете с ними списаться, заслать им свой код, они проверять и
250 страничный отчёт пришлют, ещё год курить можно выдавая начальству
по 20 багов в месяц за победоносно найденые, устраненные и описанные. :)
Обычно не более 100.000 строк, но у меня 45.000 тока взяли. :(
| | |
| 2.10, Aleksey (??), 10:24, 25/09/2009 [^] [^^] [^^^] [ответить]
| +/– |
Дешевле с точки зрения поддержки найти такие ошибки на этапе разработки.
| | |
| 2.11, uZver (??), 11:22, 25/09/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> но интересно, не уж проприетарчики пользуются услугами подобных компаний, разве не проще просто не проверять, всё равно ни кто не знает
пользуются подобным совтом. Не проще ибо цена бага в продакшене очень велика. Дешевле купить систему проверки кода и постоянно гонять ее по проекту + фиксать ВСЕ замечание выдвинутые проверкой.
| | |
|
| |
| 2.8, Zenitur (?), 02:16, 25/09/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Мало... Глючит не Qt, а новый KDE. Qt работает лучше и быстрее предыдущей версии.
| | |
| |
| 3.9, hatelinux (?), 05:37, 25/09/2009 [^] [^^] [^^^] [ответить]
| +/– |
отправте как тест от группы опеннет (с)
вот и узнаем
и под ошибками подразумевалось скоко плохого кода найдет ихний "автомат машина"
а не как реально работает qt
| | |
|
|
| 1.12, Karbofos (??), 15:33, 25/09/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
какие-нибудь бесплатные\открытые проекты есть? не нужно ссылок на поисковик, нужено мнение, основанное на личном опыте.
благодарю.
| | |
| |
| 2.13, Aleksey (??), 17:13, 25/09/2009 [^] [^^] [^^^] [ответить]
| +/– |
Для C++ ничего вменяемого нет. Бесплатные тулзы обычно столько ложных срабатываний делают, что через некоторое время на все эти варнинги забиваешь.
| | |
|
| 1.14, Andrey (??), 22:23, 25/09/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Кстати, в отчете упомянута проблема:
> ...
> struct tun_struct *tun = __tun_get(tfile);
> struct sock *sk = tun->sk;
> unsigned int mask = 0;
>
> The unusual situation in this particular defect is that the misbehavior happened at compile time. gcc looked at the assignment to sk, which used tun
as if it was guaranteed to be a valid non-NULL pointer, and decided that there was no point in performing the if (!tun) test below. The if() block was
optimized out. It’s in the source code, but it is NOT in the machine code that the compiler output. The programmers included a test to check
whether tun was valid, and return an error if it was not. The compiler removed that test, resulting in binaries that would allow processing to continue
past the intended checkpoint, even when tun’s value was invalid.
> ...
Вот тут-то и конец статическому анализу исходных текстов. Нужен еще проект по анализу соответствия полученного машинного кода исходному :)
| | |
| |
| 2.16, Alexey (??), 15:38, 26/09/2009 [^] [^^] [^^^] [ответить]
| +/– |
struct sock *sk = tun->sk;
Вот эта штука уже ошибка, т.к.если tun указывает в null, то в релизной версии эта конструкция может вызывать неопределенное поведение. Нормальный инструмент покажет, что указатель нигде не проверяется перед использованием. Так что все нормально.
| | |
| |
| 3.18, Andrey (??), 00:43, 28/09/2009 [^] [^^] [^^^] [ответить]
| +/– |
> struct sock *sk = tun->sk;
> Вот эта штука уже ошибка,
Там в исходном коде, якобы, есть проверка на ноль. Но она была удалена компилятором, т. к. он был уверен, что в этом месте ноль не может быть никогда.
Да и вообще можно было бы иметь функцию
struct sock* tun_get_sk(...);
Ведь они там такой же подход использовали, но для другой структуры.
| | |
| |
| 4.19, ximaera (?), 16:42, 28/09/2009 [^] [^^] [^^^] [ответить]
| +/– |
 Проверка на ноль там позже. Ошибка в адресации должна возникнуть до этой проверки.
| | |
|
|
|
| 1.15, Aleksey Salow (?), 11:59, 26/09/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > Наиболее распространёнными проблемами, обнаруживаемыми на протяжении нескольких лет, всё ещё являются нулевые указатели, утечки ресурсов и неумышленное игнорирование вычисленных значений.
Хех, вот вам и среды без автоматического управления ресурсами. Пока C/C++ жиф, такие баги будут находить пачками.
| | |
| |
| 2.17, я (?), 15:59, 26/09/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Хех, вот вам и среды без автоматического управления ресурсами. Пока C/C++ жиф, такие баги будут находить пачками.
А, ну да, в яве "утечки ресурсов" официально ошибками не являются. Только вот это не выход из ситуации.
> игнорирование вычисленных значений.
а это что за монстр? printf() вместо (void)print()?
| | |
| 2.20, ximaera (?), 16:43, 28/09/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> Наиболее распространёнными проблемами, обнаруживаемыми на протяжении нескольких лет, всё ещё являются нулевые указатели, утечки ресурсов и неумышленное игнорирование вычисленных значений.
>Хех, вот вам и среды без автоматического управления ресурсами. Пока C/C++ жиф,
>такие баги будут находить пачками.
Как будто в Java-программах не может быть утечек памяти.
| | |
|
|
