Dovecot переходит на CLang

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

Тяжело писать по стандарту, больно не переносимый он, местами. Опять же, visual studio например не умеет ll в printf :(

У автора водянка?

Dovecot поставляется в виде исходников - чем хочешь (точнее чем можешь) тем и собирай (GCC/PCC/Clang/ICC). Вообще, кто здесь использует самособранный Dovecot? 1%?

Завтра они скажут, что переходят на MSVC/ICC, ибо там невероятное увеличение скорости ещё на ... 0.5% Прикажете всем дистрам срочно выкинуть GCC и пересобирать всё MSVC/ICC?

Куда катится мир.

Это ничего, что сообщение в блоге - 2 месяца от роду? И что автор решил остаться на GCC?

Timo Sirainen 2 months ago

Looks like clang still isn't ready, back to gcc :(

http://llvm.org/bugs/show_bug.cgi?id=6667

http://llvm.org/bugs/show_bug.cgi?id=6668

http://llvm.org/bugs/show_bug.cgi?id=6675

>Похоже, что это первый из наиболее крупных проектов, которые официально сказали что CLang/LLVM это mainstream.

Looks like clang still isn't ready, back to gcc :(

Это пять.
Сколько пафоса, и все впустую.

Перый?.. А Apple?

catap, иди спать лучше - скоро на работу! :)

~ # CC=clang CXX=clang-c++ emerge -1Bva dovecot

These are the packages that would be built, in order:

Calculating dependencies... done!
[ebuild N ] net-mail/dovecot-1.2.11-r2 USE=«bzip2 ipv6 maildir mysql pam ssl zlib -berkdb -caps -cydir -dbox -doc -kerberos -ldap -managesieve -mbox -postgres -sieve -sqlite -suid -vpopmail» 0 kB

...

Completed installing dovecot-1.2.11-r2 into /var/tmp/portage/net-mail/dovecot-1.2.11-r2/image/

сборка прошла успешно и даже без предупреждений

Dovecot поставляется в виде исходников - чем хочешь (точнее чем можешь) тем и собирай (GCC/PCC/Clang/ICC).

Просто однажды придет день, когда он соберется только силэнгом :)

А есть тут умельцы, собравшие clang'ом генту?
Как успехи?

> http://llvm.org/bugs/show_bug.cgi?id=6667

чувак хочет «Each undeclared identifier is reported only once for each function it appears in», и это мелочь, на которую противополжные взгляды могут быть

http://llvm.org/bugs/show_bug.cgi?id=6668

Doug fixed this in r 98898.

http://llvm.org/bugs/show_bug.cgi?id=6675

это да, хотя они обещают сделать

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

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

ну и скорость тоже

я думаю стандарт не кто специально ломать не буедт

>лучше бы писали по стандартам
Значит автор dovecot пусть пишет по стандартам, а то что все остальное (ядро, glibc) заточено под gcc это нормально ?

Да, это нормально. glibc - это часть проекта GNU, собираться неГНУ инструментарием оно не обязано никому. Про ядро много говорилось, фактически оно тоже часть проекта, потому что работает в основном в гнушном окружении, а значит нет смысла собирать его сторонними компиляторами.

В общем не надо сравнивать системные компоненты GNU с обычными, относительно кросплатформенными приложениями:)

А ничего что сторонним приложениям приходится инклутить заголовочные файлы из glib ? в которых дохрена gcc-specific кода. Тоесть можешь собирать любым - но будет работать только с gcc. Офигеть позиция ;-)

оно по идее должно инклудить только glibc

а оно на самом деле достаточно кроскопилируемое

И этим http://zi.fi/shots/clang.png кто-то пользуется? Лучше бы автор не показывал этот скриншот, теперь никогда не поставлю Dovecot.

7% - это не серьёзно и ничего не доказывает. На одном процессоре оно может быть на 7% быстрее, зато на другом на 10% медленнее.

> И этим http://zi.fi/shots/clang.png кто-то пользуется? Лучше бы автор не показывал этот скриншот, теперь никогда не поставлю Dovecot.

Простите, вы идиот?

вы до сих пор думаете, что в скорости дело?

>Простите, вы идиот?

Нет, надеюсь :) Но таким методом отлаживать программы, особенно играя с синтаксисом и по этому параметру выбирая какой компилятор лучше, ИМХО, говорит о некомпетентности разработчика, раз он не может фильтровать входные и исходящие данные. По мне, автор просто хочет или очень надеется, что якобы компилятор должен «телепатически» узнавать все «тонкости» авторского кодинга. За одну такую мысль уже стоит задуматся о надежности такого кода.

