В первую очередь я, конечно, хочу порекомендовать наш сайт viva64.com. Здесь можно найти много статей и записей в блоге, касающихся разработке качественного кода. Например, предлагаю познакомиться с 28 уроками, посвященными разработке 64-битных приложений на языке Си/Си++.

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

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

Си++ живее всех живых

• Большой список известных проектов, которые разрабатываются на языке Си/Си++: C++ Applications. И после этого кто-то говорит, что язык Си++ вымирает?
• Computer Language Benchmarks Game. Как всегда по скорости лидируют языки Fortran, Си и Си++. И вряд ли что-то в обозримом времени изменится. Если вы разрабатываете ресурсоемкое программное обеспечение, то Си++ может оказаться оптимальным выбором.
• Why is C++ still a very popular language in quantitative finance?
• Why do they program in C++?
• 9 reasons to start using C++11

Интересные блоги

• Steve Hanov's Blog
• Visual C++ Team Blog
• The Old New Thing

Арифметика с плавающей запятой

• What Every Computer Scientist Should Know About Floating-Point Arithmetic
• Tricks With the Floating-Point Format
• Stupid Float Tricks
• Comparing Floating Point Numbers, 2012 Edition

Разные приёмы при программировании

• Bit Twiddling Hacks
• Table-driven methods with no relocations
• Reduce Compilation Dependencies in Large Scale C++ Projects: Factory Pattern
• Exceptions in C with Longjmp and Setjmp
• Catching Integer Overflows in C. Article N1, N2
• Cool C Tricks

О кодировках символов и управляющих символах

• Unicode, UTF-8 and all that: An intentionally incomplete character set introduction for hasty C programmers
• What the xxxx Is UTF-8? A Character Encoding Primer.
• ASCII Characters
• Control character
• The UTF-8 Everywhere manifesto

Стандарты кодирования

• Google C++ Style Guide
• CERT. C Secure Coding Standard, C++ Secure Coding Standard
• Joint Strike Fighter (F-35) C++ Coding Standard

Группы

• Reddit: Cpp, C_Programming.
• Facebook: C++ Programming, For the love of C++, C Programming, Visual C++ Developer, C Plus Plus (C++)
• LinkedIN: C++ Community Group, C++ Developers Forum, C++ Developers Group, C++ Professionals

Разное

• What's Wrong With GNU make?
• Почему strncpy не безопаснее strcpy: strncpy? just say no
• A Guide to Undefined Behavior in C and C++. Part N1, N2, N3
• Компиляция 64-битных приложений в Visual C++ 2008 Express Edition. Visual C++ 2008 Express Edition And 64-Bit Targets
• Windows Data Alignment on IPF, x86, and x64
• C/C++ Low Level Curriculum. Part N1, N2, N3, N4, N5, N6, N7, N8
• Ссылки на различные ресурсы по тематике Си++. Список ссылается на много старых ресурсов, но его стоит посмотреть.
• Functional Programming in C++
• The C++ Lands (забавная картинка)
• Translate C declaration
• Arbitrary Data Sizes with C

Предыдущие статьи доступны здесь: [1], [2].

Исторический экскурс

В начале немного истории. Необходимость операций сдвига битов очевидна любому программисту. Рано или поздно каждый сталкивается с необходимостью работать с отдельными битами и битовыми масками. Тем не менее, операции сдвига намного более популярны, чем должны были быть. Причина в том, что используя сдвиги можно умножать и делить числа на степень двойки. Например, операция "X << 3" умножит X на 8. Преимущество такого способа умножения и деления заключалось в скорости их работы в прошлом.

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

Умножение 16-битного регистра на ячейку памяти с использованием инструкции MUL на процессоре 8086 требует порядка 124-139 тактов!

Сдвиг 16-битного регистра на N позиций с использованием инструкции SHL на процессоре 8086 требует 8+4*N тактов. То есть в худшем случае получается 72 такта.

Можно было получить существенное ускорение при вычислении арифметических выражений используя различные трюки при работе с битовыми операциями. Это и стало причиной массового использования сдвигов, в начале, на языке ассемблер, потом в языках Си и Си++. Первые компиляторы Си/Си++ были просты. Человек мог получить выигрыш в скорости, явно подсказав компилятору, что здесь следует использовать сдвиг, а не инструкции умножения или деления.

С развитием процессоров польза от использования сдвигов долгое время сохранялась. В 80486 процессоре умножение стало занимать около 26 тактов. Вроде намного лучше. Однако сдвиг стал занимать всего 3 такта и вновь, был более привлекателен, чем умножение.

