The OpenNET Project / Index page

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

Результаты пересборки пакетной базы Debian при помощи Clang 10

03.06.2020 20:09

Сильвестр Ледрю (Sylvestre Ledru) опубликовал результат пересборки архива пакетов Debian GNU/Linux с использованием компилятора Clang 10 вместо GCC. Из 31014 пакетов не удалось собрать 1400 (4.5%), но применив к инструментарию Debian дополнительный патч число несобранных пакетов удалось уменьшить до 1110 (3.6%). Для сравнения при сборке в Clang 8 и 9 число пакетов, которые не удалось собрать, держалось на уровне 4.9%.

При проведении эксперимента со сборкой внимание было сосредоточено на 250 проблемах, вызванных сбоем из-за ошибки в Qmake, и 177 проблемах, связанных с генерацией различных символов в библиотеках. Добавив простой патч к dpkg-gensymbols, обрабатывающий ошибку сравнения символов при связывании как предупреждение, и заменив в qmake конфигурационные файлы g++ удалось устранить сбои при сборке примерно 290 пакетов.

Из остальных проблем, приводящих к сбою при сборке в Clang, наиболее часто встречаются ошибки из-за отсутствия некоторых заголовочных файлов, приведения типов, отсутствия пробела между литералом и идентификатором, проблемы со связыванием, отсутствие возврата значения из не-void функции, использование упорядоченного сравнения указателя с нулём, отсутствие определений.

  1. Главная ссылка к новости (https://sylvestre.ledru.info/b...)
  2. OpenNews: Эксперимент по пересборке Debian с использованием Clang показал неожиданно хорошие результаты
  3. OpenNews: Релиз набора компиляторов LLVM 10.0
  4. OpenNews: Google перешел на Clang при формировании сборки Chrome для Linux
  5. OpenNews: Обеспечена возможность сборки ядер Linux 4.4 и 4.9 при помощи Clang
  6. OpenNews: Экспериментальная поддержка пересборки ядра Linux в Clang с механизмом защиты CFI
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/53081-debian
Ключевые слова: debian, clang
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (79) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 20:19, 03/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +18 +/
    Напомните, зачем нужно переходить на шланг?
     
     
  • 2.2, Fracta1L (ok), 20:21, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • –22 +/
    Чтобы отвязаться от поехавшего GNU
     
     
  • 3.5, Аноним (5), 20:22, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +20 +/
    Слушай... можешь компилятор С++ написать, но чтоб без сишных дыреней? На питоне норм будет думаю
     
     
  • 4.8, Fracta1L (ok), 20:38, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • –36 +/
    С и С++ нужно закопать и хлоркой засыпать, это единственное лечение.
     
     
  • 5.10, Ванёк (?), 20:45, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Что, все дружно переходим на JavaScript? А потом снова на C/C++?
     
     
  • 6.32, BrainFucker (ok), 00:25, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А потом снова на C/C++?

    Написанном на JavaScript.

     
  • 5.11, Корец (?), 20:47, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что предлагаешь взамен? Или как обычно - пустой звук и ничего больше?
     
     
  • 6.14, анонимно (?), 20:49, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    golang
     
  • 6.15, Fracta1L (ok), 21:01, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Rust и Go!
     
     
  • 7.16, ghost (??), 21:11, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Идея "хорошая". Производители железа оценят.
     
     
  • 8.24, коржик (?), 22:06, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +8 +/
    раст по производительности сопоставим с c , зря вы так ... текст свёрнут, показать
     
     
  • 9.49, sdaasd (?), 13:15, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Может потому-что он больше в сторону C ... текст свёрнут, показать
     
  • 7.71, 0x3A59 (?), 07:20, 05/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Rust и Go!

    Metaprog!

     
  • 6.52, zshfan (ok), 18:08, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Язык Ада например, защищён от выстрелов в ногу архитектурно (я любитель пистона если что)...
     
     
  • 7.58, Michael Shigorin (ok), 22:04, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Говорят, надо просто ногу брать соответствующего масштаба -- и всё получится (я много писал на модуле-2, если что).
     
     
  • 8.73, Брат Анон (?), 11:52, 05/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Модула-2 -- неси зачётку, Шигорин Сдал ... текст свёрнут, показать
     
  • 7.60, erthink (ok), 22:19, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Язык Ада например, защищён от выстрелов в ногу архитектурно (я любитель пистона
    > если что)...

    Ада нередко не то что в ногу, но и вообще не стреляет.
    Однако, хуже когда стреляет не в ту сторону, можно в голову попасть.

    ;)

     
     
  • 8.74, Брат Анон (?), 11:54, 05/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не пиши чушь Ада явно лучше С С Её с избытком придумали, но всё солидно А е... текст свёрнут, показать
     
     
  • 9.78, erthink (ok), 18:48, 05/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это не чушь, а объективная реальность Грубо говоря, по совокупности _разных_ пр... текст свёрнут, показать
     
     
  • 10.80, Зз (?), 23:35, 05/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Разбудите меня через 150 лет и я скажу вам, что делают на форуме програмистов... текст свёрнут, показать
     
     
  • 11.81, erthink (ok), 01:00, 06/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    1 ... текст свёрнут, показать
     
  • 5.31, Аноним (-), 00:18, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > С и С++ нужно закопать и хлоркой засыпать

    О, дарю идею - сделай secure delete файла с линуксным (или какое там у тебя) ядром ОС :)

     
     
  • 6.59, Michael Shigorin (ok), 22:05, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> С и С++ нужно закопать и хлоркой засыпать
    > сделай secure delete файла с линуксным (или какое там у тебя) ядром ОС :)

    Думаете, он способен написать соответствующую утилиту на растиго?

     
  • 4.13, Ванёк (?), 20:48, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    1) С каких пор у Питона меньше дыр? 2) А просадку производительности на порядок при переходе на Питон на всех компьютерах мира кто, как и чем будет компенсировать? 3) И процессорах дыры. Тоже заменим на Питон???
     
     
  • 5.30, Аноним (-), 00:16, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > 1) С каких пор у Питона меньше дыр?

    Там вон эпическая новость про разнос вебсервисов цыски через питонятину. Им так лихо толпу майнеров вгрузили =)

     
  • 5.56, Аноним84701 (ok), 19:33, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Слушай... можешь компилятор С++ написать, но чтоб без сишных дыреней? На питоне норм будет думаю
    > 1) С каких пор у Питона меньше дыр?
    > 2) А просадку производительности на порядок при переходе на Питон на всех компьютерах мира кто, как и чем будет компенсировать?

    Просадка результирующего бинарника в производительности "на порядок", именно из-за ЯП компилятора (а не п(р)ограммиста этого компилятора) ...
    Н-да, чего только не узнаешь на опеннете 🙄

     
     
  • 6.61, Michael Shigorin (ok), 22:29, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Полагаете, тот парень ещё и оптимизатор на питоне изобразить сможет -- да такой, чтоб в этой пятилетке что-то на гора выдал?..
     
     
  • 7.67, Аноним84701 (ok), 23:36, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Полагаете, тот парень ещё и оптимизатор на питоне изобразить сможет -- да
    > такой, чтоб в этой пятилетке что-то на гора выдал?..

    Полагаю, что все же не стоит смешивать мух с котлетами, т.е. ЯП компилятора и результат. Тот же PyPy спокойно генерирует машкод для JIT.
    Ну а так да, в одиночку, да с полной поддержкой C++17/20 ... первая реализация плюсов, вроде как, являлась транслятором в Си (и Бъерн писал ее не вечерами после работы, а будучи на зарплате Белл Лабс).
    Да и потом, помнится, ту же реализацию С++98 ждали несколько лет.
    Так что  условия изначально "немного" нереалистичны.


     
  • 4.19, Аноним (19), 21:44, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Написал: http://compcert.inria.fr/
     
  • 3.29, Аноним (29), 00:15, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Чтобы отвязаться от поехавшего GNU

    И привязаться к совсем поехавшему эплу и всепожирающему гуглу...

     
     
  • 4.36, Fracta1L (ok), 07:51, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Лицензия Апач - так себе привязка

     
     
  • 5.42, Аноним (42), 12:25, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Там целый букет лицензий. Наверное, специально так, чтоб мозги запудрить. Но это не отменяет того, что оно под пятой у Яббла.
     
  • 3.41, Wolfy (?), 10:09, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >отвязаться от поехавшего GNU

    Слава IBM и Microsoft!

     
     
  • 4.43, Аноним (42), 12:25, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    и Apple!
     
     
  • 5.46, Wolfy (?), 12:43, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Apple это больше про BSD. А Microsoft love Linux.
     
  • 2.3, Аноним (5), 20:21, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наверно чтобы... а хер знает, не зачем наверно
     
  • 2.4, A.Stahl (ok), 20:21, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Никто никуда переходить не собирается, но иметь запасной вариант всегда хорошо.
     
  • 2.6, Аноним (6), 20:25, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +12 +/
    переходить может и не нужно. А вот выявить при пересборке не соответствующие стандарту компиляторо-специфичные костыли - дело очень полезное.
     
     
  • 3.9, Аноним (9), 20:42, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Аналогично действую. При кроссплатформенной разработке отладка в различных системах позволяет добиться качества кода и поймать некоторые ошибки.
     
     
  • 4.62, Michael Shigorin (ok), 22:30, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вот вам двоим на заметку: http://mcst.ru/lab
     
     
  • 5.75, RomanCh (ok), 14:58, 05/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я всё понимаю конечно, но очень смешно выглядит п.7:

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

    Неужели всё так ужасающе плохо, что можно получить результаты за которые будет вот прямо настолько стыдно?

    PS Публикация шаблона заявки в MS Word формате, да ещё и с макросами - это прекрасно.

     
     
  • 6.76, Michael Shigorin (ok), 16:42, 05/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> обязательства не публиковать результаты без предварительного
    >> согласования.
    > Неужели всё так ужасающе плохо, что можно получить результаты
    > за которые будет вот прямо настолько стыдно?

    Порой собирают вообще без оптимизации, насколько до меня долетало... в таких случаях на VLIW всё и впрямь плохо.

    Мы вон до сих пор вылавливаем апстримы, сборочные системы которых забивают на CFLAGS/CXXFLAGS, и в лучшем случае суют -O2 там, где хорошо бы -O3 (по крайней мере выпуски на lcc 1.23 у нас собраны именно так и им это явно пошло на пользу).

     
     
  • 7.77, RomanCh (ok), 16:57, 05/06/2020 [^] [^^] [^^^] [ответить]  
  • +/

    > Порой собирают вообще без оптимизации, насколько до меня долетало...

    Спасибо, понятно. Хотя всё равно странно, ведь оптимизация обычно не даёт прямо космического прироста производительности, даже в разы, не то что на порядки. Т.е. её отсутствие не должно давать в итоге катастрофический результат.

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

     
  • 7.83, mikhailnov (ok), 14:04, 08/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А вот если бы сборочница не пропускала пустой debuginfo, то большая часть апстримов, забивающих на CFLAGS, была бы выявлена и исправлена
     
  • 2.7, Аноним (7), 20:31, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • –16 +/
    Вопрос скорее "Зачем оставаться на GCC". Прогресса со второй версии чайная ложка, до сих пор не умеет корректно высокие уровни оптимизации, генерит код, который повреждает память и продолжает работать дальше не генерируя ексцепшена, сборка под определённую архитектуру может "случайно" использовать левые команды процессора…


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

     
     
  • 3.12, erthink (ok), 20:48, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Вы clang и gcc попутали
     
  • 3.17, Аноним (17), 21:30, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >код работает так как написано в исходнике

    угу. Тыкал одну из библиотек с поддержкой бенчмарков, так clang, в отличие от gcc, взял и выкорчевал вызовы функций, время выполнения которых пытался замерить. При этом все необходимые переменные, которые после такого стали ненужными, он решил оставить и рассчитать.

     
  • 3.23, Аноним (23), 22:01, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    У шланга высокие уровни оптимизации не особо от низких отличаются. А всё потому, что он способен оптимизировать только лапшой из goto. В gcc оптимизации уровня O3 и не включённые в него включаются в pgo. Остальное баги и регрессии, они исправляются (регулярно). Слишком много изменений происходит в нём, тут ты совершенно неправ.
     
  • 2.21, Ordu (ok), 21:51, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    just for fun.
     
     
  • 3.26, Аноним (26), 22:32, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Первый коммент по делу
     
     
  • 4.57, Аноним (57), 20:19, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Второй коммент тоже по делу.
     
  • 3.44, Аноним (42), 12:35, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    just for YOBA (Youth Oriented, Bydlo-Approved)
     
     
  • 4.69, Ordu (ok), 00:09, 05/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > just for YOBA (Youth Oriented, Bydlo-Approved)

    Естественно, это не для старпёров. Старпёры пускай водку жрут да в свою Nintendo рубятся, никакой другой fun им недоступен уже.

     
  • 2.34, Аномсис (?), 04:57, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Можно будет все пакеты распространять в уже оптимизированном биткоде LLVM, а при установке они будут быстро компилироваться  с оптимизацией по-максимуму под архитектуру процессора. При этом скорость компиляции будет намного быстрее, чем из изходников C/C++. А в репозитории будет храниться всего одна пакетная база, универсальная, под все архитектуры.
    Для сравнения, сейчас репозитории содержат разные ветки, каждая скомпилирована под свою архитектуру.
    Если это x86, то компиляция там под i686, т.е. в оптимизации не задействованы функции новых процессоров. Кто хочет задействовать свой процессор по-максимуму, им приходится самим компилировать под свой процессор. А из исходников это очень долго.
     
     
  • 3.35, Аноним (23), 06:27, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Если это x86, то компиляция там под i686, т.е. в оптимизации не задействованы функции новых процессоров. Кто хочет задействовать свой процессор по-максимуму, им приходится

    А подо что ты там компилировать собрался, под нетбурст? Нынешние процессоры к нему никакого отношения не имеют. Или ты рассчитываешь на simd оптимизации? Это только если в приложении они есть (ручные), на этой почве совершенно не важно для чего 32 битный код компилировать (зачем его вообще компилировать). А по поводу amd64, очень часто оптимизация arch под core2 оказывается быстрее native, так что вот так.

    И кстати не взлетит, самый быстрый шланг обычно оказывается медленней gcc+pgo. Намного быстрее наверно не будет, самое тяжолое и муторное это как раз линковка.

     
  • 3.45, Аноним (42), 12:39, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Можно будет все пакеты распространять в уже оптимизированном биткоде LLVM

    Для вас, любителей блобов, и проприерасов уже придумали WASM.

     
     
  • 4.82, Аноним (82), 09:17, 08/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Попробуйте на этом васме видеокодек запустить
     
  • 2.38, Аноним (38), 09:18, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это ZOG дурацкую работу подкидывает, чтобы отвлечь ресурсы.

    Так было с сырым python3 лет 10 назад. (Поддерживать два языка проэкту труднее и более ресурсоемко чем один, код становится жирнее и сложнее)

     
  • 2.40, DerRoteBaron (ok), 09:36, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя бы чтобы почистить код от совсем упоротых GNU-хаков и ошибок, возникающих из-за них. Ну и чтобы не давать GCC застрять на месте. Они как после появления рабочего шланга (или пинков от Линуса) проснулись и начали снова делать приличный тулчейн.
     
  • 2.50, freehck (ok), 14:08, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Напомните, зачем нужно переходить на шланг?

    Вопрос не в переходе, а в проверке сборки другим сторонним компилятором. Де факто это конкуренция, что в общем-то хорошо, ибо она позволит:
    1) иметь компилятор про запас, если один в силу каких-то обстоятельств загнётся / остановится в развитии,
    2) найти больше ошибок, ибо то, что один компилятор проглотит, второй может и не проглотить, и выдать ворнинг или же вообще завалиться

     
     
  • 3.63, Michael Shigorin (ok), 22:34, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Вопрос не в переходе, а в проверке сборки другим сторонним компилятором.

    Скажу больше -- чтобы избежать вендорлока.  К сожалению, RMS явно рассматривает компилятор (точнее, gnu extensions) как оружие.  В смысле мне рассказывали о письмах проектам с просьбой отвергать патчи, позволяющие собраться clang.  Меня такое крайне напрягло.

    PS: nested functions нет (и, вероятно, не будет) больше нигде; плюс VLAIS.

     
     
  • 4.65, freehck (ok), 23:05, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > К сожалению, RMS явно рассматривает компилятор (точнее, gnu extensions) как оружие.

    Если по-твоему это "к сожалению", то вероятно ты не вполне понимаешь мотивы Ричарда.

     
  • 2.79, Gogi (??), 19:00, 05/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем склеротикам вообще задавать такие вопросы? Кушайте свои таблеточки, не мешайте продукту развиваться.
     

  • 1.18, Anonymus (?), 21:30, 03/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >отсутствия некоторых заголовочных файлов

    Это да, не суметь скомпилировать простенький "Hello World!" на C99 из-за потери собственных библиотек - это что-то...

    >возврат не-void функцией какого-то значения

    А вот тут не понял, что не так-то? Или это опечатка?

    >использование сравнения указателя с нулём

    Да, зачем проверять что-то, действительно.

     
     
  • 2.20, Ordu (ok), 21:51, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> возврат не-void функцией какого-то значения
    > А вот тут не понял, что не так-то?

    Какой смысл в этом? Бессмыслицу в языках программирования нужно выжигать калёным железом. Она хороша только для обфускации кода и больше ни для чего.

    >> использование сравнения указателя с нулём
    > Да, зачем проверять что-то, действительно.

    Проверять нужно, но не нужно при этом приводить указатели к int'у или int'ы к указателю. Если уж очень нужно, сделай это явно. Если явно писать преобразование влом, то для сравнения есть макро NULL.

     
     
  • 3.33, userd (ok), 00:47, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >>> возврат не-void функцией какого-то значения
    >> А вот тут не понял, что не так-то?
    > Какой смысл в этом? Бессмыслицу в языках программирования нужно выжигать калёным железом. Она хороша только для обфускации кода и больше ни для чего.

    В новости как-то нехорошо перевели проблемы.
    На странице https://clang.debian.net/ это называется «non-void function should return a value»
    типа «error: non-void function 'u_free' should return a value»

    Это скорее всего какие-то ошибки в логике.

    >>> использование сравнения указателя с нулём
    >> Да, зачем проверять что-то, действительно.
    > Проверять нужно, но не нужно при этом приводить указатели к int'у или int'ы к указателю. Если уж очень нужно, сделай это явно. Если явно писать преобразование влом, то для сравнения есть макро NULL.

    Никто не приводит указатели к int'у или int'ы к указателю :)
    Опять-же, в источнике речь идёт не просто о сравнении, а об упорядоченном сравнении.
    Типа «error: ordered comparison between pointer and zero ('int *' and 'int')»
    в выражении «if (iPos >= 0) {»
    Так-то неупорядоченное сравнение типа == и != делайте сколько угодно, NULL тут не причём.
    И это тоже скорее всего какие-то ошибки в логике обусловленные изменением типа переменной либо некритичной копи-пастой.

    Ждём выступления товарища из команды PVS-Studio с рассказом как его софт позволяет избежать таких вот неприятностей :)

     
  • 2.22, Аноним84701 (ok), 21:53, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >>использование сравнения указателя с нулём
    > Да, зачем проверять что-то, действительно.

    Да, зачем смотреть в чем дело, действтительно:
    [code]
    domain.c:119:23: error: expression which evaluates to zero treated as a null pointer constant of type 'char *' [-Werror,-Wnon-literal-null-conversion]
                hashPtr = '\0';
                          ^~~~
    [/code]
    контекст:
    [code]
    /* Is line a comment - ignore everything after '#' character */
            if (NULL != (hashPtr = strchr(linePtr, '#'))) {
                hashPtr = '\0';
            }
    [/code]

    Подумаешь, баг в логике  (ну или опечатку/забытый *) нашли ...

     
  • 2.27, Аноним (27), 23:13, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А вот тут не понял, что не так-то? Или это опечатка?

    Сижу и не могу воткнуть. Скорее всего опечатка

     

  • 1.25, Аноним (25), 22:22, 03/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Когда с msvc протестируют?
     
     
  • 2.28, DontTreadOnMe (?), 23:26, 03/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Сначала msvc надо нормальный си научить компилять. Потом добавить ему гнутые расширения. И только потом можно подумать о тестировании.
     
     
  • 3.47, Аноним (42), 12:44, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И научить MSVC в ELF генерить.
     

  • 1.37, Аноним (37), 09:04, 04/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А зачем? Под эппл лежать приятнее?
     
     
  • 2.48, Аноним (42), 12:45, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ещё бы, аж до гланд достаёт!
     
  • 2.51, Wolfy (?), 14:20, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Чем IBM и Microsoft лучше Apple?
     
     
  • 3.64, Michael Shigorin (ok), 22:40, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Чем IBM и Microsoft лучше Apple?

    Пока что чуть традиционнее (хотя бы на публику).

     
     
  • 4.66, Wolfy (?), 23:10, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Учитывая, что все трое — сионисты, очень сомнительное утверждение.
     
  • 2.54, Аноним (54), 18:53, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Поддерживая одновременно и gcc и clang, мы не лежим ни под GNU ни под Apple.
     
     
  • 3.55, erthink (ok), 19:03, 04/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Поддерживая одновременно и gcc и clang, мы не лежим ни под GNU
    > ни под Apple.

    Разработчики с пониженной компиляторной ответственностью?

    ;)

     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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