Комментарии 88
Ждем, когда PVS-студия станет бесплатной и без этих микрософтовских заморочек. Вам главное не упустить момент, когда сообщество решит «Хватит жить без статического анализа», и не станет пилить свой PVS сразу с Clang в качестве препроцессора.
+1
Разработчиков тогда из своего кармана будете кормить?
+11
Наверное имелось ввиду «бесплатно для некоммерческого использования». Хотя мне кажется они уже дают бесплатный дистрибутив для GPL-проектов.
+2
Мы готовы предоставить бесплатную лицензию сроком на 1 месяц студентам, авторам статей в тематических IT изданиях и блогах. А также разработчикам бесплатных open-source программ, если они хотят проверить свои проекты на наличие в них ошибок диагностируемых нашим анализатором.
Если вас заинтересовало наше предложение, то просим написать об этом на support@viva64.com с темой PVS-Studio free license initiative.
+12
<sarcasm>Ну почему же, конкретно для Visual Studio можно оставить платную версию по нынешней цене в €3500 в год.</sarcasm>
-3
Намного дешевле купить готовый анализатор, чем создавать свой
+3
Но только не для сообщества, иначе бы не было целых двух опенсорс браузеров, например.
0
Открытый Firefox знаю. А второй? Chrome закрыт, Opera закрыта, может IE?
-3
Хромиум видимо имеется в виду, а ещё их куда больше чем два.
+2
Я понимаю, что имеется ввиду Chromium (мы его проверяли). Я к тому что Chrome все-таки не такой уж и открытый. И точно не неким мифическим «сообществом» делается.
0
Условия предоставления услуг Google Chrome
Настоящие Условия предоставления услуг распространяются на исполняемый код Google Chrome. Исходный код Google Chrome предоставляется бесплатно на условиях лицензионных соглашений на программное обеспечение с открытым исходным кодом по адресу code.google.com/intl/ru/chromium/terms.html.
www.google.com/chrome/eula.html
+2
>Я понимаю, что имеется ввиду Chromium (мы его проверяли).
И чем вам Хромиум не браузер?
И чем вам Хромиум не браузер?
+1
Закрытый хром, правда?? А это тогда что?
0
Уйма браузеров на вебките(midori, arora, epiphany и т.д), браузер на KHTML — konqueror.
Кроме этого есть links, elinks, w3m. Есть dillo.
Кроме этого есть links, elinks, w3m. Есть dillo.
+1
Мне странно Ваше желание. Мне кажется, Вы не ждете, что в магазинах будут бесплатно раздавать отвертки и гаечные ключи. То, что цена копирования экземпляра программы равна нулю, не означает, что и цена создания продукта равна нулю. Также, Вы забываете, что это класс инструментов с очень дорогой поддержкой. Чтобы ответить на вопрос пользователя/потенциального пользователя требуется квалифицированный человек, а не девочка в торговом центре, которая говорит, где можно выбрать люстру. Часто вопросы требуют серьезного изучения и большого времени на ответ. Это очень дорого. Вот пример, одной такой переписки. Это только ответы на вопросы, а ещё есть работа с пожеланиями пользователей и реализация их в новых версиях.
Продукт подобный PVS-Studio может стать бесплатным только в случае, если кто-то его будет финансировать со стороны. Как, например, Apple финансирует Clang.
Продукт подобный PVS-Studio может стать бесплатным только в случае, если кто-то его будет финансировать со стороны. Как, например, Apple финансирует Clang.
+19
Ждем когда вас купят Microsoft :)
+4
У MS есть свой анализатор. Не такой развитый, возможно. Посмотрим, что изменится с MSVS.vNext
+1
Было бы неплохо, если бы MS начала заниматься правкой своих С++ инструментов, складывается впечатление, что они вообще на native разработку забили.
+2
Да мы уже сами ходим все так:
+10
Я уже спрашивал разработчиков PVS. Открывать сорцы они не планируют, поэтому сообщество поступит именно так — пилить свой PVS на Clang.
0
Я давно умер как программист, но всё равно с удовольствием читаю Ваши статьи об PVS-Studio.
Рад за русский продукт.
Лошадка-которая-Единорог-рыгающий-радугой супер, сразу её визуально видно на главной и рука тянется Подробнее.
Рад за русский продукт.
Лошадка-которая-Единорог-рыгающий-радугой супер, сразу её визуально видно на главной и рука тянется Подробнее.
+10
НЛО прилетело и опубликовало эту надпись здесь
Можно проголосовать. Кому нравится лого, ставьте плюсик этому моему комментарию. Кому не нравится — ставьте плюсик комменту XPilot.
+50
Не хватает заряда проголосовать, но единорог отвртителен. Мало того, что блюющее существо вызывает соответствующий рефлекс, но и радуга — символ людей с нетрадиционной ориентацией. Всё сугубо на правах ИМХО, естественно.
-8
А радуга на небе у вас тоже неприятные ощущения вызывает?
+14
Совсем нет, но радуга на логотипе лично у меня вызывает такую ассоциацию. Возможно потому, что пришлось прожить несколько лет там, где эти флаги можно встретить на каждом углу и они означают они там исключительно одно. Речь о Сан-Франциско.
0
Спасибо за мнение. Теперь я тоже считаю, что «официальные» картинки лучше. Например как эта:
Сразу видно, что такая компания не врет, все делает для людей, и вообще они — молодцы! Не то что мы.
Сразу видно, что такая компания не врет, все делает для людей, и вообще они — молодцы! Не то что мы.
+9
Сами попросили высказать мнение. И не надо путать имидж продукта и непосредственно логотип. Корпоративный стиль Аэрофлота — очень приятный. Другое дело, что вы о нём думаете как о компании. К слову сказать, тот же Аерофлот иногда удивляет очень хорошим обслуживанием на международных рейсах. Хоть это и не отменяет их многочисленные косяки и идиотизм. Но речь не о нём.
Для тех кто в танке — речь о субъективном восприятии вашего логотипа как такого. Извините, если такое мнение вам неприятно.
Для тех кто в танке — речь о субъективном восприятии вашего логотипа как такого. Извините, если такое мнение вам неприятно.
+3
НЛО прилетело и опубликовало эту надпись здесь
Меня больше возмущает что гомосеки заграбастали радугу.
А блюющий радугой единорог — это круто.
А блюющий радугой единорог — это круто.
+14
Ничего плохого не вижу в чем-то неформальном. Пусть даже и в йа-креведке. Я наоборот отношусь с настороженностью к компаниям, у которых все в официальном тоне.
+2
А пока идет голосование, выскажу свой взгляд. Неужели абстрактные картинки чудесных телефонов лучше? Неужели абстрактные блоги не о чем, которые пишутся крупными компаниями «потому что так надо» и«потому что надо освоить бюджет» лучше? Есть много хороших блогов крупных компаний, в том числе и на Хабре, но согласитесь, что большинство «корпоративных» текстов скучны? А мы маленькая живая компания. С которой можно пообщаться. И эта символика — способ выделиться.
P.S. Продолжаем голосовать.
P.S. Продолжаем голосовать.
+3
я чуток устал от текстов «серьезных» компаний
серьезное лицо ещё не признак ума
серьезное лицо ещё не признак ума
+2
Я тоже от них устал. Но однообразные топики «Мы проверили проект *** и в очередной раз убедились, что копи-паст — зло, покупайте наших слонов» с неизменным блюющим единорогом тоже надоели, если честно.
Первые 3-4 раза было свежо и интересно, дальше информативность свелась к полному нулю, а единорог задолбал.
И ладно ещё, если бы делали это в собственном корпоративном блоге (кстати, интересно, почему до сих пор не завели?) — так нет же: в профильных блогах «С++», «Ревизия кода», теперь вот«Компиляторы», к которым сами топики относятся с ну о-о-очень большой натяжкой.
Первые 3-4 раза было свежо и интересно, дальше информативность свелась к полному нулю, а единорог задолбал.
И ладно ещё, если бы делали это в собственном корпоративном блоге (кстати, интересно, почему до сих пор не завели?) — так нет же: в профильных блогах «С++», «Ревизия кода», теперь вот«Компиляторы», к которым сами топики относятся с ну о-о-очень большой натяжкой.
0
Это как любимый сериал… опять знакомые лица, но новая ситуация.
Мне интересно кого проверяют в этот раз… и очень интересно, когда лажают крупные компании. Для меня это как сбить спесь с лица. Маркетинговый бред от дядек в костюмах и с тётеньками на картинках, показывающие иллюзорное светлое будущее их софтварных компаний.
И тут гадский PVS со своей «лошадью», которую рвёт от плохого кода =)
Мне интересно кого проверяют в этот раз… и очень интересно, когда лажают крупные компании. Для меня это как сбить спесь с лица. Маркетинговый бред от дядек в костюмах и с тётеньками на картинках, показывающие иллюзорное светлое будущее их софтварных компаний.
И тут гадский PVS со своей «лошадью», которую рвёт от плохого кода =)
+1
Компания типа Intel находится в творческих поисках наилучшей КДПВ. Но PVS Studio уже использует блюющую радугой лошадку. Дабы не доводить до судебных разборок, мы решили никогда не использовать блюющую лошадку в своих постах.
+6
Ждем когда PVS-Studio будет аналазировать свой собственный код. Было бы интересно посмотреть, какие ошибки они нашли у себя (:
+2
Уже же вроде писали, что они перед коммитами себя анализируют и правят, поэтому нарыть материала на анализ самих себя не могут.
+2
Думаю, они их все исправили ;)
0
Тестирование происходит каждую ночь. А поскольку у нас самих уже достаточно давно включен инкрементальный анализ, всё, что иногда находится, тут же исправляется. Учет найденного я не вёл и написать заметку про это сложно. Из примеров, могу показать сходу только случай, который нашел отражение в документации.
+1
НЛО прилетело и опубликовало эту надпись здесь
>> Если вы будете и дальше следовать своему принципу «пока нам не заказали — мы и не делаем» то вы многого не добьётесь и все ваши подходы к клиентам описанные ранее будут никому не нужны.
Очень и очень круто иметь версии подо все платформы. Правда даже не у всех крупных компаний это получается удачно. А мы — маленькая компания. Поэтому вместо того, чтобы иметь версию, которая «одинаково плохо работает на куче платформ», мы хотим ХОТЯ БЫ научится на одной Visual Studio работать хорошо. Хотя и так уже есть (даже в рамках этой модели) кроссплатформенность. Я имею ввиду VS2005/2008/2010. Уже ТАМ есть отличия и нюансы.
При этом пользователей Visual Studio нам удается порадовать. А если будет монстр, который и на Linux, и на Windows ТЕОРЕТИЧЕСКИ работает, то возможно пользователи VS уже будут страдать.
Очень и очень круто иметь версии подо все платформы. Правда даже не у всех крупных компаний это получается удачно. А мы — маленькая компания. Поэтому вместо того, чтобы иметь версию, которая «одинаково плохо работает на куче платформ», мы хотим ХОТЯ БЫ научится на одной Visual Studio работать хорошо. Хотя и так уже есть (даже в рамках этой модели) кроссплатформенность. Я имею ввиду VS2005/2008/2010. Уже ТАМ есть отличия и нюансы.
При этом пользователей Visual Studio нам удается порадовать. А если будет монстр, который и на Linux, и на Windows ТЕОРЕТИЧЕСКИ работает, то возможно пользователи VS уже будут страдать.
+12
НЛО прилетело и опубликовало эту надпись здесь
>> Как это всё «лёгким движением руки» засунуть под msvs?
А как нам «легким движением руки» поддержать все эти платформы?
>> А вообще странно, что вы захардкодили свой продукт на визуал студию на столько, что «возможно пользователи VS уже будут страдать» в случае расширения поддерживаемых патформ.
Да ладно… Видел я инструменты статического анализа, которые сначала неделю (условно) настраивать надо, прежде чем хоть что-то проверишь. А у нас — скачал и все, сразу работает.
А как нам «легким движением руки» поддержать все эти платформы?
>> А вообще странно, что вы захардкодили свой продукт на визуал студию на столько, что «возможно пользователи VS уже будут страдать» в случае расширения поддерживаемых патформ.
Да ладно… Видел я инструменты статического анализа, которые сначала неделю (условно) настраивать надо, прежде чем хоть что-то проверишь. А у нас — скачал и все, сразу работает.
+1
НЛО прилетело и опубликовало эту надпись здесь
>> Если бы вы выложили на хабре статью вида «почему наш pvs-studio msvs addicted»
Да тыщу раз все это объяснялось и даже в FAQ есть:
www.viva64.com/ru/d/0008/#ID0EZCAE
Да тыщу раз все это объяснялось и даже в FAQ есть:
www.viva64.com/ru/d/0008/#ID0EZCAE
0
Как это всё «лёгким движением руки» засунуть под msvs?
Очень просто — используя CMake или аналог с самого начала разработки, тем более, что продукт кросс-платформенный.
0
Спасибо за комментарий, кстати CMake у нас очень хорошо поддерживается.
+1
НЛО прилетело и опубликовало эту надпись здесь
Сложно поддержать все IDE, а делать IDE-less продукт — терять клиентов. Я когда искал memory leak детектор, то отбрасывал все, что не работает со студией. Мне не удобно запускать несколько разных программ, чтобы комфортно разрабатывать, так что интеграция это нужная фича.
К тому же лучше иметь продукт с ориентацией, в том числе, на MSVS, это позволит использовать не только PVS. Все таки под MSVS много качественных продуктов и сознательно от них отказываться не стоит. Тем более, что это делать не сложно.
К тому же лучше иметь продукт с ориентацией, в том числе, на MSVS, это позволит использовать не только PVS. Все таки под MSVS много качественных продуктов и сознательно от них отказываться не стоит. Тем более, что это делать не сложно.
+1
НЛО прилетело и опубликовало эту надпись здесь
>> Анализатор с++ кода это софтина, которая на входе принимает С++ текст и на выходе даёт отчёт.
Только пользоваться такой фигнёй совершенно неудобно. Так работает, например, PC-lint. И появляются потом к нему всякие фантики типа Visual Lint, самописные прикручивалки к IDE и к IncrediBuild.
А у нас сразу установил и работай. Мы сами фильтруем дублирующиеся сообщения из h-файлов. Мы удобно на лету фильтруем сообщения (не надо перезапускать анализ). Мы сами используем несколько ядер. Мы умеем сохранять и открывать отчет. Нас не надо никуда хитро прописывать, чтобы мы запускались после сборки файлов. У нас удобная справочная система. У нас нормальный диалог прогресса а не чёрное окно в котором мелькают плевки анализатора. И так далее, и так далее. :)
Лучше поддержать меньше, но сделать это хорошо и качественно.
Только пользоваться такой фигнёй совершенно неудобно. Так работает, например, PC-lint. И появляются потом к нему всякие фантики типа Visual Lint, самописные прикручивалки к IDE и к IncrediBuild.
А у нас сразу установил и работай. Мы сами фильтруем дублирующиеся сообщения из h-файлов. Мы удобно на лету фильтруем сообщения (не надо перезапускать анализ). Мы сами используем несколько ядер. Мы умеем сохранять и открывать отчет. Нас не надо никуда хитро прописывать, чтобы мы запускались после сборки файлов. У нас удобная справочная система. У нас нормальный диалог прогресса а не чёрное окно в котором мелькают плевки анализатора. И так далее, и так далее. :)
Лучше поддержать меньше, но сделать это хорошо и качественно.
+2
Ну вообще тема что удобнее — гуй или коммандлайн старая и флеймовая :)
Но если все-таки рассматривать PVS-Studio не только как инструмент рабочего места разработчика, а и как инструмент для автоматического контроля — при чек-ин-ах, например, или при билдах, то коммандлайн версия будет таки удобнее…
Но если все-таки рассматривать PVS-Studio не только как инструмент рабочего места разработчика, а и как инструмент для автоматического контроля — при чек-ин-ах, например, или при билдах, то коммандлайн версия будет таки удобнее…
0
На тему PVS-Studio Standalone и Linux, возможно будет интересна вот эта новая заметка — "PVS-Studio теперь работает и без среды Visual Studio или C++Builder – проверяем препроцессированные файлы от чего угодно".
0
Хочу немного прояснить ситуацию с Linux.
На самом деле мы хотим поддержать большее количество платформ. Но мы имеем холодную трезвую голову и не занимаемся авантюрами. У нас есть хороший иммунитет к призывам «хочется Linux версию». Мы видели, как почти умер один проект, который пытались сделать и вашим, и нашим. Была допущена ошибка, что работа на двух платформах потребует немного дополнительных усилий и это проект можно вести без увеличения команды. Однако часто это означает, что работы станет больше в 2-3 раза. Мы не хотим повторять такую ошибку.
Конечно, не во всяком проекте, поддержка другой платформы увеличивает стоимость разработки в 2 раза. Однако, в случае статического анализатора, произойдет именно это. Основная цена развития статического анализатора, не в том чтобы добавить новое правило и написать документацию. Основные трудозатраты связаны с тем, чтобы проект адекватно себя вёл в различных режимах. Здесь часто звучит, что мы поддерживаем только MSVC. А вот у меня такое осушение, что мы и так уже тянем кроссплатформенную разработку. Мы поддерживаем разные версии компилятора. Например, учитываем, что в VS2005 static_assert это может быть имя переменной, а в VS2010 это новое ключевое слово. Еще есть поддержка разных старых проектов ARMV4 и т.д. У нас разные модули расширения под разные версии Visual Studio (не дай бог вам залезть в такие дебри и узнать почему). Постоянно появляются дополнительные заплатки, чтоб, например плагин работал в русской или немецкой MSVC. У нас очень много различных тестов на базе реальных проектов. Прогон всех тестов в разных режимах (VS 2005/2008/2010) занимает около дня. Всё очень тяжело и медленно.
И вот имея всё это, я понимаю, что мы умрем, если займемся Linux. MSVC представляет собой монолит по сравнению с Linux. Если мы пойдем в том направлении, то цена разработки вырастет минимум в 2-4 раза. Общее в проектах будет только сам анализ, а это по трудозатратам 10% от всего остального. Зато в Linux мы будем иметь колоссальный зоопарк различных разностей. Очень хорошо про ад разработки статического анализа под многие системы написано в статье "Using Static Analysis to Find Bugs in the Real World".
Поэтому повернуться лицом к Linux мы можем только в двух случаях:
1) Мы естественным образом дорастем до Linux. У нас появится достаточный штат сотрудников, чтобы можно было заняться новым направлением.
2) У нас появится внешнее финансирование для этого.
На самом деле мы хотим поддержать большее количество платформ. Но мы имеем холодную трезвую голову и не занимаемся авантюрами. У нас есть хороший иммунитет к призывам «хочется Linux версию». Мы видели, как почти умер один проект, который пытались сделать и вашим, и нашим. Была допущена ошибка, что работа на двух платформах потребует немного дополнительных усилий и это проект можно вести без увеличения команды. Однако часто это означает, что работы станет больше в 2-3 раза. Мы не хотим повторять такую ошибку.
Конечно, не во всяком проекте, поддержка другой платформы увеличивает стоимость разработки в 2 раза. Однако, в случае статического анализатора, произойдет именно это. Основная цена развития статического анализатора, не в том чтобы добавить новое правило и написать документацию. Основные трудозатраты связаны с тем, чтобы проект адекватно себя вёл в различных режимах. Здесь часто звучит, что мы поддерживаем только MSVC. А вот у меня такое осушение, что мы и так уже тянем кроссплатформенную разработку. Мы поддерживаем разные версии компилятора. Например, учитываем, что в VS2005 static_assert это может быть имя переменной, а в VS2010 это новое ключевое слово. Еще есть поддержка разных старых проектов ARMV4 и т.д. У нас разные модули расширения под разные версии Visual Studio (не дай бог вам залезть в такие дебри и узнать почему). Постоянно появляются дополнительные заплатки, чтоб, например плагин работал в русской или немецкой MSVC. У нас очень много различных тестов на базе реальных проектов. Прогон всех тестов в разных режимах (VS 2005/2008/2010) занимает около дня. Всё очень тяжело и медленно.
И вот имея всё это, я понимаю, что мы умрем, если займемся Linux. MSVC представляет собой монолит по сравнению с Linux. Если мы пойдем в том направлении, то цена разработки вырастет минимум в 2-4 раза. Общее в проектах будет только сам анализ, а это по трудозатратам 10% от всего остального. Зато в Linux мы будем иметь колоссальный зоопарк различных разностей. Очень хорошо про ад разработки статического анализа под многие системы написано в статье "Using Static Analysis to Find Bugs in the Real World".
Поэтому повернуться лицом к Linux мы можем только в двух случаях:
1) Мы естественным образом дорастем до Linux. У нас появится достаточный штат сотрудников, чтобы можно было заняться новым направлением.
2) У нас появится внешнее финансирование для этого.
+4
А есть ли какие-нибудь коммерческие предложения по портированию PVS для других платформ?
+1
НЛО прилетело и опубликовало эту надпись здесь
Свершилось: PVS-Studio для Linux.
0
> Как именно устроен cl.exe я не знаю, но по косвенным уликам могу предположить, что имеется два совершенно разных алгоритма препроцессирования, используемых для компиляции и для создания*.i файлов.
По препроцессору Си могу сказать, что при использовании внешнего препроцессора и создании *.i файлов возможны проблемы с tokenizer. Встроенный препроцессор совмещают с tokenizer-ом и только тогда реализуют требования стандарта. Если вывод препроцессора сохранить в виде текста, повторное выделение токенов компилятором может дать иной результат.
Вот, например, у gcc «The compiler does not re-tokenize the preprocessor's output. Each preprocessing token becomes one compiler token.».
У clang встроенный препроцессор тоже выдает токены: «The preprocessor gives us a stream of tokens.»
Ваш пример с испорченным кодом — из этой серии. Комментарий после препроцессора должен был стать обычным пробельным токеном и наличие или отсутствие после него символа перевода строки не меняло бы значение последующих символов.
По препроцессору Си могу сказать, что при использовании внешнего препроцессора и создании *.i файлов возможны проблемы с tokenizer. Встроенный препроцессор совмещают с tokenizer-ом и только тогда реализуют требования стандарта. Если вывод препроцессора сохранить в виде текста, повторное выделение токенов компилятором может дать иной результат.
Вот, например, у gcc «The compiler does not re-tokenize the preprocessor's output. Each preprocessing token becomes one compiler token.».
У clang встроенный препроцессор тоже выдает токены: «The preprocessor gives us a stream of tokens.»
Ваш пример с испорченным кодом — из этой серии. Комментарий после препроцессора должен был стать обычным пробельным токеном и наличие или отсутствие после него символа перевода строки не меняло бы значение последующих символов.
+4
Давно хотел узнать как соотносится PVS-Studio и статический анализатор на основе LLVM который разрабатывается Apple для XCode. Судя по тому что они проверяют clang этим анализатором при разработке получается что PVS-Studio все же лучше.
+2
Страшно, когда в компиляторе ошибки находятся?Я тут недавно gmcs уронил совершенно невинной конструкцией с наследованием шаблона, принимающего аргументом вложенный класс. Веселее всего было искать, что именно в коде на него так могло повлиять.
+1
Собственно, в Clang анализатор нашёл только две ошибки. Из них одна на самом деле ошибкой не является. Всё остальное — ошибки LLVM, который, впрочем, тоже неплохо подходит для анализа, но ни в коем случае не является частью Clang (скорее наоборот).
Об ошибках сообщил в несколько мест, часть уже исправили, остальное перенаправили авторам участков кода.
По поводу PS: как так получается, что после препроцессирования у вас остаются комментарии? Моя версия из trunk старательно вырезает комментарии при процессировании (флаг -E) и нормально расставляет переносы. Вполне возможно, что баг уже давно исправлен.
Об ошибках сообщил в несколько мест, часть уже исправили, остальное перенаправили авторам участков кода.
По поводу PS: как так получается, что после препроцессирования у вас остаются комментарии? Моя версия из trunk старательно вырезает комментарии при процессировании (флаг -E) и нормально расставляет переносы. Вполне возможно, что баг уже давно исправлен.
0
Оффтоп. Джон Кармак на QuakeCon 2011 рассказывает о статических анализаторах, в своей речи он упоминает PVS-Studio:
http://www.youtube.com/watch?v=4zgYG-_ha28&feature=player_detailpage#t=54m00s
http://www.youtube.com/watch?v=4zgYG-_ha28&feature=player_detailpage#t=54m00s
+2
Вопорс топикстартеру: можно ли использовать пвс в автоматизированной билд системе? т.е не чтоб руками пускать и проверять каждый раз, а чтоб можно было проверять некоторое дерево автоматом из скрипта и получать некоторый с ошибками? Сильно глубоко я не копал, но внешне похоже что пвс заточен именно под ide и интерактивное использование?
0
Можно. И из командной строки запускать, и проверять только файлы за последнюю неделю, а стартовать из систем сборки. В документации (внизу) все описано. Есть конкретные вопросы — пишите нам в поддержку.
+1
Небольшое продолжение — www.viva64.com/external-pictures/txt/LLVM.txt
+1
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
PVS-Studio vs Clang