К счастью эти вынужденные оптимизации в большинстве своём канули в небытие. Во-первых, компиляторы стали умны и используют оптимальный набор инструкций для вычисления арифметических выражений. Во-вторых, процессоры также колоссально изменились. Появились конвейеры, предсказание переходов, переименование регистров и много чего ещё. Поэтому сказать, сколько времени займет выполнение той или иной инструкции обыкновенный программист уже не в состоянии. Но ясно, что если код местами будет не идеален, этого можно даже не заметить. Процессор разобьет инструкции на микроинструкции и начнет выполнять их параллельно. Если честно, то я уже не разбираюсь, как сейчас там всё происходит. Я понял, что разбираться в тонкостях бессмысленно, начиная с процессора Intel Pentium. И сделал вывод, что не стоит думать, что ты лучше знаешь, как нужно писать оптимизирующий код, использовать сдвиги и битовые операции, где только можно. Далеко не факт, что в результате код будет быстрее, чем сделает это оптимизатор в компиляторе. Зато точно можно сказать, что программа станет запутанной и сложной для понимания.

Примечание. Вышесказанное не значит, что использование битовых операций больше не может приносить выгоды. Есть много интересных и полезных трюков [3]. Главное не увлекаться.

Неопределенное поведение

Началось всё с того, что я решил увеличить в анализаторе PVS-Studio количество предупреждений связанных с undefined behaviour [4] и unspecified behavior [5]. Достаточно быстро и просто было реализовано правило, выявляющее некорректное использование операций сдвига. После этого мне пришлось остановиться и задуматься.

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

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

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

Итак, посмотрим, что написано в стандарте C++11 по поводу операторов сдвига:

The shift operators << and >> group left-to-right.

shift-expression << additive-expression

shift-expression >> additive-expression

The operands shall be of integral or unscoped enumeration type and integral promotions are performed.

1. The type of the result is that of the promoted left operand. The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand.

2. The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has an unsigned type, the value of the result is E1 * 2^E2, reduced modulo one more than the maximum value representable in the result type. Otherwise, if E1 has a signed type and non-negative value, and E1*2^E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.

3. The value of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a non-negative value, the value of the result is the integral part of the quotient of E1/2^E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined.

Читать подобные тексты грустно и печально. Но не волнуйтесь. Сейчас мы рассмотрим различные некорректные ситуации на примерах.

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

int A = 10;
int B = A << -5;

Так, слава богу, никто не делает. По крайней мере, проанализировав более 70 open-source проектов, мы не встретили подобных ошибок.

Следующий случай гораздо интереснее. Это сдвиг на N бит, где N, большее, чем количество бит в левом операнде. Простейший пример:

int A = 10;
int B = A << 100;

Посмотрим, как такая ошибка может выглядеть на практике. Следующий фрагмент кода был обнаружен нами в библиотеке Lib7z:

SZ_RESULT
SafeReadDirectUInt64(ISzInStream *inStream, UInt64 *value)
{
  int i;
  *value = 0;
  for (i = 0; i < 8; i++)
  {
    Byte b;
    RINOK(SafeReadDirectByte(inStream, &b));
    *value |= ((UInt32)b << (8 * i));
  }
  return SZ_OK;
}

Диагностическое сообщение PVS-Studio: V610 Undefined behavior. Check the shift operator '<<. The right operand ('(8 * i)' = [0..56]) is greater than or equal to the length in bits of the promoted left operand. lib7z 7zin.c 233

Функция пытается побайтно прочитать 64-битное значение. К сожалению, у неё это не получится, если число было больше 0x00000000FFFFFFFF. Обратите внимание на сдвиг "(UInt32)b << (8 * i)". Размер левого операнда составляет 32 бита. При этом сдвиг происходит от 0 до 56 бит. На практике это приведёт к тому, что старшая часть 64-битного значения останется заполнена нулями. Теоретически здесь вообще имеет место неопределенное поведение и результат непредсказуем.

Корректный код должен выглядеть так:

*value |= ((UInt64)b << (8 * i));

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

char A = 1;
int B = A << 20;

Да, корректен. Слева от оператора << находится переменная A, состоящая только из 8 бит. Но перед началом операции сдвига, левая часть будет расширена до типа int. Соответственно, значение типа 'int' можно сдвинуть на 20 бит.

А теперь самый интересный момент. Это сдвиг отрицательных значений. Простейший пример:

int A = (-1) << 5; // undefined behavior
int B = (-1) >> 5; // unspecified behavior

В этом коде имеет место неопределённое и неуточненное поведение. С практической точки зрения разницы нет. Вывод один - так писать нельзя.

На этом можно было бы поставить точку и привести пару примеров. К сожалению, есть два нюанса, которые портят идеальную картину мира.

Нюансы, которые портят идеальную картину мира

Нюанс N1. В старом стандарте языка Си++ от 1998 года ситуации с неопределенным поведением обходятся стороной. Сказано, как ведет себя оператор << при сдвиге беззнаковых значений. А про знаковые значения ничего не сказано. В общем, тот самый случай, когда чтение стандарта не прибавляет ясности. Не рассматривается такой случай и всё.

