Скачай PVS-Studio и найди ошибки в С, С++,C# коде
385,50
рейтинг
1 сентября 2011 в 10:58

Разное → PVS-Studio: анализируем код операционной системы ReactOS

PVS-Studio vs ReactOS
Проверив код ReactOS, я смог исполнить сразу три своих желания. Во-первых, давно хотелось написать статью об обыкновенном проекте. Не интересно проверять код таких проектов, как Chromium. Он слишком качественен и, на поддержание этого качества тратятся ресурсы, недоступные в обыкновенных проектах. Во-вторых, появился хороший пример, на котором можно показать, как необходим статический анализ в большом проекте, особенно если он разрабатывается разнородным распределенным коллективом. В-третьих, я получил подтверждение, что PVS-Studio становится всё лучше и полезнее.

PVS-Studio становится все лучше и лучше


Начну с последнего момента, по поводу пользы инструмента PVS-Studio. ReactOS косвенно подтверждает, что PVS-Studio развивается в правильном направлении. Вот новость о проверке ReactOS с помощью такого тяжеловеса, как Coverity — «Статический анализ в Coverity» [1]. Я, конечно, знаю и понимаю, что до возможностей Coverity нам далеко. Но, тем не менее, там, где благодаря Coverity «было найдено несколько новых ошибок», PVS-Studio находит их целый вагон и маленькую тележку. При этом никакой код никуда отправлять не надо. Можно просто взять и проверить проект. Значит мы на верном пути.

Что такое ReactOS?


ReactOS — это современная, свободная и открытая операционная система, основанная на архитектуре Windows XP/2003. Система была написана с нуля и имеет своей целью повторение архитектуры Windows-NT, созданной Microsoft, от аппаратного до прикладного уровня. Объем исходного кода на языке Си, Си++ и ассемблере составляет порядка 220 мегабайт.

Различные ссылки:

Ошибки в ReactOS


Теперь поговорим о вагоне ошибок, которые повстречались мне в коде ReactOS. Конечно, все они в статью не войдут. Здесь я выложил текстовый файл с описанием ошибок, которые я заметил в ходе анализа. Файл содержит диагностические сообщения с именами файлов и номерами строк. Также я выделил ошибки в короткий код и дал некоторые комментарии. Поэтому тем, кто захочет сделать правки в ReactOS, лучше руководствоваться этим файлом, а не статьёй.

А еще лучше скачать и самим проверить проект с помощью PVS-Studio. Ведь я не знаком с проектом и выписывал только те ошибки, которые мне понятны. По поводу многих фрагментов кода я не знаю, содержат они ошибки или нет. Так что мой анализ достаточно поверхностен. Ключ для проверки выделим.

Ошибки, которые можно встретить в ReactOS разнообразнейшие. Просто зоопарк. Есть опечатки из одного символа.
BOOL WINAPI GetMenuItemInfoA(...)
{
  ...
  mii->cch = mii->cch;
  ...
}

На самом деле должно быть написано вот так: «mii->cch = miiW->cch;». Потеряли букву 'W'. Как результат, программы уже не могут доверять функции GetMenuItemInfoA.

А вот другая опечатка в один символ. В этот раз некорректно работает сравнение двух имён.
static void _Stl_loc_combine_names(_Locale_impl* L,
  const char* name1, const char* name2,
  locale::category c)
{
  if ((c & locale::all) == 0 || strcmp(name1, name1) == 0)
  ...
}

Есть путаница между оператором && и &. Очень распространенная ошибка. Встречаю практически в каждом проекте, где работают с битами или атрибутами файлов.
static LRESULT APIENTRY ACEditSubclassProc()
{
  ...
  if ((This->options && ACO_AUTOSUGGEST) &&
      ((HWND)wParam != This->hwndListBox))
  ...
}

