После того как Daniel Walker подготовил (http://kerneltrap.org/node/6591) патч предназначенный для устранения многочисленных предупреждающих сообщений на этапе сборки ядра, в списке рассылки Linux Kernel разгорелся спор.
Участники разделились на два лагеря, одни считают, что на предупреждения не стоит обращать внимания и устранять их не нужно, так как при исправлении легко породить новые, трудноуловимые ошибки (некоторые предупреждения формальны и вызваны особенностями или недоработками разных версий GCC).
Другие, резонно полагают, что стоит провести чистку кода и избавиться от предупреждающих сообщений, так как на них уже мало кто смотрит, и среди множества недостойных внимания сообщений, может остаться незамеченным предупреждение о наличии серьезной ошибки.URL: http://kerneltrap.org/node/6591
Новость: http://www.opennet.me/opennews/art.shtml?num=7504
варнинги придумали не дуракипод неприметным ругательством может крыться серьезная логическая ошибка.
лучше от этих матов избавляться
Кстати при компиляции FreeBSD варнингов почти нет.
>Кстати при компиляции FreeBSD варнингов почти нет.^FreeBSD^Linux
>>Кстати при компиляции FreeBSD варнингов почти нет.
>
>^FreeBSD^Linuxт.е. то же самое можно сказать и о линухе.
Фича в том, что они или есть или их нет. "почти" - это уже "есть"
Фича в том, что варнинги можно либо подавить либо исправить код, чтобы их не было. Во фре стараются следовать по второму пути. Варнинги приравниваются к ошибкам, т.е. практически при любом варнинге компиляция прекращается. Есть только небольшое количество файлов, кторые компилируются с мягкими ограниченими на варнинги.
>варнинги придумали не дураки
+1
Спор идет о том стоит ли вносить изменения в код ядра для того чтобы скрыть варнинги ЯВНО ПОРОЖДЕННЫЕ НЕДОРАБОТКАМИ В GCC (особенно 4.x.x)Обоснованные же варнинги искореняются регулярно :)
НЕТ.
Один раз на голову упадет просто опавший листик, а когда много листьев - это уже дерево.
Я думаю, что когда падает дерево на голову это не очень приятно.
Я уж не говорю про ураган, когда деревья станут в роли листьев.
НЕТ.
Пример:В <linux/kernel.h> определён макросик max(x,y)
он работает так: определяет тип переменных через временно создаваемые
дополнительные переменные _x и _y#define max(x,y) ({ \
typeof(x) _x = (x); \
typeof(y) _y = (y); \
(void) (&_x == &_y); \
_x > _y ? _x : _y; })В своей безобидной проге/модуле/патче, я пишу:
-----------------------------
#include <linux/kernel.h>int main(void)
{
long long _x=2341234123513452345L, _y=8567856785768576857L;
max(_y,_x);
}
--------------------------------gcc -D__KERNEL__ test.c
Тишина...А с флагом -Wshadow, ругнётся:
warning: declaration of '_y' shadows a previous local
warning: shadowed declaration is here
warning: declaration of '_x' shadows a previous local
warning: shadowed declaration is hereНо этого мало, так как в kernel.h использует временные переменые с именами _х, _у
В примере получится, что _х присваевается мой _y, _y мой _х
В итоге вернется не наибольшее число, и меньнее.--------------------------------
Один раз на голову упадет просто опавший листик, а когда много листьев - это уже дерево.
Я думаю, что когда падает дерево на голову это не очень приятно.
Я уж не говорю про ураган, когда деревья станут в роли листьев.
А можете коротко объяснить, как интерпретировать эту конструкцию:
(void) (&_x == &_y);
А так же что означает буква L в присвоении
int a=456789123L;
PS: Действительно надо знать...
Ээ... Если буквально: преобразуем к типу void результат стравнения по == адресов _x и _y. Я прав? Но зачем это выражение в данном макросе?
> (void) (&_x == &_y);Это для того чтобы типы x и y были одинаковые. Если это не так, то при компиляции в этом месте возникнет ошибка.
> int a=456789123L;
L - значит Long, т.е. константа получается не типа int, а типа long.
P.S. учите матчасть.
Понял, сенкс.
> L - значит Long, т.е. константа получается не типа int, а типа long.
Константа, по-моему, получится того типа, которого она объявлена. Скорее это эквивалентно такому присваиванию:int a;
long b=123456789;
a=(int)b;Или L все-таки явно заменяет тип?
>В своей безобидной проге/модуле/патче, я пишу:
>-----------------------------
>#include <linux/kernel.h>
>
>int main(void)
> {
> long long _x=2341234123513452345L, _y=8567856785768576857L;
> max(_y,_x);
> }
>--------------------------------
>
>gcc -D__KERNEL__ test.c
>Тишина...
>
>А с флагом -Wshadow, ругнётся:
>
>warning: declaration of '_y' shadows a previous local
>warning: shadowed declaration is here
>warning: declaration of '_x' shadows a previous local
>warning: shadowed declaration is here
>
>Но этого мало, так как в kernel.h использует временные переменые с именами
>_х, _у
>В примере получится, что _х присваевается мой _y, _y мой _х
>В итоге вернется не наибольшее число, и меньнее.Насколько я помню имена переменных начинающиеся с _ зарезервированы для внутреннего употребления C, имена переменных начинающиеся с __ зарезервированы для C++
Так что вы в своей программы НИКОГДА не должны употреблять ТАКИХ имен переменных
и проблема просто испаряется ...
первое предложение первого поста очень понравилось. супер. ранньше юзал Линукс, а теперь не юзаю т.г. гавно. больше всех отличилась Шапка, когда пол поменяла. Все это фигня. Я еще не отрезвел после вчера, но ворнинг это будующая ошибка. причем тут спор я не понимаю. наверное решили ошибок наделать. :-)))))
да, информация полезная, кто себя считает умным пусть попьет молока, сказано по дулу
Бред какой-то написали, опять какие-то религиозные войны, не более того. Посмотрите одну из стабильных версия ядра linux и сравнивайте с тем же freebsd. А то прям горазды нечетные ядра обсуждать я смотрю.Наезд на шапку не понял, объясните пожалуйста. Red Hat кстати очень многое делает для стабилизации ядра и его ядро одно из лучших на продакшн системах.
>Бред какой-то написали, опять какие-то религиозные войны, не более того.а что ты хотел получить из треда на форуме?
Ты можешь сказать нечто большее, чем что-либо сказанное до тебя??вряд-ли. зачем тогда на других наежать?
>Посмотрите одну
>из стабильных версия ядра linux и сравнивайте с тем же freebsd.
>А то прям горазды нечетные ядра обсуждать я смотрю.
>
>Наезд на шапку не понял, объясните пожалуйста. Red Hat кстати очень многое
>делает для стабилизации ядра и его ядро одно из лучших на
>продакшн системах.
>Или L все-таки явно заменяет тип?Неа.
#cat test.c
#include <stdio.h>
int main(void)
{
int a = 456789123LL;printf("a=%d\n", a);
printf("sizeof(int):\t%d\n", sizeof(int));
printf("sizeof(long long):\t%d\n", sizeof(long long));
printf("sizeof(a):\t%d\n", sizeof(a));return 0;
}#gcc test.c
#./test
a=456789123
sizeof(int): 4
sizeof(long long): 8
sizeof(a): 4Зато с такой конструкцией можно и нарваться -
заменим int a = 456789123LL на a = 456789123000LL:#gcc test.c
test.c: In function `main':
test.c:5: warning: overflow in implicit constant conversionВот так вот, спасибо gcc, что отлавливает такие ляпы. Я раньше работал с msvc и он такие ошибки спокойно пропускал. Так что пользуясь случаем хочу бросить клич: "Виндовые программеры, переходите на MinGW. gcc рулит"!