Итак, с точки зрения Си++ от 1998 года, конструкция "(-1) << 5" не приводит к неопределенному поведению. Впрочем, как она должна работать, тоже не описывается.

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

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

В старом стандарте Си++ и не сказано про неопределенное поведение. В новом сказано. Получается, что старый стандарт просто был недостаточно точен. Кстати, в новом стандарте языка Си (я смотрел черновик от 25 июня 2010), также сказано, что сдвиги отрицательных значений приводят к неопределенному поведению. Вывод - следует избавиться от некорректного кода.

Теперь по поводу повсеместного использования опасных сдвигов. Их действительно много. Например, в библиотеке JPEG необходимо заполнить массив следующими значениями:

11...11111111111111b
11...11111111111101b
11...11111111111001b
11...11111111110001b
....

Это записано так:

/* entry n is (-1 << n) + 1 */
static const int extend_offset[16] = { 0,
  ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1,
  ((-1)<<4) + 1, ((-1)<<5) + 1, ((-1)<<6) + 1,
  ((-1)<<7) + 1, ((-1)<<8) + 1, ((-1)<<9) + 1,
  ((-1)<<10) + 1, ((-1)<<11) + 1, ((-1)<<12) + 1,
  ((-1)<<13) + 1, ((-1)<<14) + 1, ((-1)<<15) + 1
};

Сложно назвать библиотеку JPEG плохой. И этот код проверен временем и разными компиляторами.

С точки зрения стандарта его теперь следует переписать так:

static const int extend_offset[16] =
{ 0,
  ((~0u)<<1) | 1, ((~0u)<<2) | 1, ((~0u)<<3) | 1,
  ((~0u)<<4) | 1, ((~0u)<<5) | 1, ((~0u)<<6) | 1,
  ((~0u)<<7) | 1, ((~0u)<<8) | 1, ((~0u)<<9) | 1,
  ((~0u)<<10) | 1, ((~0u)<<11) | 1, ((~0u)<<12) | 1,
  ((~0u)<<13) | 1, ((~0u)<<14) | 1, ((~0u)<<15) | 1
};

Но стоит ли вносить такие правки решать вам. Я могу только дать совет всё-таки это сделать. Неизвестно когда и как, это может себя проявить.

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

Выводы

1. Раньше использование битовых операций и сдвигов было признаком мастерства программиста и позволяло писать быстрый код. Сейчас это почти не актуально. Намного важнее, чтобы код был понятным. Используйте игры с битами только в случае реальной необходимости.
2. Выражения вида "(-1) << N" теперь объявлены некорректными и производящими к неопределенному поведению.
3. Выражения вида "(-1) << N" давно и часто используются. Поэтому сложно привести реальные аргументы против использования таких конструкций. Аргументом являются только новые стандарты языков Си и Си++.
4. Решайте сами, исправить сдвиг отрицательных значений или нет. Но я рекомендую исправить. Хотя бы на всякий случай.
5. Диагностические сообщения, касающиеся опасных сдвигов будут доступны в PVS-Studio начиная с версии 4.60, которая скоро выйдет.

Дополнительные ресурсы

1. Не зная брода, не лезь в воду. Часть первая. http://www.viva64.com/ru/b/0127/
2. Не зная брода, не лезь в воду. Часть вторая. http://www.viva64.com/ru/b/0129/
3. Sean Eron Anderson. Bit Twiddling Hacks. http://www.viva64.com/go.php?url=837
4. Wikipedia. Неопределённое поведение. http://www.viva64.com/go.php?url=663
5. Wikipedia. Неуточняемое поведение. http://www.viva64.com/go.php?url=738
6. Алёна C++. Разница между unspecified behavior и undefined behavior. http://www.viva64.com/go.php?url=739

Конечно, в другие подразделения Intel я тоже хочу сделать продажи. Просто разработчики IPP кажутся ближе. Во-первых, часть из них находится в России. Во-вторых, они уже применяют в работе статические анализаторы. В-третьих, у нас уже есть задел в данном направлении. Я имею в виду, что мы уже проверяли два раза проект IPP Samples (первая проверка, вторая проверка). Конечно, намного было бы интереснее проверить не примеры, а саму библиотеку IPP, но к её исходным кодам у нас нет доступа.

Итак, пытаться прорекламировать себя я буду стандартной методикой. Мы будем продолжать время от времени перепроверять IPP Samples и находить новые ошибки. Это говорит о том, что анализатор кода PVS-Studio активно развивается. Хотя конечно основная ценность его применения не в разовых запусках, а в регулярном использовании. Не стоит забывать про возможности ночных запусков и фоновый анализ после компиляции.

