The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

12.05.2006 17:42

После того как Daniel Walker подготовил патч предназначенный для устранения многочисленных предупреждающих сообщений на этапе сборки ядра, в списке рассылки Linux Kernel разгорелся спор.

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

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

  1. Главная ссылка к новости (http://kerneltrap.org/node/659...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/7504-linux
Ключевые слова: linux, complile, kernel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (19) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, _Nick_ (??), 18:01, 12/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    варнинги придумали не дураки

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

    лучше от этих матов избавляться

     
  • 1.2, citrin (ok), 18:06, 12/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кстати при компиляции FreeBSD варнингов почти нет.
     
     
  • 2.3, _Nick_ (??), 18:14, 12/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Кстати при компиляции FreeBSD варнингов почти нет.

    ^FreeBSD^Linux

     
     
  • 3.4, _Nick_ (??), 18:15, 12/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >>Кстати при компиляции FreeBSD варнингов почти нет.
    >
    >^FreeBSD^Linux

    т.е. то же самое можно сказать и о линухе.

    Фича в том, что они или есть или их нет. "почти" - это уже "есть"

     
     
  • 4.12, butcher (ok), 15:45, 15/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Фича в том, что варнинги можно либо подавить либо исправить код, чтобы их не было. Во фре стараются следовать по второму пути. Варнинги приравниваются к ошибкам, т.е. практически при любом варнинге компиляция прекращается. Есть только небольшое количество файлов, кторые компилируются с мягкими ограниченими на варнинги.
     

  • 1.5, Killy (?), 18:55, 12/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >варнинги придумали не дураки
    +1
     
  • 1.6, pazke (?), 18:55, 12/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Спор идет о том стоит ли вносить изменения в код ядра для того чтобы скрыть варнинги ЯВНО ПОРОЖДЕННЫЕ НЕДОРАБОТКАМИ В GCC (особенно 4.x.x)

    Обоснованные же варнинги искореняются регулярно :)

     
     
  • 2.7, Golovach Lena (?), 23:26, 12/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    НЕТ.
    Один раз на голову упадет просто опавший листик, а когда много листьев - это уже дерево.
    Я думаю, что когда падает дерево на голову это не очень приятно.
    Я уж не говорю про ураган, когда деревья станут в роли листьев.
     
  • 2.8, Golovach Lena (?), 23:53, 12/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    НЕТ.
    Пример:

    В <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 мой _х
    В итоге вернется не наибольшее число, и меньнее.

    --------------------------------

    Один раз на голову упадет просто опавший листик, а когда много листьев - это уже дерево.
    Я думаю, что когда падает дерево на голову это не очень приятно.
    Я уж не говорю про ураган, когда деревья станут в роли листьев.

     
     
  • 3.10, fresco (?), 15:21, 15/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    А можете коротко объяснить, как интерпретировать эту конструкцию:
         (void) (&_x == &_y);
    А так же что означает буква L в присвоении
         int a=456789123L;
    PS: Действительно надо знать...
     
     
  • 4.11, fresco (?), 15:28, 15/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Ээ... Если буквально: преобразуем к типу void результат стравнения по == адресов _x и _y. Я прав? Но зачем это выражение в данном макросе?
     
  • 4.13, _Nick_ (??), 18:05, 15/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > (void) (&_x == &_y);

    Это для того чтобы типы x и y были одинаковые. Если это не так, то при компиляции в этом месте возникнет ошибка.

    > int a=456789123L;

    L - значит Long, т.е. константа получается не типа int, а типа long.

    P.S. учите матчасть.

     
     
  • 5.20, fresco (?), 11:14, 19/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Понял, сенкс.
    > L - значит Long, т.е. константа получается не типа int, а типа long.
    Константа, по-моему, получится того типа, которого она объявлена. Скорее это эквивалентно такому присваиванию:

    int a;
    long b=123456789;
    a=(int)b;

    Или L все-таки явно заменяет тип?

     
  • 3.14, Осторожный (?), 07:21, 16/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >В своей безобидной проге/модуле/патче, я пишу:
    >-----------------------------
    >#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++
    Так что вы в своей программы НИКОГДА не должны употреблять ТАКИХ имен переменных
    и проблема просто испаряется ...

     

  • 1.9, Fantamas (?), 14:25, 15/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    первое предложение первого поста очень понравилось. супер. ранньше юзал Линукс, а теперь не юзаю т.г. гавно. больше всех отличилась Шапка, когда пол поменяла. Все это фигня. Я еще не отрезвел после вчера, но ворнинг это будующая ошибка. причем тут спор я не понимаю. наверное решили ошибок наделать. :-)))))
     
  • 1.16, Вася (?), 02:28, 17/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    да, информация полезная, кто себя считает умным пусть попьет молока, сказано по дулу
     
  • 1.17, liks (??), 09:42, 17/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Бред какой-то написали, опять какие-то религиозные войны, не более того. Посмотрите одну из стабильных версия ядра linux и сравнивайте с тем же freebsd. А то прям горазды нечетные ядра обсуждать я смотрю.

    Наезд на шапку не понял, объясните пожалуйста. Red Hat кстати очень многое делает для стабилизации ядра и его ядро одно из лучших на продакшн системах.

     
     
  • 2.18, _Nick_ (??), 09:48, 17/05/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Бред какой-то написали, опять какие-то религиозные войны, не более того.

    а что ты хотел получить из треда на форуме?
    Ты можешь сказать нечто большее, чем что-либо сказанное до тебя??

    вряд-ли. зачем тогда на других наежать?


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


     

  • 1.21, scum (??), 19:20, 25/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Или 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 рулит"!

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру