форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[Проследить за развитием треда]

"OpenNews: Стоит ли избавляться от предупреждений компилятора..."

Сообщение от opennews (??) on 12-Май-06, 18:01

После того как 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

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Сообщения по теме

[Сортировка по времени, UBB]

1. "Стоит ли избавляться от предупреждений компилятора при сборк..."

Сообщение от _Nick_ (??) on 12-Май-06, 18:01

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

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

2. "Стоит ли избавляться от предупреждений компилятора при сборк..."

Сообщение от citrin (ok) on 12-Май-06, 18:06

Кстати при компиляции FreeBSD варнингов почти нет.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	3. "Стоит ли избавляться от предупреждений компилятора при сборк..."
	Сообщение от _Nick_ (??) on 12-Май-06, 18:14
	>Кстати при компиляции FreeBSD варнингов почти нет. ^FreeBSD^Linux
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	4. "Стоит ли избавляться от предупреждений компилятора при сборк..."
	Сообщение от _Nick_ (??) on 12-Май-06, 18:15
	>>Кстати при компиляции FreeBSD варнингов почти нет. > >^FreeBSD^Linux т.е. то же самое можно сказать и о линухе. Фича в том, что они или есть или их нет. "почти" - это уже "есть"
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	12. "Стоит ли избавляться от предупреждений компилятора при сборк..."
	Сообщение от butcher (ok) on 15-Май-06, 15:45
	Фича в том, что варнинги можно либо подавить либо исправить код, чтобы их не было. Во фре стараются следовать по второму пути. Варнинги приравниваются к ошибкам, т.е. практически при любом варнинге компиляция прекращается. Есть только небольшое количество файлов, кторые компилируются с мягкими ограниченими на варнинги.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

5. "Стоит ли избавляться от предупреждений компилятора при сборк..."

Сообщение от Killy on 12-Май-06, 18:55

>варнинги придумали не дураки +1

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

6. "Когда же авторы новостей научатся читать ?"

Сообщение от pazke on 12-Май-06, 18:55

Спор идет о том стоит ли вносить изменения в код ядра для того чтобы скрыть варнинги ЯВНО ПОРОЖДЕННЫЕ НЕДОРАБОТКАМИ В GCC (особенно 4.x.x) Обоснованные же варнинги искореняются регулярно :)

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	7. "Когда же авторы новостей научатся читать ?"
	Сообщение от Golovach Lena on 12-Май-06, 23:26
	НЕТ. Один раз на голову упадет просто опавший листик, а когда много листьев - это уже дерево. Я думаю, что когда падает дерево на голову это не очень приятно. Я уж не говорю про ураган, когда деревья станут в роли листьев.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	8. "Когда же авторы новостей научатся читать ?"
	Сообщение от Golovach Lena on 12-Май-06, 23:53
	НЕТ. Пример: В <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 мой _х В итоге вернется не наибольшее число, и меньнее. -------------------------------- Один раз на голову упадет просто опавший листик, а когда много листьев - это уже дерево. Я думаю, что когда падает дерево на голову это не очень приятно. Я уж не говорю про ураган, когда деревья станут в роли листьев.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	10. "Когда же авторы новостей научатся читать ?"
	Сообщение от fresco on 15-Май-06, 15:21
	А можете коротко объяснить, как интерпретировать эту конструкцию:      (void) (&_x == &_y); А так же что означает буква L в присвоении      int a=456789123L; PS: Действительно надо знать...
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	11. "Когда же авторы новостей научатся читать ?"
	Сообщение от fresco on 15-Май-06, 15:28
	Ээ... Если буквально: преобразуем к типу void результат стравнения по == адресов _x и _y. Я прав? Но зачем это выражение в данном макросе?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	13. "Когда же авторы новостей научатся читать ?"
	Сообщение от _Nick_ (??) on 15-Май-06, 18:05
	> (void) (&_x == &_y); Это для того чтобы типы x и y были одинаковые. Если это не так, то при компиляции в этом месте возникнет ошибка. > int a=456789123L; L - значит Long, т.е. константа получается не типа int, а типа long. P.S. учите матчасть.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	20. "Когда же авторы новостей научатся читать ?"
	Сообщение от fresco on 19-Май-06, 11:14
	Понял, сенкс. > L - значит Long, т.е. константа получается не типа int, а типа long. Константа, по-моему, получится того типа, которого она объявлена. Скорее это эквивалентно такому присваиванию: int a; long b=123456789; a=(int)b; Или L все-таки явно заменяет тип?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	14. "Когда же авторы новостей научатся читать ?"
	Сообщение от Осторожный on 16-Май-06, 07:21
	>В своей безобидной проге/модуле/патче, я пишу: >----------------------------- >#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++ Так что вы в своей программы НИКОГДА не должны употреблять ТАКИХ имен переменных и проблема просто испаряется ...
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

9. "Стоит ли избавляться от предупреждений компилятора при сборк..."

Сообщение от Fantamas on 15-Май-06, 14:25

первое предложение первого поста очень понравилось. супер. ранньше юзал Линукс, а теперь не юзаю т.г. гавно. больше всех отличилась Шапка, когда пол поменяла. Все это фигня. Я еще не отрезвел после вчера, но ворнинг это будующая ошибка. причем тут спор я не понимаю. наверное решили ошибок наделать. :-)))))

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

16. "Стоит ли избавляться от предупреждений компилятора при сборк..."

Сообщение от Вася on 17-Май-06, 02:28

да, информация полезная, кто себя считает умным пусть попьет молока, сказано по дулу

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

17. "Стоит ли избавляться от предупреждений компилятора при сборк..."

Сообщение от liks (??) on 17-Май-06, 09:42

Бред какой-то написали, опять какие-то религиозные войны, не более того. Посмотрите одну из стабильных версия ядра linux и сравнивайте с тем же freebsd. А то прям горазды нечетные ядра обсуждать я смотрю. Наезд на шапку не понял, объясните пожалуйста. Red Hat кстати очень многое делает для стабилизации ядра и его ядро одно из лучших на продакшн системах.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	18. "Стоит ли избавляться от предупреждений компилятора при сборк..."
	Сообщение от _Nick_ (??) on 17-Май-06, 09:48
	>Бред какой-то написали, опять какие-то религиозные войны, не более того. а что ты хотел получить из треда на форуме? Ты можешь сказать нечто большее, чем что-либо сказанное до тебя?? вряд-ли. зачем тогда на других наежать? >Посмотрите одну >из стабильных версия ядра linux и сравнивайте с тем же freebsd. >А то прям горазды нечетные ядра обсуждать я смотрю. > >Наезд на шапку не понял, объясните пожалуйста. Red Hat кстати очень многое >делает для стабилизации ядра и его ядро одно из лучших на >продакшн системах.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

21. "Стоит ли избавляться от предупреждений компилятора при сборк..."

Сообщение от scum (??) on 25-Май-06, 19:20

>Или 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 рулит"!

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]