Привожу некоторые новые ошибки, выявленные с помощью PVS-Studio v4.60. Конечно, я привожу не все подозрительные места. Их гораздо больше, но я затрудняюсь понять, являются они ошибочными или нет. Заодно это повод разработчикам IPP установить и попробовать наш инструмент. Мы изменили триальную модель, и теперь инструмент обладает полной функциональностью. Попробуйте.

Итак, рассмотрим подозрительные места в коде IPP Samples.

Ситуация N1. Бессмысленное высказывание

AACStatus bsacdecSetNumChannels(Ipp32s channelConfiguration,
                                AACDec *state)
{
  state->com.m_channel_number = channelConfiguration;
  if (channelConfiguration == 7) {
    state->com.m_channel_number;
  }

  return AAC_OK;
}

Диагностическое сообщение PVS-Studio: V607 Ownerless expression 'state->com.m_channel_number'. aac_dec aac_dec_api_fp.c 1404

Высказывание "state->com.m_channel_number;" очень странное. Возможно, здесь забыто присваивание или что-то ещё.

Ситуация N2. Заполнение таблицы виртуальных методов

В IPP Samples встречается достаточно много мест, где память для классов выделяется с помощью функции malloc() и инициализируется с помощью функции memset(). Может в этом и нет ничего страшного, но смущает то, что у этих классов есть виртуальные методы. Таким образом, есть опасения, что таблица виртуальных методов может быть испорчена, и что-то будет работать не так.

Например, класс _MediaDataEx содержит виртуальные функции:

virtual bool TryStrongCasting(....) const;
virtual bool TryWeakCasting(....) const;

А вот как создаётся объект этого класса:

Status VC1Splitter::Init(SplitterParams& rInit)
{
  MediaDataEx::_MediaDataEx *m_stCodes;
  ...
  m_stCodes = (MediaDataEx::_MediaDataEx *)
    ippsMalloc_8u(
      START_CODE_NUMBER*2*sizeof(Ipp32s)+
      sizeof(MediaDataEx::_MediaDataEx));
  ...
  memset(m_stCodes, 0,
   (START_CODE_NUMBER*2*sizeof(Ipp32s)+
   sizeof(MediaDataEx::_MediaDataEx)));
  ...
}

Диагностическое сообщение PVS-Studio: V598 The 'memset' function is used to nullify the fields of '_MediaDataEx' class. Virtual method table will be damaged by this. vc1_spl umc_vc1_spl.cpp 131

Не знаю, есть здесь беда или нет, но предупредить стоит.

Аналогичную картину можно наблюдать в следующих местах:

V598 The 'memset' function is used to nullify the fields of '_MediaDataEx' class. Virtual method table will be damaged by this. vc1_dec umc_vc1_video_decoder.cpp 641 False

V598 The 'memset' function is used to nullify the fields of 'AVS_DISASSEMBLING_CONTEXT' class. Virtual method table will be damaged by this. avs_enc umc_avs_enc_slice.cpp 45

V598 The 'memset' function is used to nullify the fields of 'AVS_DISASSEMBLING_CONTEXT' class. Virtual method table will be damaged by this. avs_enc umc_avs_enc_slice.cpp 29

V598 The 'memset' function is used to nullify the fields of 'AVS_DISASSEMBLING_CONTEXT' class. Virtual method table will be damaged by this. avs_enc umc_avs_enc_slice.cpp 22

V598 The 'memcpy' function is used to copy the fields of 'AVSVideoEncoderParams' class. Virtual method table will be damaged by this. avs_enc umc_avs_enc.cpp 115

V598 The 'memset' function is used to nullify the fields of 'AVS_DECODING_CONTEXT' class. Virtual method table will be damaged by this. avs_dec umc_avs_dec_slice_init.cpp 65

V598 The 'memset' function is used to nullify the fields of 'AVS_DEBLOCKING_CONTEXT' class. Virtual method table will be damaged by this. avs_common umc_avs_slice.cpp 153

V598 The 'memset' function is used to nullify the fields of 'AVS_RECONSTRUCTING_CONTEXT' class. Virtual method table will be damaged by this. avs_common umc_avs_slice.cpp 133

V598 The 'memset' function is used to nullify the fields of 'AVS_DEBLOCKING_CONTEXT' class. Virtual method table will be damaged by this. avs_common umc_avs_slice.cpp 43

V598 The 'memset' function is used to nullify the fields of 'AVS_RECONSTRUCTING_CONTEXT' class. Virtual method table will be damaged by this. avs_common umc_avs_slice.cpp 42

V598 The 'memset' function is used to nullify the fields of 'AVS_DECODING_CONTEXT' class. Virtual method table will be damaged by this. avs_common umc_avs_slice.cpp 41

V598 The 'memset' function is used to nullify the fields of 'AVS_DEBLOCKING_CONTEXT' class. Virtual method table will be damaged by this. avs_common umc_avs_slice.cpp 32