Зря Вы так о Тимо.

http://www.dovecot.org/doc/securecoding.txt

>я думаю стандарт *не кто* специально ломать не буедт

никто

ппц

>вы до сих пор думаете, что в скорости дело?

Ну а в чём же ещё? Чтобы говорить, что оно действительно бытрее, надо протестировать на всех моделях (и даже ревизиях) поддерживаемых процессоров. Это на бумаге они все стандартизированы, а там инженеры могли таких подводных камней понапихать...

r00t@r00t:~$ cat /etc/slackware-version
Slackware 12.2.0
r00t@r00t:~$ clang
-bash: clang: command not found
r00t@r00t:~$

вывод: ФФТОПКУ!!!
не хватало мне только стороннее какое-то поделие устанавливать (а то и собирать) ради какого-то-там довекота.

Слава Хаосу, в GNU достаточно мыльниц (с разумными разработчиками) и без этого поделия.

r00t@r00t:~$ cat /etc/slackware-version
Slackware 12.2.0
r00t@r00t:~$ clang
-bash: clang: command not found
r00t@r00t:~$

вывод: ФФТОПКУ!!!

Я смотрю ты прям полномасштабное исследование провел, ага.

По моему, кто-то выдает желаемое за действительное, подтверждая такие новости.

> Но таким методом отлаживать программы, особенно играя с синтаксисом и по этому параметру выбирая какой компилятор лучше, ИМХО, говорит о некомпетентности разработчика, раз он не может фильтровать входные и исходящие данные. По мне, автор просто хочет или очень надеется, что якобы компилятор должен «телепатически» узнавать все «тонкости» авторского кодинга. За одну такую мысль уже стоит задуматся о надежности такого кода.

Видите ли какое дело, людям свойственно ошибаться. Поэтому чем больше будет возможностей отлавливать ошибки в коде автоматически — тем лучше. То, что автор заботится об этом, как раз положительно характеризует его. Насчет «не может фильтровать входные и исходящие данные» — не понял.

поделье - это вы

llvm и clang уже давно не поделье. Над ним рабоатю очень хорошие инженеры

>> вы до сих пор думаете, что в скорости дело?

Ну а в чём же ещё?

1. лицензия

2. глубина статического анализа

Молодой человек, о Вашем уровне (не)компетенции (нужное - подчеркнуть) говорит Ваш блог вообще и конкретно пост от 16.01.10. В котором Вы хвалитесь тем фактом, что таки сумели освоить mod_rewrite (честь Вам и хвала!).

У меня же почтовый сервер в пике обрабатывает до 200 писем в секунду. И, хотя на этом сервере dovecot работает уже 1.5 года (и, кстати, аптайм сервера сейчас 482 суток), меня совершенно не радует заманчивая перспектива пользоваться нестабильным и плохо оттестированным софтом, которым CLang, без сомнения, является: хотели «как лучше», а получилось «как всегда». В настоящий момент я не вижу альтернативы GCC.

И если Вам (от безделья или школьных понтов) сильно хочется покрасоваться перед девочками и выпендриться, то лично мне хочется, чтобы хорошо сделанный, отлаженный и стабильный софт просто работал.

http://zi.fi/shots/clang.png

однозначно позитивный скриншот

кстати, приведу еще позитивчика:

gcc:
test2.cxx:12: error: ‘struct Alias<n, D>::Arr’ is not a type

clang:
test.cpp:12:63: error: missing 'typename' prior to dependent type name 'Alias<n, D>::Arr'
template<uint n, class D> float scalar_product( Array<D>& x,  Alias< n, D >::Arr& y ) { return 0; }
                                                              ^~~~~~~~~~~~~~~~~~
                                                              typename 

Dovecot не без причины считается лучшим и секурным IMAP-сервером, а красноглазить не стоит. Пусть автор юзает для разработки то, что ему удобно, если это приносит такой результат.

>Насчет «не может фильтровать входные и исходящие данные» — не понял.

I actually wanted to start using clang a long time ago, but it didn't give enough warnings. Many important warnings, like not verifying printf() parameters, were completely missing. So I kept using gcc..