Корректный код должен выглядеть так "(This->options & ACO_AUTOSUGGEST)". Пример ниже содержит родственную ей ошибку, из-за которой всё условие всегда ложно.
void adns__querysend_tcp(adns_query qu, struct timeval now) {
  ...
    if (!(errno == EAGAIN || EWOULDBLOCK || errno == EINTR ||
        errno == ENOSPC || errno == ENOBUFS || errno == ENOMEM)) {
  ...
}

Если присмотреться, то можно заметить коварный фрагмент: "|| EWOULDBLOCK ||".

Кстати, в ReactOS нашлось достаточно много условий, которые всегда истинны или ложны. Некоторые нестрашные, так как, например, располагаются в макросе assert(). Но есть, на мой взгляд, и критичные.
INT WSAAPI
connect(IN SOCKET s,
        IN CONST struct sockaddr *name,
        IN INT namelen)
{
  ...
  /* Check if error code was due to the host not being found */
  if ((Status == SOCKET_ERROR) &&
      (ErrorCode == WSAEHOSTUNREACH) &&
      (ErrorCode == WSAENETUNREACH))
  {
  ...
}

Согласитесь, что реализация таких функций как «connect» должна быть протестирована максимально полно. А здесь мы имеем условие, которое всегда ложно. Быстро заметить дефект не так просто, поэтому выделю суть ошибки:
(ErrorCode == 10065) && (ErrorCode == 10051)

Кстати, часть, связанная с сокетами, вообще выглядит сырой. Возможно, это связано с тем, что в Linux мире SOCKET принято объявлять как знаковый тип. А в Windows он беззнаковый:
typedef UINT_PTR SOCKET;

Как результат имеем разнообразные ошибки в операциях сравнения:
void adns_finish(adns_state ads) {
  ...
  if (ads->tcpsocket >= 0) adns_socket_close(ads->tcpsocket);
  ...
}

Выражение «ads->tcpsocket >= 0» не имеет смысла, так как всегда истинно.

Встречаются просто странные фрагменты. Скорее всего, это недописанные и забытые участки кода.
if (ERROR_SUCCESS == hres)
{
  Names[count] = HeapAlloc(GetProcessHeap(), 0, strlenW(szValue) + 1);
  if (Names[count])
     strcmpW(Names[count], szValue);
}

Зачем вызывать «strcmpW», если результат никак не используется?

Имеются ошибки, связанные с приоритетом операций.
VOID NTAPI
AtapiDmaInit(...)
{
  ...
  ULONG treg = 0x54 + (dev < 3) ? (dev << 1) : 7;
  ...
}

Я расставлю скобки, чтобы стало ясно, как работает это выражение на самом деле:
ULONG treg = (0x54 + (dev < 3)) ? (dev << 1) : 7;

Следующая ошибка обязательно встречается в любом большом проекте. Есть парочка и в ReactOS. Речь идет о лишней точке с запятой — ';'.
BOOLEAN
CTEScheduleEvent(PCTE_DELAYED_EVENT Event,
                 PVOID Context)
{
  ...
  if (!Event->Queued);
  {
    Event->Queued = TRUE;
    Event->Context = Context;
    ExQueueWorkItem(&Event->WorkItem, CriticalWorkQueue);
  }
  ...
}

Ещё мне нравятся ошибки с инициализацией элементов массива. Не знаю почему. Они трогательны. Возможно, я вспоминаю свои первые эксперименты с массивами на языке Basic.
HPALETTE CardWindow::CreateCardPalette()
{
  ...
  //include button text colours
  cols[0] = RGB(0, 0, 0);
  cols[1] = RGB(255, 255, 255);

  //include the base background colour
  cols[1] = crBackgnd;

  //include the standard button colours...
  cols[3] = CardButton::GetHighlight(crBackgnd);
  cols[4] = CardButton::GetShadow(crBackgnd);
  ...
}

Можно продолжать приводить разные интересные участки кода. К сожалению, тогда статья станет слишком длинной и нужно останавливаться. Напомню, что посмотреть на другие ошибки, найденные мной в ReactOS, можно вот в этом файле. На сладкое только приведу вот этот кусочек кода:
#define SWAP(a,b,c)  c = a;\
                      a = b;\
                      a = c

Пример использования:
BOOL FASTCALL
IntEngGradientFillTriangle(...)
{
  ...
  SWAP(v2,v3,t);
  ...
}

Это – шедевр.

Статический анализ кода


Я считаю ReactOS очень хорошим примером проекта, где регулярный статический анализ кода просто необходим. И дело здесь не в квалификации разработчиков. Проект большой и содержит разнообразные подсистемы. Это значит, что над таким проектом всегда трудится большое количество людей. А в большом коллективе всегда кто-то программирует хуже, кто-то лучше. Кто-то использует один стиль, кто-то другой. Но никто не застрахован от ошибок. Вот смотрите.

Один человек взял и написал в ReactOS вот так:
if ((res = setsockopt(....) == -1))

Код делает не то, что хочется. Корректный вариант: if ((res = setsockopt(....)) == -1). Если придерживаться практики писать константу в начале, то случайно никогда не сделаешь ошибочное присваивание внутри оператора «if». У нас здесь другой тип ошибки. Но если писать код по приведенному правилу, то не получится сделать ошибку и в рассматриваемом выражении: «if (-1 == res = setsockopt(....))».

Вот только знание этой практики не мешает другому человеку ошибиться альтернативным способом.
static DWORD CALLBACK
RegistrationProc(LPVOID Parameter)
{
  ...
  if (0 == LoadStringW(hDllInstance, IDS_UNKNOWN_ERROR,
                        UnknownError,
                        sizeof(UnknownError) /
                        sizeof(UnknownError[0] - 20)))
  ...
}

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

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

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

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

Поясню своё утверждение. В подобных системах невозможно приблизиться к 100% покрытию кода при тестировании с помощью юнит-тестов или регрессионных тестов. Немного уточню. Можно конечно, но затраты на создание и поддержание таких тестов становятся недопустимо высоки.

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

Пример проверки кода, редко получающего управление:
static HRESULT STDMETHODCALLTYPE
CBindStatusCallback_OnProgress(...)
{
  ...
  if (This->szMimeType[0] != _T('\0'))
    _tprintf(_T("Length: %I64u [%s]\n"), This->Size, 
             This->szMimeType);
  else
    _tprintf(_T("Length: %ull\n"), This->Size);
  ...
}

Скорее всего, изначально код был написан неправильно. Потом кто-то заметил, что сообщение формируется неправильно и внес исправление, написав "%I64u". А вот на код по соседству он не обратил внимание. И там по-прежнему имеется некорректный формат "%ull". Видимо ветка вызывается крайне редко. Статический анализ такое не пропустит. Собственно он и не пропустил, раз я могу продемонстрировать этот пример.

Другим хорошим примером может служить большое количество ошибок очистки памяти, которые я увидел ReactOS. Почему их так много, мне понятно. Никто не тестирует, заполнилась память или нет. Во-первых, сложно осознать, что в этих простых местах можно ошибиться. А во-вторых, не так просто проверить очистился внутри функции какой-то временный буфер или нет. Здесь статический анализ вновь на высоте. Приведу только пару примеров. На самом деле я насчитал как минимум 13 ошибок заполнения массивов константным значением.
#define MEMSET_BZERO(p,l) memset((p), 0, (l))

char *SHA384_End(SHA384_CTX* context, char buffer[]) {
  ...
  MEMSET_BZERO(context, sizeof(context));
  ...
}

Очищаем только первые байты массива, так как sizeof(context) возвращает размер указателя, а не структуры.
#define RtlFillMemory(Destination, Length, Fill) \
  memset(Destination, Fill, Length)

#define IOPM_FULL_SIZE          8196

HalpRestoreIopm(VOID)
{
  ...
  RtlFillMemory(HalpSavedIoMap, 0xFF, IOPM_FULL_SIZE);
  ...
}

Перепутаны аргументы при использовании макроса RtlFillMemory. Вызов должен быть таким:
RtlFillMemory(HalpSavedIoMap, IOPM_FULL_SIZE, 0xFF);

Снова о табуляциях и пробелах


Заранее хочу попросить не начинать в комментариях новую бурную дискуссию на эту тему. Я просто выскажу своё мнение. С ним можно быть согласным или нет. Но обсуждать не стоит.

Есть два непримиримых лагеря. Одни за использование табуляции в коде, так как это позволяет подстраивать отображение кода под себя [2]. Другие говорят, что это всё равно не работает и, что нет разумных причин использовать символы табуляции. От табуляции только вред и разъезжающееся форматирование. К их числу отношусь и я [3].

Можно сколько угодно говорить о том, что табуляции надо использовать правильно и тогда всё будет хорошо. К сожалению, это говорят те, кто работает замкнуто над одним проектом и не сталкиваются с внешним миром. В любом открытом или просто большом проекте, не удаётся достичь нормального оформления кода, если разрешить использовать табуляцию в любом виде.

Я не буду заниматься абстрактными рассуждениями. В этот раз я просто приведу своим оппонентам наглядный пример. Сейчас таким примером станет код ReactOS.

В стандарте кодирования ReactOS [4] написано хорошее правило с теоретической точки зрения:
Generic note about TABs usage: Don't use TABs for formatting; use TABs for indenting only and use only spaces for formatting.
Example: 
NTSTATUS
SomeApi(IN Type Param1,
[spaces]IN Type Param2)
{
[TAB]ULONG MyVar;
[TAB]MyVar = 0;
[TAB]if ((MyVar == 3) &&
[TAB][sp](Param1 == TRUE))
[TAB]{
[TAB][TAB]CallSomeFunc();
...

Поклонники табуляции довольны. Однако я открываю исходные коды ReactOS и наблюдаю во многих местах испорченное форматирование. Почему?
Tabs vs Spaces 1

Tabs vs Spaces 2

Tabs vs Spaces 3
Ответ конечно очевиден. Потому, что это сложно помнить, где надо нажать TAB, а где поставить несколько пробелов, если это не единственный проект, с которым работаешь. Вот люди постоянно и ошибаются. А раз так, нечего быть теоретиками, а надо быть практиками. Надо взять и запретить использовать табуляцию вообще. И тогда всё у всех будет одинаково, а виновника, кто начинает использовать табуляцию, легко найти и сделать ему внушение.

Это не шаг назад в оформлении кода! Это шаг вперёд! Это следующий уровень осознания. Теоретическая красота настраиваемых отступов не сочетается с практикой. В первую очередь важно обеспечить однозначное представление кода и легкость разработки в большой команде. В компании Google это понимают. И в их стандарте для форматирования используются только пробелы [5]. Тем, кто ратует за использование табуляции, еще раз рекомендую задумываться, почему распределенная команда высококлассных профессионалов, которые разрабатывают Chromium, выбрала именно пробелы.

И еще раз. Теоретическая красота настраиваемых отступов не сочетается с практикой. Неважно, как красиво звучит теория, если она не работает. А именно так и обстоит дело в ReactOS.

Рекомендую команде разрабатывающей ReactOS модифицировать их стандарт и отказаться от использования табуляции. Любая табуляция должна расцениваться, как ошибка и быть устранена из кода.

Кстати, подобная практика позволит находить вот такие вот безобразия в коде ReactOS:
BOOLEAN
KdInitSystem(IN ULONG BootPhase,
             IN PLOADER_PARAMETER_BLOCK LoaderBlock)
{
  ...
  /* Check if this is a comma, a space or a tab */
  if ((*DebugOptionEnd == ',') ||
      (*DebugOptionEnd == ' ') ||
      (*DebugOptionEnd == ' '))
  ...
}

Последнее сравнение, это сравнение с символом табуляции, а не с пробелом, как может показаться. Нормальный код должен выглядеть так: "(*DebugOptionEnd == '\t')".

Примечание для сторонников табуляции. Не надо мне вновь рассказывать, как правильно использовать табуляции. И это не мой код. Смотрите, вот есть вполне конкретный проект ReactOS. В нем есть плохо отформатированный код. Подумайте, какие действия позволят сделать так, чтобы новый программист мог открыть код проекта и не гадать, какой размер символа табуляции ему необходимо установить в настройках редактора. Мысли в духе «нужно сразу было писать правильно» практической ценности не имеют.

Библиографический список


  1. Выпуск новостей ReactOS N79. Статический анализ в Coverity. http://www.viva64.com/go.php?url=722
  2. Пора завязывать использовать пробелы вместо табуляции в коде. http://www.viva64.com/go.php?url=725
  3. Пора завязывать использовать символы табуляции в коде. http://www.viva64.com/go.php?url=726
  4. ReactOS. Coding Style. http://www.viva64.com/go.php?url=724
  5. Google C++ Style Guide. http://www.viva64.com/go.php?url=679
Автор: @Andrey2008
PVS-Studio
рейтинг 385,50
Скачай PVS-Studio и найди ошибки в С, С++,C# коде

Комментарии (121)

  • +13
    По поводу табов — разумно.
    Пожалуй что убедили (к тому же, это согласуется с моей практикой). Буду использовать пробелы.
    • +15
      Главное — это единообразие в проекте.
      А в чем именно единообразие — уже не так важно.

      А за невидимую табуляцию в строковых константах нужно бить… по рукам :-)
      • +6
        ага, топором… =)
      • –1
        >Главное — это единообразие в проекте.

        и не в одном, а желательно во всех, с которыми работаешь.
        • +7
          Я сейчас работаю в двух не связанных проектах — в одном приняты за стандарт табы, в другом пробелы. И. надо сказать, в обоих проектах все идет замечательно, и никаких неудобств люди не испытывают.
    • +2
      Часть проблем с табами в ReactOS идут из вайна. Там в coding style нет единого правила на эту тему и вообще сказано — оформляйте так, как код оформлен рядом. Поэтому запросто в одном файле могут исторически смешаться разные стили. И в плане табуляции и оформления кода там местами тихий ужас.
  • +38
    Ой не надо опять про табы… больная же тема, сейчас другой лагерь придет и будет столь же правильные вещи задвигать!
    • +10
      Испортили весь топик этим холиваром.
  • 0
    Если разработчик не знает, не хочет, или забывает обрашать внимание на корректную расстановку табов/пробелов, он с таким же успехом будет игнорировать и другие стилевые правила. Так что это вообще не аргумент. А ещё по табам удобнее перемещаться курсором. Курсор всегда шагает на уровень отступа (впрочем, в некоторых IDE есть имитация такого поведения для пробелов).
    • +3
      Мне в NetBeans нравится ставить пробелы табом :)
  • +9
    А мне пофик табы или пробелы: какой стандарт принят в данном конкретном проекте или в данной команде — такой и использую. Тоже мне — нашли проблему. Главное — чтобы было едино, либо табы либо пробелы.
  • +45
    Народ!!! Топик не о табах, еси чё.
    • +5
      Автор жостко потроллил.
      • +1
        Да ладно — «протроллир». Я слов то таких не знаю. Причем здесь это? Я открыл очередной проект — ReactOS. В нем местами каша из кода. Что толку учить людей ставить табы (в стандарте ReactOS всё правильно написано), если научить не получается. Надо просто табы запретить и жестко бить, кто начинает создавать ими кашу. И я высказал это своё мнение. В дискуссию вдаваться не хочу. Если согласны — хорошо. Если нет — поставьте минус. А обсуждать тут нечего.
        • +13
          Нет, вы снова подняли бессмысленный холивар, который уже поднимали и увели тему топика в левое русло. Вот вы говорите:
          Потому, что это сложно помнить, где надо нажать TAB, а где поставить несколько пробелов

          А что нужно писать английским, а не транслитом — не сложно помнить?
          Что нужно писать camelCase'ом (under_score'ом), если в проекте такой стиль — не сложно помнить?
          Что нужно объявлять переменные — не сложно помнить?
          Может сложно помнить, что ключевое слово int означает целое число в определённых рамках?
          Почему всё это не сложно помнить, а вдруг разницу, когда надо использовать табы, а когда — пробелы — сложно. Пробелы — это костыль, который неудобен большинству разработчиков, что мы уже доказали предыдущими топиками.

          Вы просто решили взять матч-реванш.
          И да, я запросто покажу вам огромное количество проектов, где табы не используются, а используются пробелы и при этом едет выравнивание.
          • +3
            И да, я запросто покажу вам огромное количество проектов, где табы не используются, а используются пробелы и при этом едет выравнивание.

            Покажите хоть один.
            • 0
              Как вы думаете, что будет когда у разных разработчиков разное число символов в отступе?
              • +3
                что будет, что будет… тот у кого оно будет более разное — заболеет гематомами
              • –1
                Для всякого проекта есть стандарт кодирования. Например: 8 пробелов в табе для ядра Linux.
                Если нет для проекта — есть для языка. Например: 2 пробела в табе для ruby.
                Если разработчик не следует стандартам — бить по рукам.
                • +1
                  >8 пробелов в табе

                  эээ? в ядре линукса как раз настоящие табы без всяких пробелов.
                  • +2
                    Documentation/CodingStyle:
                    Tabs are 8 characters, and thus indentations are also 8 characters.
                    There are heretic movements that try to make indentations 4 (or even 2!)
                    characters deep, and that is akin to trying to define the value of PI to
                    be 3.

                    Rationale: The whole idea behind indentation is to clearly define where
                    a block of control starts and ends. Especially when you've been looking
                    at your screen for 20 straight hours, you'll find it a lot easier to see
                    how the indentation works if you have large indentations.

                    Now, some people will claim that having 8-character indentations makes
                    the code move too far to the right, and makes it hard to read on a
                    80-character terminal screen. The answer to that is that if you need
                    more than 3 levels of indentation, you're screwed anyway, and should fix
                    your program.

                    In short, 8-char indents make things easier to read, and have the added
                    benefit of warning you when you're nesting your functions too deep.
                    Heed that warning.

                    Важно, что для проекта есть специфический стандарт кодирования. Здесь — 8 символов для отступа. Будь это табы или пробелы — это будет выглядеть одинаково. Но если это будут табы, то нужна modeline или другой способ указать, что в табе должно быть именно 8 пробелов. А если это будут пробелы, то такой проблемы не будет.
                    Это к фразе «что будет когда у разных разработчиков разное число символов в отступе».
                    • –4
                      Вообще-то без разницы сколько пробелов в табе, хоть 10, хоть 2, они одинаково отображаются у всех
                      • 0
                        Топик читал, с ним совершенно несогласен, но это вопроса не касается. Был задан вопрос «а если у разных разработчиков разное число символов в отступе?» Был дан ответ «нужно следовать стандартам». Всё.
              • 0
                Во-во. Я уж не знаю, какие редкие эстеты авторы vanilla, но они там используют 3 пробела, я это вообще не перевариваю :)
          • –1
            ну вот лично я регулярно забываю пнуть vim на использование правильного форматирования, когда работаю с исходниками ядра.

            везде пробелы (еще и разное количество, блин), а у Линуса табы.

            а потом еще мне говорят свое фе, когда этот код кто-то в апстрим шлет и вынужден фиксить за меня.
            • 0
              modeline всем поможет. Опять же — родная для vim технология :).
              • 0
                спасибо, что рассказали, как эта фиговина называется — много раз видел такие метки в файлах, не знал, где прочитать про них.

                однко я вам скажу, что писать инструменто-специфичные данные в общую кодовую базу — это свинство. мне бы захотелось что-то нехорошее сделать с людьми, которые коммитят всякий шлак, типа *.proj в ту же кодовую базу.

                в своих проектах я может так и делал бы, но в линуксе меня за такое справедливо и больно стукнут кадилом по патч-сабмишшеную
                • 0
                  modeline не более специфическая чем shebang :). На вскидку ее поддерживают: vim, emacs, eclipse и даже notepad++ и visual studio с сответствующим аддином. Modeline уже достаточно давно не vim-specific.
                  • 0
                    тем не менее, в том проекте о котором я говорю (linux kernel) модлайны в файлах запрещены:

                    Documentation/CodingStyle:

                    Some editors can interpret configuration information embedded in source files,
                    indicated with special markers.

                    Do not include any of these in source files. People have their own personal
                    editor configurations, and your source files should not override them. This
                    includes markers for indentation and mode configuration. People may use their
                    own custom mode, or may have some other magic method for making indentation
                    work correctly.
                    • +1
                      Что я тут могу сказать — сами себе злобные ежики. Текст rationale не имеет смысла, так как все редаторы с поддержкой modeline поддерживают ее достаточно гибко и все эти «custom mode» и «magic method» замечательно работают при имеющейся modeline. Возможно, это правило устарело лет так на десять кода modeline был только в vim и жестко менял поведение редактора :).
                      • 0
                        этому документу лет 20 и есть.
                      • 0
                        Ну, например, маленькая проблема в том, что у emacs — своя modeline, а у vim — своя, ничего?
                        • 0
                          чтобы emacs понимал vim-овский достаточно одной строки в конфигурации.
                          • 0
                            Просветите, пожалуйста, какой? Я знаю только некий скрипт-враппер, который вешается на открытие файла и конвертирует modeline регэкспами; разумеется, более-менее сложный modeline от этого ломается.
                            • –2
                              Увы, конфиг где я это делал за давностью лет того -_-. Более-менне сложный не нужен, достаточно регекспом вытаскивать indent и expandtabs :)
                              • 0
                                Для такого стандарта, как, например, предполагается в ReactOS — как раз нужна достаточно сложная настройка…
        • 0
          > Что толку учить людей ставить табы
          а что толку учить физику? А что толку учить математику? Всегда можно найти человека, который их не осилил и на его примере доказывать, что учить их бесполезно. Слабый аргумент.
    • +11
      Теперь это топик о табах!
  • +13
    PVS-Studio для ReactOS на льготных условиях или бесплатно — вклад в технологический прогресс человечества!
    • +5
      Так есть же лицензия бесплатная для опен сорса.
      • +1
        Она не то, чтобы бесплатная — там больше на триал похоже по условиям.
        • +8
          Если кому-то понравилось и от него есть обратная связь, то мы продлеваем ключи. Например, разработчики FlylinkDC++ уже более полугода бесплатно пользуются. И им польза. И нам. Они нам присылают баг-репорты и интересные пожелания по диагностическим правилам.
          • +1
            Кстати, не сочтите за попытку попридираться — но кроме FlylinkDC++ кто-то до сих пор воспользовался вашим предложением? Если да — вероятно, где-то есть где-то список open source проектов-получателей — можно на него взглянуть? На сайте PVS как-то сходу не нашел.
            • 0
              Я знаю, что, как минимум, PVS-Studio пользовался Кармак, а это очень показательно, имхо.
              • 0
                Это здорово, я уверен, что у PVS-Studio есть туча коммерческих заказчиков (тем более, что ценовая политика действительно достаточно либеральная), но я про их open source программу спрашивал :)
                • 0
                  Такие люди и коллективы конечно же есть, но поскольку добиться от них внятного фидбека, который можно опубликовать в виде статьи сложно, то и сослаться особо не на что.

                  Все-таки одно дело на Хабре прокричать «фу, коммерческое, вот если бы было бесплатное, то я бы горы свернул!» и другое — потом статью выдать. Это, конечно же, не какая-то конкретная личная претензия.
                  • +1
                    У меня закрадывается стойкое подозрение, что целевой аудитории FOSS-разработчиков тут как бы нет. Коллективы, которые их пишут именно на C/C++ под Windows, конечно, бывают, но их страшно мало в общей массе — я вот сейчас подумал и из сколько-нибудь широко известных из головы вспомнил всего 3 — TortoiseSVN, Miranda и eMule.

                    Если бы PVS-Studio хотя бы как-то работал с gcc и под не-Windows — возможно, получилось бы охватить и всяких ядерных разработчиков, и серверный userland, и разработчиков gtk/gtk+ приложений, и Qt/KDE разработчиков на C++ — а так — я практически не вижу, кто мог бы воспользоваться предложением…
                    • +1
                      Не то чтобы я спорю, но просто на всякий случай напомню, что мы маленькая софтовая компания. Продажа софта — наш единственный бизнес. И цели «чтобы линукс-пользователи могли бесплатно пользоваться нашим продуктом» у нас нет.
                      • +3
                        Если я правильно понимаю, ваша основная цель — пытаться продавать продукт, а для этого нужна какая-то огласка и чтобы о нем знали. Конкуренция на этом рынке достаточно приличная, если верить списку в википедии — инструментов статического анализа C/C++ порядка 10-15 штук бесплатных/свободных и порядка 50 — коммерческих/проприетарных.

                        Де факто я сейчас не вижу, чтобы о вас говорили на каждом углу, где говорят о статическом анализе C/C++. Говорят в первую очередь о Сoverity, о CppCheck, о CppDepend, о VSTT Prefast. Реже — об Klocwork'овском Insight, Goanna, PC-Lint и еще десятке инструментов. Несмотря на существенный успех с iD software — PVS-Studio все-таки упоминается довольно редко.

                        Вы сами предложили весьма эффективную на первый взгляд стратегию — предлагать бесплатную триал-версию всяким FOSS-проектам и за счет этого получить PR, известность и огласку. На второй же взгляд, оказывается, что проектов, которые бы могли воспользоваться продуктом и дать вам этот самый PR — как-то толком и нет. Возможно, стоит что-то пересмотреть — если уж пытаться пользоваться таким PR-ресурсом?
  • –11
    Очень веселая реклама, особенно учитывая, что ReactOS некоммерческий проект и вы считаете, что выложить 3.5 штуки евро на одного разработчика это нормально?
    • +4
      >А еще лучше скачать и самим проверить проект с помощью PVS-Studio.…
      > Ключ для проверки выделим.
    • +19
      1) За 3500 евро вы имеете право использовать продукт в команде до 5 пользователей, при инсталляции только на одну машину каждого пользователя. В том числе вы имеете право установить одну инсталляцию на сервер. И не стоит забывать, что команда получает оперативную поддержку на русском и английском языке в течении года. Очень даже дёшево.

      2) Не надо особенно кричать про энтузиазм. Проекты уровня ReactOS делаются тогда, когда это кому-то нужно. А то что это происходит в формате Open Source — значит так просто удобнее и дешевле.

      3) Мы предоставляем открытым бесплатным проектам ключи на некоторое время. И я сказал в статье, что выдадим и для команды ReactOS. Не надо делать из нас жадных злодеев.
    • +2
      В соседнем топике уже реквестировали миллион евро на форк reactOS, как вы думаете зачем?
      • +1
        всем 200м разработчикам по PVS!!!
  • +8
    Статья про анализ кода ReactOS, а все опять про табы с пробелами.
    Хватит об этом уже.
  • +9
    if (ERROR_SUCCESS == hres)
    {
      Names[count] = HeapAlloc(GetProcessHeap(), 0, strlenW(szValue) + 1);
      if (Names[count])
         strcmpW(Names[count], szValue);
    }


    Зачем вызывать «strcmpW», если результат никак не используется?


    Я подозреваю, что тут код вполне осмыслен, просто вместо strcmpW должно быть strcpyW
    • +4
      Вы случаем не:

      Роэль Мессан (Roel Messiant) недавно присоединился к проекту и исправил несколько ошибок, обнаруженных Coverity. На IRC-канале Роэль известен под именем Mephisto, и, несмотря на ник, оказался значительно более полезным, чем его тёзка по нику (Мефистофель), а мы с нетерпением ждём, что ещё нового он принесёт в проект. (с) с Сайта РеактОС.
      • +2
        нет :D
  • +1
    Подумайте, какие действия позволят сделать так, чтобы новый программист мог открыть код проекта и не гадать, какой размер символа табуляции ему необходимо установить в настройках редактора.


    Оффтопик: строго говоря, для этого есть modeline. Но в целом аргументы за пробелы мне понравились, с такого ракурса я еще не рассматривал.

    Видимо, пора показывать эту статью руководству и намекать что неплохо бы прикупить анализатор. Хорошая, годная реклама :).
  • +16
    >Считаю, что статический анализ кода должен являться обязательным элементом цикла разработки ReactOS и других крупных проектов.

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

    Вы крутые чуваки, мне нравятся ваши посты, как по сути, так и по стили изложения, очень жаль, что не могу пользоваться вашим инструментом.
    • +2
      Насколько я знаю, интеграция в IDE у них опциональная, недавно появилась. И основной способ запуска как раз из командной строки.

      А что до платформы… Их много сейчас. Вон у меня справа свиноферма стоит — там и mac (потому что по лицензионному соглашению macos нельзя запускать на неродном железе даже в виртуалке), и несколько ubuntu, и windows 7. Кучка виртуалок. И все замечательно работает вместе, автобилд под разные платформы делает. Ограничиваться одной платформой потому что остальные «не православные» — это сейчас череповато рыночной долей :).
      • +1
        >Ограничиваться одной платформой потому что остальные «не православные» — это сейчас череповато рыночной долей :).

        а чего вы это мне рассказываете?
        • +1
          работающий только под одной ОС и завязанный на определенную IDE никогда не станет обязательным элементом цикла разработки большинства крупных проектов


          Тайна сия великая есть и разгадка ее в глубине веков :) Может быть, мне интересна позиция человека, который столь критично относится к софту, работающему только под одну ОС?
          • 0
            я вас не понимаю. вы сами пишете, что ограничиваться одной платформой — «череповато».

            >Может быть, мне интересна позиция человека, который столь критично относится к софту, работающему только под одну ОС?

            потомучто ОС у всех разные, как и рабочий процесс.

            одна ОС — это еще ладно, особенно если под ОС понимать *unix.

            а вот некоторые панове, не буду тыкать пальцем в стороны прибальтики, так вообще чего придумали — бинарники исключительно под i686 штампуют. хоть в qemu их запускай, право слово.
            • 0
              Есть виртуальные машины. Ставим ее на любимую nix, туда ставим Windows 7, благо она не очень дорогая в простых редакциях, а под нее уже можно и PVS-Studio. И все довольны.

              У меня даже на virtualbox все замечательно работает :). Как на nix так и на macos в качестве «основной» операционки.
              • +2
                >Есть виртуальные машины. Ставим ее на любимую nix, туда ставим Windows 7.

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

                а на собственной машине это попросту неудобно, а в моем случае вообще невозможно. это я еще опускаю такие подробности, как работа с кодом с другой машины по ssh.
                • 0
                  Вы сами себе противоречите

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


                  и

                  а на собственной машине это попросту неудобно, а в моем случае вообще невозможно. это я еще опускаю такие подробности, как работа с кодом с другой машины по ssh.
                  • 0
                    >Вы сами себе противоречите

                    не понял, где противоречие?
                  • 0
                    в чем противоречие то?

                    я тоже бльшую часть времени веду вазработку через ssh… и я бы тоже хотел пройтись по сырцам pvs-studio, но пока никак не выходит…
                    • 0
                      Вы говорите про крупный проект и тут же говорите собственную машину, этим вы подтверждаете что работаете далеко не на крупном проекте или пытаетесь применить средство только со своей стороны не имея прямого доступа ко всем сырцам.

                      Согласуйте со всей командой разработчиков, выделите машину и запускайте там PVS, хоть через SSH или telnet его дергайте — инструментов полно.
                      • 0
                        Простите, ответ был для muromec
  • +2
    Хочу PVS-Studio в виде самостоятельного инструмента. Ну или хотя бы в виде плагина к NetBeans и Eclipse. А также версию для linux, но это уже из области фантастики. В любом случае, желаю проекту дальнейшего развития.
    • 0
      Да это студия видно хороша, раз такие ошибки ищет, но в моей работе неприменима: VS + Win
    • –1
      Нужно признать, что авторы PVS-Studio — реалисты. Те, кто пользуется NetBeans, Eclipse и Linux никогда не заплатят за такой инструмент. Идеология не позволит. А среди пользователей визуал студии — много больших фирм с деньгами и пониманием того факта, что за хороший рабочий инструмент можно и заплатить.
      • 0
        не правда про не заплатят, и про идеологию тоже не правда…
        • –1
          Да, это наглая клевета. Хотя и правда.
          • 0
            Eclipse активно используется в больших interprise-J2EE проектах, в компаниях, которые могут позволить себе такой инструмент, но pvs сейчас не для java, насколько я знаю.
      • +1
        Фиг с ним, с линуксом, но неужели вы думаете, что большие фирмы другими IDE не пользуются? Если бы они сделали свой анализатор как отдельный инструмент, он бы устроил и тех и других, по крайней мере им бы могли пользоваться все, а не только визуальщики. Ну а потом можно было выпустить плагины для интеграции анализатора с популярными IDE. Реалисты — не реалисты, но зачем такие жёсткие зависимости?
        • –1
          >неужели вы думаете, что большие фирмы другими IDE не пользуются?

          Под Виндой, для написания коммерческого С++ кода — да, думаю не пользуются. (Ну оставьте 5% на статистическую погрешность).
          • 0
            >Под Виндой, для написания коммерческого С++ кода — да, думаю не пользуются.

            Вы думаете неправильно. Вылезайте уже из своего уютного десктопного мирка — помимо него есть громадное количество областей, где C++ рулит и педалит, причём это далеко не всегда C++.Net.

            >Ну оставьте 5% на статистическую погрешность

            Хренасе у вас «погрешности» о_О
            Вы хотя бы представляете, сколько составляют эти 5% в абсолютных числах и сколько денег там зарыто?

            Даю один простой пример: для того, чтобы писать под QNX, используется их собственная QNX Momentics IDE, основанная на Eclipse. Да, компаний, пишущих под QNX, очень мало, но сама область такова, что во-первых ею занимаются действительно серьёзные компании (что обусловлено самой нишей QNX), а во-вторых у них чрезвычайно высокие требования к качеству кода. Думаю, дальше объяснять не нужно?
            • +2
              >ею занимаются действительно серьёзные компании (что обусловлено самой нишей QNX), а во-вторых у них чрезвычайно высокие требования к качеству кода. Думаю, дальше объяснять не нужно?

      • +2
        Те, кто пользуется NetBeans, Eclipse и Linux никогда не заплатят за такой инструмент

        Я сижу на Линуксе и пользуюсь купленной phpStorm. Так что это только ваши ошибочные домыслы.
        • +1
          Давайте возьмем 100 произвольных компьютеров\серверов с Линуксом. На скольких, по Вашей оценке, стоит хоть какое-то купленное ПО?

          А теперь возьмем 100 компьютеров с Виндой. Даже в наших диких пиратских краях благодаря программам продажи ОС с железом, всяким гос.тендерам и наездам на частные фирмы процент лицензионного (купленного) ПО весьма существенен.

          Я ничего плохого не хочу сказать о пользователях Linux и opensource-программ — это вполне себе выбор и хорошее, благородное мировозрение. Но заработать на таких людях в среднем можно существенно меньше, чем на «виндузятниках».
        • +2
          Вы вот сказали, что у Вас стоит на компе phpStorm — прекрасно. А у меня на рабочем компе стоит около 20 разных купленных организацией, где я работаю, программ. Плюс на домашнем компе около десятка честно купленных (и не буду говорить сколько не честно). Ну вот и под какую платформу и для какой аудитории выгоднее делать инструменты, аналогичные PVS Studio?
          • 0
            Ну вот и под какую платформу и для какой аудитории выгоднее делать инструменты, аналогичные PVS Studio?

            JetBrains правильно делают. У них отличный инструмент, который работает и покупается под любой платформой. И если бы он не работал под Линуксом, то и под виндой тоже меньше покупался бы.
    • 0
      На тему PVS-Studio Standalone и Linux, возможно будет интересна вот эта новая заметка — "PVS-Studio теперь работает и без среды Visual Studio или C++Builder – проверяем препроцессированные файлы от чего угодно".
  • –12
    Тю, оно проприентарное. Не интересно. Будет опенсорс, приходите.
    • +1
      оценсорц есть под более другие языки. те же pep8 и pyflakes, например.
      • +3
        Тю, хабрахабр проприетарный. Не интересно. Будут выложены все потроха, приходите. /irony
        • +1
          Хабрахабр, кстати, с точки зрения контента — CC-BY в очень многих местах.
          • +3
            CC-BY в постах и проприетарщина в разуме.
            • +1
              Уверены? Приобретали движок хабра и исходники вам не дали? :)
    • +2
      Тю, да это ж красноглазик амарао. Не интересно. Будет некрасноглазик, приходите.
  • –1
    Видимо табы с пробелами будут обсуждаться до тех пор, пока каждый для себя не примет четкого, взвешенного и обоснованного решения использовать то или другое.
    • +2
      Поправочка: Пока все не согласятся с твоим единственно верным решением о том, что надо использовать.
      • 0
        PS Если что, то твоим == %username%
    • +3
      Табы с пробелами будут обсуждаться до тех пор, пока не прекратятся провокации по этому поводу. Особенно такие: «Не-не, я не хочу развязывать холивар, но пробелы всё-таки лучше».
      • 0
        <holywar-begin><irony>Не-не, я вовсе не хочу поддаваться на провокацию, но табы всё таки получше будут.</irony></holywar-begin>
  • 0
    Может вам стоит ещё проверить Wine? Любопытно насколько много проблем у него…

    Или не выйдет?
    • +2
      Wine под Windows? Под Visual Studio?
      • 0
        Вот я тоже подумал что не выйдет(
      • +1
        Вообще-то WINE для Windows существует. Используется разработчиками WINE понятно для чего.
      • +2
        Вы будете смеяться, но есть масса программ, которые плохо работают в новых версиях Windows, но прекрасно работают под Wine (из-за чего Wine собственно имеет смысл и для Windows).
  • 0
    strcmp(name1, name1)

    А тут всё в порядке?
    • +1
      Там и написано: «опечатка в один символ».
  • +2
    Мысли, глядя на код:

    1. Как страшно жить. Как над пороховым погребом или болотом.
    2. Цивилизация обречена. У нас нет шансов. «Хотим сделать как лучше, а получается как всегда».
    3. Возможно, Си не подходит для таких больших и сложных проектов, именно потому что в нём очень мало статической проверки на этапе компиляции.
    4. Нет, Си++ тоже не подойдёт.
    5. Я не знаю, что подойдёт. Возможно, ничего.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +3
    Почему разработчики не используют авто оформитель кода?
    Мы у себя решили проблему оформления кода именно так.
    У всех одни настройки и один же оформитель кода.
  • +15
    Исправление ошибок в ReactOS чревато потерей совместимости с Windows. ;-)
  • +5
    Отличная статья, понравилась, только раздел 'Снова о табуляциях и пробелах' на мой взгляд лишний
  • 0
    Мда, и кто-то после этого может уверять, что Хабр не стадо хомячков?

    Ну и раз уж топик о чем угодно, кроме анализа кода, вопрос к рразработчикам PVS-Studio. Как думаете, миллиона евро хватит, чтобы исправить все эти ошибки? :)
    • 0
      вы про какие ошибки? про опечатки или более глобальные вещи? простые опечатки можно поправить за более скромную сумму…
  • +1
    Перевод статьи ещё не готов. Однако, если кому-то из иностранных товарищей хочется поработать со списком ошибок, то я подготовил для них вот этот файл. В нём переведены разъяснения к ошибкам.
  • +1
    Надеюсь, после исправления этих ошибок система станет намного стабильнее.
  • +2
    Наблюдал эту ОС на кассах в Фуршете. Так там у кассирш стандартная операция — ребут компа. Висла каждый раз при скане их же карточки со скидкой. Хорошо хоть грузится шустро…
    • +4
      Мне интересно, кто додумался её использовать в реальном коммерческом предприятии, когда сами разработчики не рекомендуют это делать. Да и ReactOS пока в альфа-версии.
      • 0
        имхо это лучший способ отладить систему… ну или получить отвращение к ней, на веки вечные…
    • 0
      А во времена Win95 это бы никого не удивило =)
  • –1
    Спасибо за статью, теперь я точно знаю, что могу писать свою операционку.
  • 0
    > давно хотелось написать статью об обыкновенном проекте

    Прозвучало как-то унизительно для ReactOS. Никакой исключительности.
  • 0
    А найденые ошибки были закоммичены? если работа была проделанна, почему не сдлеать вклад в ОпенСорс

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

Самое читаемое Разное