V598 The 'memset' function is used to nullify the fields of 'AVS_RECONSTRUCTING_CONTEXT' class. Virtual method table will be damaged by this. avs_common umc_avs_slice.cpp 31

V598 The 'memset' function is used to nullify the fields of 'AVS_DECODING_CONTEXT' class. Virtual method table will be damaged by this. avs_common umc_avs_slice.cpp 30

Ситуация N3. Проверка указателей после использования

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

Пример:

VIDEO_DRV_CREATE_BUFFERS_FUNC(....)
{
  ...
  VideoDrvVideoMemInfo* drv_vm = &(driver->m_VideoMemInfo);
  ...
  if ((NULL == driver) || (NULL == bufs))
  {
    ERR_SET(VM_NULL_PTR, "null ptr");
  }
  ...
}

Диагностическое сообщение PVS-Studio: V595 The 'driver' pointer was utilized before it was verified against nullptr. Check lines: 40, 46. video_renders drv.c 40

Здесь проверку указателя нужно переместить выше или совсем удалить, если ситуация "dreiver==NULL" невозможна.

Вот другие аналогичные примеры кода:

Ipp16s *pNewSpeech = encoderObj->stEncState.pSpeechPtrNew;
if (NULL==encoderObj || NULL==src || NULL ==dst )
  return APIGSMAMR_StsBadArgErr;

Диагностическое сообщение PVS-Studio: V595 The 'encoderObj' pointer was utilized before it was verified against nullptr. Check lines: 296, 298. speech encgsmamr.c 296

m_pAVSCompressorParams = DynamicCast<AVSVideoEncoderParams> (pParams);
...
m_qp = m_pAVSCompressorParams->m_iConstQuant;
// check error(s)
if (NULL == m_pAVSCompressorParams)
  return UMC_ERR_NULL_PTR;

Диагностическое сообщение PVS-Studio: V595 The 'm_pAVSCompressorParams' pointer was utilized before it was verified against nullptr. Check lines: 88, 91. avs_enc umc_avs_enc_fusion_core.cpp 88

Ситуация N4. Подозрительные выражения с запятыми

Есть пара ситуаций с подозрительными запятыми ','. Первый пример:

void GetIntraDCPredictors(VC1Context* pContext)
{
  DCPred.DC[13] = pC->DCBlkPred[5].DC,QurrQuant;
  ...
}

Диагностическое сообщение PVS-Studio: V521 Such expressions using the ',' operator are dangerous. Make sure the expression is correct. vc1_dec umc_vc1_dec_mb_com.cpp 370

Быть может просто опечатка, а возможно здесь что-то не хватает.

Второй пример:

V521 Such expressions using the ',' operator are dangerous. Make sure the expression is correct. speech usc_dtmf.c 309

static int DTMF_16s(....)
{
  ...
  for (i = pIppTDParams->dtmf_fs, j = 0;
       i < dtmf_frame_size+pIppTDParams->dtmf_fs, j < nbytes;
       i++, j++)
}

Диагностическое сообщение PVS-Studio: V521 Such expressions using the ',' operator are dangerous. Make sure the expression is correct. speech usc_dtmf.c 309

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

i < dtmf_frame_size+pIppTDParams->dtmf_fs && j < nbytes

Ситуация N5. Подозрительное неявное приведение типа

class MeMV
{
public:
  MeMV(){};
  MeMV(int a0){x = (Ipp16s)a0; y=(Ipp16s)a0;};
  MeMV(int a0, int a1){x = (Ipp16s)a0; y=(Ipp16s)a1;};
  ...
}

MeMV MePredictCalculatorVC1::GetPrediction8x8()
{
  ...
  default:
    return false;
  ...
}

Диагностическое сообщение PVS-Studio: V601 The 'false' value becomes a class object. me umc_vec_prediction.cpp 754

Функция GetPrediction8x8() возвращает тип MeMV. Однако в одной из ветвей, она возвращает значение 'false'. Это значение неявно приводится int и вызывается конструктор MeMV(int a0). Я не знаю, но возможно здесь необходимо вернуть что-то ещё или сгенерировать исключение.

Аналогичное неявное приведение типа присутствует здесь:

V601 The 'false' value becomes a class object. me umc_vec_prediction.cpp 717

Ситуация N6. Неопределенное поведение

В очень многих местах IPP Samples встречаются конструкции, которые приводят к неопределенному или неуточненному поведению. О некоторых я писал в предыдущей заметке. Теперь обнаружилось огромное количество сдвигов отрицательных значений. Я не берусь утверждать, что это может создать где-то проблемы, но предлагаю на всякий случай обратить внимание на эту статью: "Не зная брода, не лезь в воду. Часть третья".

Где располагается потенциально опасный код можно посмотреть в этом файле: ipp-samples-ub.txt.

Заключение