Не спорю о профессионализме, но отладка параметров функции решается многими методами, авторский путь мне не ясен по своей нелогичности. Во-первых, можно взглянуть во внутрь clang/gcc и обратится прямо к нужным функциям, можно _подумать_ головой о том, какие же я данные собираюсь отдать в функцию?
То чем занимается автор больше подходит на «хакинг» clang'а и его дебаг в поисках уязвимых мест, за это конечно респект. Но вот на основе этого выбирать компилятор для своей программы, вместо рефакторинга кода, включения дополнительных проверок и т.п., мне видимо не понять.

Тут уже нарисовали приколов из CLang'а.
И, подозреваю, ещё больше косяков вылезет, если ЭТО попробовать собрать под х86_64 (или вообще под отличную от х86 архитектуру).

Dovecot не без причины считается лучшим и секурным IMAP-сервером

Нууу. Далеко не всё так хорошо в Датском Королевстве. Тем не менее, для сельской местности сойдет.

особый прикол в том, что ж++, говоря «‘struct Alias<n, D>::Arr’ is not a type», врал мне в глаза — он *являлся* типом, т.к. других специализаций просто не было; да, ж++ имел по стандарту полное право об этом не знать, но зачем же врать?

а вот clang насчет typename прав на 100%

http://stackoverflow.com/questions/1301380/g-is-not-a-type-error

у меня нет не почтового сервера, не толком http

не мои это задачи и жутко мне не интересные

clang уже используется apple как инструмент статического анализа (да, это пока еще не компилятор, который к продакшену)

с другой стороны должно быть очевидно, что в условиях линукса отказ от gcc будет равнозначен уходу с linux. Поэтому, если даже автор лично будет пользоваться clang, это не будет значит, что он не будет собираться с помощью gcc (тем более clang более чист, в плане стандарта)

> И, подозреваю, ещё больше косяков вылезет, если ЭТО попробовать собрать под х86_64 (или вообще под отличную от х86 архитектуру).

clang вообще от архитектуры независит

> Во-первых, можно взглянуть во внутрь clang/gcc и обратится прямо к нужным функциям

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

можно _подумать_ головой о том, какие же я данные собираюсь отдать в функцию?

Если следовать вашей логике, то все отладочные средства и сами отладчики можно выбросить, ведь если подумать головой, то ошибок не будет. Так что ли?

А сервера у Вас, Великий и Могучий Системный Администратор, тоже на слаке? В любом случае, не вижу ни одной причины использовать это поделие вообще где-то. Тем более, с Вашей-то позицией.

Похоже, что это первый из наиболее крупных проектов, которые >официально сказали что CLang/LLVM это mainstream.

Автор не совсем в теме. Apple - главный спонсор, «говорит» об этом уже
несколько лет.
мои две копейки в топку (LLVM C++ interpreter):
http://cern.ch/onuchin/LLVM/

> у меня нет не почтового сервера, не толком http

Выучите уже русский, пожалуйста. Читать противно. В данном предложении нужно использовать частицу «ни» вместо «не» в обоих случаях.

>Apple - главный спонсор, «говорит» об этом уже несколько лет.

Они уже собирают ним свою макось? Нет? Почему же? Не готово для продакшена?

>А есть тут умельцы, собравшие clang'ом генту?

Как успехи?

отдельные второстепенные пакеты собирала им, прекрасно работает, пока без нареканий, целиком - не пробовала

У меня позиция достаточно ясная:
если система проходит аудит PCI DSS, значит оно вполне приемлемо.

Slackware, как раз, входит в список рекомендованных ОС для PCI DSS.

А вот будет ли входить в тот список собранный CLang'ом софт - лично для меня большая загадка. И, почему-то, есть мнение, что не будет.

Хм. Окей. Я бы попробовал, но там пока плюсы только в транке, AFAIK. Как-то даже лениво шевелиться. Но раз им уже и boost почти собрали, и qt - скоро можно будет.

> http://stackoverflow.com/questions/1301380/g-is-not-a-type-error

одно дело «is assumed not to name a type», как сказано в стандарте, и совсем другое — «is not a type» как говорит ж++

> У меня позиция достаточно ясная: если система проходит аудит PCI DSS, значит оно вполне приемлемо.

и каким образом слака или Dovecot к PCI DSS?

(прочел оттуда 5. Use and regularly update anti-virus software on all systems commonly affected by malware... глубоко задумался...)

Новость непонятно о чём. Эмоциональное что-то кого-то, кто хочет побыстрее закопать gcc.