> Название _C_lang как бы намекает.

что поддерживаются C/C++/Obj-C ( расшифровка для Rakot )

> Никто так и не сказал зачем оно нужно.

Читать не умеешь, да?

Затем, чтобы проще было ядро разрабатывать. Чтобы сообщения об ошибках человеческие были. Чтобы нетривиальные ошибки на этапе компиляции отлавливать. Чтобы код для отладки инструментировать по всякому. Все то, чего gcc не умеет, и уже никогда не научится.

> Ну.. раз пошла такая песня. Xcode не видел. Он лучше Visual Studio ?

http://developer.apple.com/technologies/mac/snowleopard/static.html

в VC2010 тоже есть статический анализ

да и в 2008-м тоже был

> в VC2010 тоже есть статический анализ

Для Си? Нету.

> Для Си? Нету.

http://msdn.microsoft.com/en-us/library/6yz6c9dy(v=VS.100).aspx

он петушиный и находит только совсем тривиальные вещи (насколько хорошо с этим в хкоде увы не смотрел).

> он петушиный и находит только совсем тривиальные вещи

в Xcode 3.х тоже был не фонтан, в четверке еще не смотрел

>http://developer.apple.com/technologies/mac/snowleopard/static.html

Продвинутая защита от опечаток ? От логических ошибок это все равно не защитит :)

то есть даже повторное освобождение указателя он не находил.

GCC тоже сначала назывался GNU C Compiler, так что название ни на что не намекает. А вообще у них планов на другие ЯП нет?

Судя по всему пациент пока скорее мёртв, чем жив.

>пациент пока скорее мёртв, чем жив.

Да, ядро пора закопать.

> А вообще у них планов на другие ЯП нет?

поддержка других языков под llvm есть - Haskell, Ruby, Java, Python и т.д., но это «неофициально», т.е. это делают другие люди, кроме того есть, например, такой проект:

http://vmkit.llvm.org/

Если судить по сайту clang.llvm.org, то он затачивается только на С/С++/Obj C, для всего остального пишуться фронтенды для LLVM, такие как, например, GHC.

>Да, ядро пора закопать.

Всему свое время

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

Самое интересное, что нет, не повысит. Попытка писать код под все компиляторы приводит только к их собираемости, но запутанности и (частичной) неработоспособности.

сборка софта несколькими компиляторами часто помогает найти баги в коде. мы всегда собираем свой софт gcc и visual c++ 10, + регулярно делаем сборки intel c compiler и clang, в процессе таких сборок нашли несколько подозрительных мест, которые оказались настоящими багами. у clang/llvm достаточно хороший анализатор кода, и на его основе есть решения по static analysis (мы правда все равно coverity используем)

>в чём поинт использования каждого такого расширения, например, в ядре Linux?

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

если можно писать на plain C99 как те же BSD?

А зачем? Чтобы получилась еще одна ненужная недоось лайк БЗД? Зачем подражать лузерам?

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

Долго читал их сайт и вики - так и не понял нахрена оно нужно и в чем его плюшки. Если кто знает - просвятите.

> Ассемблер для генерации кода реального режима

А где там реальный режим?

Оно нужно как конкурент gcc.

Похоже на костыль для ленящихся писать юнит-тесты и не знающих про valgrind и про проблему останова.

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

> Попытка писать код под все компиляторы приводит

Писать нужно не под компиляторы, а в соответствии со стандартом. Попытки делать иначе приводят к глючному говну.

С некроссплатформемным байт-кодом ллвм не нужен.

> Компилируются примерно 90% драйверов ядра, многие работают

:D

я про то - чем оно лучше/хуже?

>Писать нужно не под компиляторы, а в соответствии со стандартом. Попытки делать иначе приводят к глючному говну.

здорово, когда получается, но тут есть две трудности.

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

2) Что делать, если в рамках стандарта реализация никак не получается? Расширения потому и пишут, что стандарта не хватает.

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

Авторы любого вменяемого компилятора.

Что делать, если в рамках стандарта реализация никак не получается?

Руки выпрямлять.

Расширения потому и пишут, что стандарта не хватает.

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

Расширений, без которых действительно никак, очень мало. И подозреваю, что llvm их все давно поддерживает.

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

>Авторы любого вменяемого компилятора.

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

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

для этого надо углубиться в вопрос «что в моем компиляторе нестандартного». А этот вопрос для разработчика сугубо вторичен.

Выносом в дефайны обычно занимется как раз тот, кто предпринимает попытку собрать код другим компилером и натыкается на несовместимость.

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

Корректность кода - не самоцель. Я ни разу не видел на форониксе или в исследованиях британских ученых сравнения корректности кода. Измеряют объем машинного кода, потребляемую память, скорость, совместимость, отсутствеи ошибок в результатах, а никак не «корректность кода», что само по себе не измеряемая характеристика, а так, график ректальной температуры читателя.

Зачем эти мадригалы с каким-то Linux kernel нужны ? да и еще отстой под названием gcc... он и так скоро умрет - а тут пытаются делать костыли совместимости с ним.. Нахрена прогибаться под то что сознательно ложило на стандарты?

>> анонсирован проект по адаптации LLVM компилятора CLang к сборке ядра Linux Вах! Будем собирать компьютеры из видеокарт и ставить туда линупс. А что, неплохо довольно:)

> для этого надо углубиться в вопрос «что в моем компиляторе нестандартного»

Ты язык учишь по руководству от компилятора? :D

Корректность кода - не самоцель.

Когда у тебя на руках мегабайты говна, и задача портировать его с gcc3 на gcc4, мнение на этот счёт резко меняется.

С некроссплатформенным GIMPLE GCC не нужен.

Лучше б тебя учитель информатики убил

Для emacs тоже есть такое автодополнение. Использую.

Но то, что GCC уж совсем для этого не пригоден - враньё, есть GCCSense - автодополнение на основе патченного GCC для emacs и vim.

PS. Новость позитивная, раньше ядро Clang-ом практически совсем не собиралось.

Мне как простому пользователю нравятся вменяемые сообщения об ошибках, такие бы да в gcc.

А кто мешает вам использовать Clang?

> Я ни разу не видел на форониксе или в исследованиях британских ученых сравнения корректности кода.

на форониксе

сравнения корректности кода

/0

Тем более, они все нивелируются, если вспомнить, что Clang в сравнении с GCC ничего не умеет.

То, что им собирается 90% софта, называется «ничего не умеет»?

Clang в среднем выигрывает у GCC по быстродействии скомпилированного бинарника, но очень слабо выигрывает.

Иногда занимает. Но сообщения поадекватнее, чем у GCC.

А кто, по вашему, end-user компилятора?

А что, разработчик должен все собирать на супер-производительном компьютере с 8 GB оперативки? :D

90% какого софта, если он только минимальную FreeBSD может собрать? А выигрыш действительно слишком маленький, да и то не везде(в основном в кодеках и архиваторах, но там лучше себя показал ICC).

Мой учитель информатики не видел дальше методички по MS Word 97.

>То, что им собирается 90% софта, называется «ничего не умеет»?

и что-то даже работает...

Останусь на GCC.

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

Даже если LLVM будет выдавать более быстрое ядро, то я останусь на GCC. Но работе LLVM с Linux'ом я рад, потому что это действительно способствует повышению качества кода ядра, вычищению из него gcc-hack'ов, костылей и подпорок.