Уважаемые разработчики IPP и IPP Samples, мы ждем ваших писем. Мы готовы обсудить и реализовать недостающий функционал в инструменте PVS-Studio, который препятствует его использованию. Мы также готовы реализовать критичные для вашего проекта диагностические правила.

Всем остальным желаю безглючного кода и приглашаю в твиттер @Code_Analysis. В нём мы размещаем ссылки на интересные статьи про Си++, программирование, статический анализ кода и инструмент PVS-Studio.

Не зная брода, не лезь в воду. Часть первая.

Аннотация. Программисты - ленивые существа. Поэтому норовят решить задачу минимальным количеством кода. Это похвальное и хорошее стремление. Главное не увлечься процессом и вовремя остановиться. Например, программистам бывает лень создавать единую функцию инициализации в классе, чтобы затем вызывать её из разных конструкторов. Программист думает: "Зачем мне лишняя функция? Я лучше вызову один конструктор из другого". К сожалению, даже эту простую задачу программисту удается решить не всегда.

Не зная брода, не лезь в воду. Часть вторая.

Аннотация. В этот раз я хочу поговорить о функции printf. Все наслышаны об уязвимостях в программах, и что функции наподобие printf объявлены вне закона. Но одно дело знать, что лучше не использовать эти функции. А совсем другое - понять почему. В этой статье я опишу две классических уязвимости программ, связанных с printf. Хакером после этого вы не станете, но, возможно, по-новому взгляните на свой код. Вдруг, вы реализуете аналогичные уязвимые функции, даже не подозревая об этом.

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

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

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

P.S. Приглашаю в мой твиттер: @Code_Analysis

Миф пятый: "Возможности статического анализатора легко оценить, написав тестовый пример".

Вот как выглядит такое утверждение при обсуждении (собирательный образ):

Я написал специальную программу, размером в 100 строк кода. Но анализатор ничего мне не выдает, хотя у меня включены все уровни предупреждений. Глупость этот ваш [инструмент] / [статический анализ] в целом.

Глупостью является не методология статического анализа, а такой подход к попытке оценить пользу от использования конкретного инструмента. Некорректность исследования инструмента складывается из двух моментов:

1. Программисты думают, что не допускают простых ошибок. Этот феномен был рассмотрен в Мифе номер 2. Поэтому они стараются подсунуть анализатору хитрый пример и втайне радуются, если анализатор не смог найти ошибку. Эта игра интересна, но не имеет практического смысла.

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

int threadcounts[] = { 1, kNumThreads };
for (size_t i = 0;
     i < sizeof(threadcounts) / sizeof(threadcounts); i++) {

Сомневаюсь. Невозможно представить, что можно сделать такую тупую ошибку и написать "sizeof(threadcounts) / sizeof(threadcounts)". Соответственно, такой пример никогда составлен не будет. А, между прочим, этот код не из лабораторной работы студента, а из проекта Chromium. И конечно, он прекрасно диагностируется анализатором PVS-Studio.

2. Составленные примеры носят случайный характер. Причем примеров мало. Поэтому получается, что в зависимости от удачи можно получить разнообразнейший результат. Можно придумать 5 ошибок, которые будут успешно найдены первым анализатором, и не обнаружены вторым. А можно придумать программу с пятью ошибками, на которых анализаторы покажут противоположные результаты. Выборка для исследования слишком мала. Чтобы хоть как-то сравнивать и изучать, нужно придумать текст программы, где имеется хотя бы 500 разных ошибок. Исследования на примерах с 5-10 ошибками ничего не дают.

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

void Foo()
{
  int *a = (int *)malloc(X);
  int *b = (int *)malloc(Y);
  //...
  free(a);
}

Какие-то анализаторы диагностируют эту ошибку, какие-то нет. Например, PVS-Studio пока не работает с утечками памяти. Зато, он обнаружит такое:

static int rr_cmp(uchar *a,uchar *b)
{
  if (a[0] != b[0])
    return (int) a[0] - (int) b[0];
  if (a[1] != b[1])
    return (int) a[1] - (int) b[1];
  if (a[2] != b[2])
    return (int) a[2] - (int) b[2];
  if (a[3] != b[3])
    return (int) a[3] - (int) b[3];
  if (a[4] != b[4])
    return (int) a[4] - (int) b[4];
  if (a[5] != b[5])
    return (int) a[1] - (int) b[5];
  if (a[6] != b[6])
    return (int) a[6] - (int) b[6];
  return (int) a[7] - (int) b[7];
}

Здесь вместо "return (int) a[1] - (int) b[5];" должно быть "return (int) a[5] - (int) b[5];".

Почему никто никогда не составляет подобные примеры? А ведь эту ошибку PVS-Studio нашел в проекте MySQL.

Вывод. Адекватное исследование или сравнение инструментов может быть только на реальных проектах. Взяли проект A. Проверили его с помощью PC-Lint / Visual C++ / PVS-Studio / C++Test. Внимательно проанализировали все сообщения. Составили табличку, какой анализатор сколько ошибок нашел. Вот единственное настоящее изучение и сравнение. Пример: "Сравнение статического анализа общего назначения из Visual Studio 2010 и PVS-Studio на примере обнаруженных ошибок в пяти открытых проектах ".

Миф четвертый: "Статический анализатор должен иметь возможность добавлять пользовательские правила. Программисты хотят добавлять свои собственные правила."

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

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

Дмитрий подтвердил моё убеждение, что программисты не будут писать диагностические правила. Причина очень простая - это очень сложно. В ряде инструментов статического анализа есть возможность расширять набор правил. Но сделано это скорее для галочки или для удобства самих создателей инструмента. Требуется очень глубокое погружение в тему, чтобы разрабатывать новые диагностики. Если за это возьмется энтузиаст без опыта, то практической пользы от его правил будет мало.

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

Программисты действительно хотят искать некоторые паттерны/ошибки в своём коде. Им это действительно нужно. Например, человеку нужно найти вся явные приведения от типа int к float. Эту задачу нельзя решить, используя такие инструменты, как grep. Ведь в конструкции вида "float(P->FOO())" неизвестно какой тип вернет функция FOO(). В этот момент программист и приходит к выводу, что он может реализовать поиск таких конструкций, добавив свою проверку в статическом анализаторе.

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

Именно поэтому и я, и Дмитрий не поддерживаем идеи предоставлять пользователю API для работы с анализатором. Это крайне сложная задача с точки зрения разработки. И при этом от неё человек вряд ли будет использовать более 1%. Нерационально. Разработчику проще и дешевле реализовывать пожелания пользователей, чем создавать сложный API для модулей расширения или создавать специальный язык описания правил.

Читатель заметит: "тогда откройте в API только 1% от функциональности и все будут довольны". Да, всё правильно. Но смотрите, как сместился акцент. От разработки своих правил мы пришли к тому, что на самом деле достаточен инструмент, схожий с grep, но обладающий некоторой дополнительной информацией о коде программы.

Пока такого инструмента нет. Если вы хотите решить какую-то задачу, то можете написать мне, и мы постараемся реализовать её в анализаторе PVS-Studio. Например, недавно мы как раз реализовывали несколько пожеланий по поиску явных приведениё типов: V2003, V2004, V2005. Воплощать в жизнь такие пожелания нам намного проще, чем создавать и поддерживать открытый интерфейс. Проще это и самим пользователям.

Кстати, возможно такой инструмент со временем появится в рамках Intel C++. Дмитрий Петунин говорил, что они обсуждали возможность создания grep-подобного инструмента, обладающего знаниями о структуре кода и типах переменных. Но это обсуждалось абстрактно. Я не знаю, планируется в действительности создать такое или нет.

Миф третий: "Динамическая проверка такими инструментами, как valgrind для Си/Си++ намного продуктивнее, чем статический анализ кода".

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

Перечислю сильные стороны статического анализа кода.

Диагностика всех ветвей программы

Динамический анализ на практике не может покрыть все ветвления программы. После этих слов поклонники valgrind заявляют, что нужно делать правильные тесты. Теоретически они правы. Но любой, кто пробовал такое осуществить, понимает всю сложность и объем работы. На практике, даже хорошие тесты покрывают не более 80% программного кода.

Особенно хорошо это видно в участках кода, обрабатывающие нестандартные/аварийные ситуации. Если взять старый проект, то большинство ошибок будет выявлено статическим анализатором именно в этих местах. Причина в том, что даже если проект стар, эти участки практически не протестированы. Приведу очень короткий пример, чтобы показать, что я имею в виду (проект FCE Ultra):

fp = fopen(name,"wb");
int x = 0;
if (!fp)
  int x = 1;

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

Масштабируемость

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

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

Более высокоуровневый анализ

У динамического анализатора есть преимущество, что он знает, какая функция с какими аргументами вызывается. Как следствие он может проверить корректность вызова. Статический анализ в большинстве случаев не может это узнать и проверить значения аргументов. Это минус. Зато статический анализ проводит более высокоуровневый анализ, чем динамический. И это позволяет ему искать такие вещи, которые с точки зрения динамического анализа корректны. Простой пример (проект ReactOS):

void Mapdesc::identify( REAL dest[MAXCOORDS][MAXCOORDS] )
{
  memset( dest, 0, sizeof( dest ) );
  for( int i=0; i != hcoords; i++ )
    dest[i][i] = 1.0;
}

С точки зрения динамического анализа, здесь всё хорошо. А вот статический анализ забьет тревогу, так как очень подозрительно, что в массиве обнуляется столько байт, из скольких состоит указатель.

Или вот другой пример из проекта Clang:

MapTy PerPtrTopDown;
MapTy PerPtrBottomUp;
void clearBottomUpPointers() {
  PerPtrTopDown.clear();
}
void clearTopDownPointers() {
  PerPtrTopDown.clear();
}

Что здесь может заподозрить динамический анализатор? Ничего. А статический анализатор, может заподозрить неладное. Здесь ошибка в том, что внутри clearBottomUpPointers() должно быть:

PerPtrBottomUp.clear();

Миф второй: "Профессиональные разработчики не допускают глупых ошибок, которые в основном и ловят статические анализаторы кода".

Вот как выглядит такое утверждение при обсуждении на форуме (собирательный образ):

У меня, профессионального разработчика, уже N лет не было проблем с порчей памяти, временем жизни объектов и так далее. Статический анализ - это инструмент для "макдональдса", а здесь (на профессиональном форуме) сидят гики. Сейчас мои основные проблемы это сложно тестируемые алгоритмы и интеграция с другими разработчиками с использованием неявных контрактов по состояниям объектов.

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

Это не так. Любые программисты делают глупые ошибки. Я знаю, что вы меня не услышали. Повторю еще раз еретические мысли. Все программисты делают глупые ошибки. Неважно, какие они профессионалы. Людям свойственно делать ошибки. И чаще всего эти ошибки просты.

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

Отвлечемся немного и вспомним, почему так живучи различные гороскопы. Первая причина - это очень расплывчатые формулировки, которые человеку легко подстроить под себя. Но нам интересен второй компонент. Люди не запоминают те случаи, когда предсказание не сбылось. Зато очень хорошо помнят и пересказывают те случаи, когда их жизненная ситуация совпала с ситуацией, описанной в гороскопе. В результате получается, что, говоря и вспоминая о гороскопе, мы находим N подтверждений, что гороскопы работают и не вспоминаем про N*10 случаев, когда гороскоп не сработал.

Что-то аналогичное происходит с программистом, когда он занимается поиском ошибок. Он хорошо помнит про сложные и интересные ошибки. Может подискутировать о них с коллегами или написать заметку в блог. Когда же он заметит, что вместо переменной 'AB' он написал 'BA', то он просто исправит ляп, и этот факт сразу исчезнет из его памяти. Фрейд обратил внимание на следующую особенность памяти: человеку свойственно помнить положительные высказывания о себе и забывать отрицательные. Если человек сражается со сложной ошибкой в алгоритмической задаче, то когда он её исправляет, считает себя героем. Это стоит запомнить и даже рассказать другим. Когда он находит глупый баг, то помнить про это нет никакого повода и желания.

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

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

Миф первый: "Статический анализатор - это продукт разового применения".

Вот как выглядит такое утверждение при обсуждении на форуме (собирательный образ):

Имея пробную/крякнутую версию, можно бесплатно прогнать все свои проекты, найти несколько застаревших ошибок и, собственно, на этом успокоиться на какое-то время.

Все счастливы. Люди проверили. Разработчики анализатора не узнали, что их обманули и обокрали.

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

Аналогия:

Ставим уровень предупреждений компилятора /W0. И разрабатываем проект. Ругаемся, правим глупые ошибки и опечатки, тестируем больше и дольше. Потом изредка включаем /W3 и сражаемся с предупреждениями, а потом опять возвращаемся к /W0. При этом то, что мог подсказать компилятор на уровне /W3 мы бесстрашно и долго искали в отладчике и потратили на это в 10-100 раз больше времени. Вдобавок, обратим внимание на то, что теперь программисту не будет нравиться результат /W3. Ведь почти все ошибки он и так поправил методом тестирования и отладки. Компилятор на уровне /W3 выдает теперь в основном ложные срабатывания.

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

Так же, как и ключ /W3, использование статического анализа максимально полезно в случае регулярного использования. Кстати, статический анализ и есть своего рода расширение предупреждений, выдаваемых компилятором. Многие диагностики, которые когда то были реализованы в старых анализаторах, постепенно переходят в компилятор. Конечно, анализаторы всегда будут опережать в диагностическом плане компиляторы. Они разработаны для этого специально. У компилятора больше других забот и вдобавок на него накладываются более жесткие требования по производительности.

Некоторые в пылу дискуссии отвечают так:

Идея верна для начинающих студентов. Для специалистов это уже не так важно. Если я поставлю /W0 я хуже писать не стану. Нужно совершенствовать стиль программирования, а не увеличивать количество инструментов-костылей.

Совершенно согласен со всем написанным выше. Но давайте поиграем и вот так переделаем текст:

Идея верна для начинающих водителей. Для профессионалов это уже не так важно. Если я не пристегнусь за рулем, я хуже ездить не стану. Нужно совершенствовать стиль вождения, а не увеличивать количество страхующих компонентов.

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