Компилятор который показывает ошибки

Я регулярно проверяю различные открытые проекты, чтобы продемонстрировать возможности статического анализатора кода PVS-Studio (C, C++, C#). Настало время компилятора GCC. Бесспорно, GCC — это очень качественный и оттестированный проект, поэтому найти в нём хотя бы несколько ошибок уже большое достижение для любого инструмента. К моей радости, PVS-Studio справился с этой задачей. Никто не застрахован от опечаток и невнимательности. Именно поэтому PVS-Studio может стать вашей дополнительной линией обороны на фронте бесконечной войны с багами.

GCC

GNU Compiler Collection (обычно используется сокращение GCC) — набор компиляторов для различных языков программирования, разработанный в рамках проекта GNU. GCC является свободным программным обеспечением, распространяется фондом свободного программного обеспечения на условиях GNU GPL и GNU LGPL и является ключевым компонентом GNU toolchain. Проект написан на языке C и C++.

Компилятор GCC имеет хорошие встроенные диагностики, помогающие выявлять многие ошибки на этапе компиляции. Естественно, GCC собирается с помощью GCC и, соответственно, может выявлять ошибки в собственном коде. Дополнительно исходный код GCC проверяется с помощью анализатора Coverity. Да и вообще, думаю GCC проверялся энтузиастами с помощью многих анализаторов и других инструментов. Это делает поиск ошибок в GCC большим испытанием для анализатора кода PVS-Studio.

Для анализа была взята trunk версия из git-репозитория: (git) commit 00a7fcca6a4657b6cf203824beda1e89f751354b svn+ssh://gcc.gnu.org/svn/gcc/trunk@238976

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

Предвидя дискуссию

Как я сказал во введении, я считаю GCC проектом с высоким качеством кода. Уверен, многие захотят поспорить. В качестве примера приведу цитату из Wikipedia на русском языке:

Некоторые разработчики OpenBSD, например Тео де Раадт и Отто Мурбек (Otto Moerbeek), критикуют GCC, называя его «громоздким, глючным, медленным и генерирующим плохой код».

Я считаю такие заявления необоснованными. Да, возможно, код GCC содержит много макросов, которые затрудняют его чтение. Но я никак не могу согласиться с заявлением о его глючности. Если бы GCC глючил, вообще бы нигде ничего не работало. Вы только вспомните, как много программ им компилируется и успешно работает. Создатели GCC делают огромную, сложную работу с большим профессионализмом. Спасибо им. Я рад, что могу протестировать работу PVS-Studio на таком высококачественном проекте.

Для тех, кто скажет, что код компилятора Clang всё равно круче, напомню: в нём PVS-Studio также находил ошибки: 1, 2.

PVS-Studio

Я проверил код GCC с помощью Alpha-версии анализатора PVS-Studio for Linux. Мы планируем начать выдавать заинтересовавшимся программистам Beta-версию анализатора в середине сентября 2016 года. Инструкцию о том, как стать одним из первых, кто сможет попробовать Beta-версию PVS-Studio for Linux на своём проекте, вы найдете в статье «PVS-Studio признаётся в любви к Linux».

Если вы читаете эту статью гораздо позже, чем сентябрь 2016, и хотите попробовать PVS-Studio for Linux, то приглашаю вас на страницу продукта: http://www.viva64.com/ru/pvs-studio/

Результаты проверки

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

К сожалению, я не могу выдать разработчикам компилятора полный отчёт. В нем пока слишком много мусора (ложных срабатываний), связанных с тем, что анализатор не полностью готов к встрече с миром Linux. Нужно проделать работу по уменьшению количества ложных предупреждений на типовые используемые конструкции. Попробую пояснить на одном простом примере. Многие диагностики не должны ругаться на выражения, относящиеся к макросам assert. Эти макросы бывают устроены весьма творчески и надо научить анализатор не обращать на них внимание. Но дело в том, что определяется макрос assert очень по-разному, и надо обучить анализатор всем типовым вариантам.

Поэтому разработчиков GCC прошу подождать выхода по крайней мере Beta-версии анализатора. Я не хочу испортить впечатление отчетом, сгенерированным недоделанной версией.

Классика (Copy-Paste)

Начнем мы с самой классической и распространённой ошибки, которая выявляется с помощью диагностики V501. Как правило, такие ошибки появляются из-за невнимательности при Copy-Paste или просто являются опечатками, допускаемыми при наборе нового кода.

static bool
dw_val_equal_p (dw_val_node *a, dw_val_node *b)
{
  ....
  case dw_val_class_vms_delta:
    return (!strcmp (a->v.val_vms_delta.lbl1,
                     b->v.val_vms_delta.lbl1)
            && !strcmp (a->v.val_vms_delta.lbl1,
                        b->v.val_vms_delta.lbl1));
  ....
}

Предупреждение анализатора PVS-Studio: V501 There are identical sub-expressions ‘!strcmp(a->v.val_vms_delta.lbl1, b->v.val_vms_delta.lbl1)’ to the left and to the right of the ‘&&’ operator. dwarf2out.c 1428

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

Функция strcmp дважды сравнивает одни и те же строки. Мне кажется, второй раз следовало сравнивать не члены класса lbl1, а lbl2. Тогда корректный код должен выглядеть так:

return (!strcmp (a->v.val_vms_delta.lbl1,
                 b->v.val_vms_delta.lbl1)
        && !strcmp (a->v.val_vms_delta.lbl2,
                    b->v.val_vms_delta.lbl2));

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

Ошибки, возможно, удалось бы избежать, если использовать «табличное» выравнивание кода. Например, ошибку было бы легче заметить, если отформатировать код так:

Подробнее я рассматривал такой подход в электронной книге «Главный вопрос программирования, рефакторинга и всего такого» (см. главу N13: Выравнивайте однотипный код «таблицей»). Рекомендую всем, кто заботится о качестве своего кода, познакомиться с приведённой здесь ссылкой.

Давайте рассмотрим ещё одну ошибку, которая, я уверен, появилась из-за Copy-Paste:

const char *host_detect_local_cpu (int argc, const char **argv)
{
  unsigned int has_avx512vl = 0;
  unsigned int has_avx512ifma = 0;
  ....
  has_avx512dq = ebx & bit_AVX512DQ;
  has_avx512bw = ebx & bit_AVX512BW;
  has_avx512vl = ebx & bit_AVX512VL;       // <=
  has_avx512vl = ebx & bit_AVX512IFMA;     // <=
  ....
}

Предупреждение анализатора PVS-Studio: V519 The ‘has_avx512vl’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 500, 501. driver-i386.c 501

В переменную has_avx512vl дважды подряд записываются различные значения. Это не имеет смысла. Я изучил код и обнаружил переменную has_avx512ifma. Скорее всего, именно она и должна инициализироваться выражением ebx & bit_AVX512IFMA. Тогда корректный код должен быть таким:

has_avx512vl   = ebx & bit_AVX512VL;    
has_avx512ifma = ebx & bit_AVX512IFMA;

Опечатка

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

static bool
ubsan_use_new_style_p (location_t loc)
{
  if (loc == UNKNOWN_LOCATION)
    return false;

  expanded_location xloc = expand_location (loc);
  if (xloc.file == NULL || strncmp (xloc.file, "1", 2) == 0
      || xloc.file == '' || xloc.file[0] == 'xff'
      || xloc.file[1] == 'xff')
    return false;

  return true;
}

Предупреждение анализатора PVS-Studio: V528 It is odd that pointer to ‘char’ type is compared with the » value. Probably meant: *xloc.file == ». ubsan.c 1472

Здесь программист случайно забыл разыменовать указатель в выражении xloc.file == ». В результате указатель просто сравнивается с 0, т.е. с NULL. Никакого эффекта это не имеет, так как ранее такая проверка уже выполнялась: xloc.file == NULL.

Хорошо, что терминальный ноль программист записал как ». Это помогает быстрее понять, что код ошибочен и как его надо исправить. Про это я также писал в книге (см. главу N9: Используйте для обозначения терминального нуля литерал »).

Правильный вариант кода:

if (xloc.file == NULL || strncmp (xloc.file, "1", 2) == 0
    || xloc.file[0] == '' || xloc.file[0] == 'xff'
    || xloc.file[1] == 'xff')
  return false;

Хотя, давайте ещё немного улучшим код. Я рекомендую отформатировать выражение так:

if (   xloc.file == NULL
    || strncmp (xloc.file, "1", 2) == 0
    || xloc.file[0] == ''
    || xloc.file[0] == 'xff'
    || xloc.file[1] == 'xff')
  return false;

Обратите внимание: теперь, если допустить ту же ошибку, шанс её заметить будет чуть-чуть выше:

if (   xloc.file == NULL
    || strncmp (xloc.file, "1", 2) == 0
    || xloc.file == ''
    || xloc.file[0] == 'xff'
    || xloc.file[1] == 'xff')
  return false;

Потенциальное разыменование нулевого указателя

Ещё этот раздел можно было бы назвать «стотысячный пример, почему макросы — это плохо». Я очень не люблю макросы и всегда призываю поменьше их использовать. Макросы затрудняют чтение кода, провоцируют появление ошибок, усложняют работу статическим анализаторам. Как мне показалось из недолгого общения с кодом GCC, его авторы очень любят макросы. Я замучался изучать, во что раскрывается тот или иной макрос и возможно поэтому пропустил немало интересных ошибок. Признаюсь, я иногда бываю ленив. Но пару ошибок, связанных с макросами, я всё-таки продемонстрирую.

odr_type
get_odr_type (tree type, bool insert)
{
  ....
  odr_types[val->id] = 0;
  gcc_assert (val->derived_types.length() == 0);
  if (odr_types_ptr)
    val->id = odr_types.length ();
  ....
}

Предупреждение анализатора PVS-Studio: V595 The ‘odr_types_ptr’ pointer was utilized before it was verified against nullptr. Check lines: 2135, 2139. ipa-devirt.c 2135

Видите здесь ошибку? Думаю, нет, и сообщение анализатора ясности не вносит. Всё дело в том, что odr_types — это не имя переменной, а макрос, объявленным следующим образом:

#define odr_types (*odr_types_ptr)

Если раскрыть макрос и убрать всё не относящееся к делу, мы получим следующий код:

(*odr_types_ptr)[val->id] = 0;
if (odr_types_ptr)

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

Рассмотрим ещё один аналогичный случай:

static inline bool
sd_iterator_cond (sd_iterator_def *it_ptr, dep_t *dep_ptr)
{
  ....
  it_ptr->linkp = &DEPS_LIST_FIRST (list);
  if (list)
    continue;
  ....
}

Предупреждение анализатора PVS-Studio: V595 The ‘list’ pointer was utilized before it was verified against nullptr. Check lines: 1627, 1629. sched-int.h 1627

Чтобы увидеть ошибку, нам опять потребуется показать устройство макроса:

#define DEPS_LIST_FIRST(L) ((L)->first)

Раскрываем макрос и получаем:

it_ptr->linkp = &((list)->first);
if (list)
  continue;

И сейчас многие воскликнут: «Стоп, стоп! Здесь нет ошибки. Мы ведь просто получаем указатель на член класса. Никакого разыменования нулевого указателя здесь нет. Да, возможно код не аккуратен, но ошибки здесь нет!».

Всё не так просто. Здесь возникает неопределённое поведение. И то, что такой код может работать на практике, это просто везение. На самом деле, так писать нельзя. Например, оптимизирующий компилятор, увидев list->first, может удалить проверку if (list). Раз мы выполняли оператор ->, значит предполагается, что указатель не равен nullptr. Если это так, то проверять указатель не нужно.

Я написал целую статью на эту тему: «Разыменовывание нулевого указателя приводит к неопределённому поведению». Там как раз рассматривается аналогичный случай. Прежде чем спорить, прошу внимательно познакомиться с этой статьёй.

Впрочем, рассмотренная ситуация действительно сложна и неочевидна. Я допускаю, что могу быть всё-таки неправ и ошибки здесь нет. Однако, до сих пор мне никто не смог это доказать. Будет интересно услышать комментарии разработчиков GCC, если они обратят внимание на эту статью. Уж они-то точно должны знать, как работает компилятор и следует ли интерпретировать такой код как ошибочный, или нет.

Использование разрушенного массива

static void
dump_hsa_symbol (FILE *f, hsa_symbol *symbol)
{
  const char *name;
  if (symbol->m_name)
    name = symbol->m_name;
  else
  {
    char buf[64];
    sprintf (buf, "__%s_%i", hsa_seg_name (symbol->m_segment),
       symbol->m_name_number);
     name = buf;
  }
  fprintf (f, "align(%u) %s_%s %s",
           hsa_byte_alignment (symbol->m_align),
           hsa_seg_name(symbol->m_segment),
           hsa_type_name(symbol->m_type & ~BRIG_TYPE_ARRAY_MASK),
           name);
  ....
}

Предупреждение анализатора PVS-Studio: V507 Pointer to local array ‘buf’ is stored outside the scope of this array. Such a pointer will become invalid. hsa-dump.c 704

Строка формируется во временном буфере buf. Адрес этого временного буфера сохраняется в переменной name и используется далее в теле функции. Ошибка в том, что после записи буфера в переменную name, сам этот буфер будет уничтожен.

Использовать указатель на разрушенный буфер нельзя. Формально мы имеем дело с неопределённым поведением. На практике этот код может вполне успешно работать. Корректная работа программы — это один из вариантов проявления неопределенного поведения.

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

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

static void
dump_hsa_symbol (FILE *f, hsa_symbol *symbol)
{
  const char *name;
  char buf[64];
  ....
}

Выполнение одинаковых действий, независимо от условия

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

bool
thread_through_all_blocks (bool may_peel_loop_headers)
{
  ....
  /* Case 1, threading from outside to inside the loop
     after we'd already threaded through the header.  */
  if ((*path)[0]->e->dest->loop_father
      != path->last ()->e->src->loop_father)
  {
    delete_jump_thread_path (path);
    e->aux = NULL;
    ei_next (&ei);
  }
  else
  {
    delete_jump_thread_path (path);
    e->aux = NULL;
    ei_next (&ei);
  }
  ....
}

Предупреждение анализатора PVS-Studio: V523 The ‘then’ statement is equivalent to the ‘else’ statement. tree-ssa-threadupdate.c 2596

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

Избыточное выражение вида (A == 1 || A != 2)

static const char *
alter_output_for_subst_insn (rtx insn, int alt)
{
  const char *insn_out, *sp ;
  char *old_out, *new_out, *cp;
  int i, j, new_len;

  insn_out = XTMPL (insn, 3);

  if (alt < 2 || *insn_out == '*' || *insn_out != '@')
    return insn_out;
  ....
}

Предупреждение анализатора PVS-Studio: V590 Consider inspecting this expression. The expression is excessive or contains a misprint. gensupport.c 1640

Нас интересует условие: (alt < 2 || *insn_out == ‘*’ || *insn_out != ‘@’)

Его можно сократить до: (alt < 2 || *insn_out != ‘@’)

Рискну предположить, что оператор != следует заменить на ==. Тогда код примет более осмысленный вид:

if (alt < 2 || *insn_out == '*' || *insn_out == '@')

Обнуление не того указателя

Рассмотрим функцию, занимающуюся освобождением ресурсов:

void
free_original_copy_tables (void)
{
  gcc_assert (original_copy_bb_pool);
  delete bb_copy;
  bb_copy = NULL;
  delete bb_original;
  bb_copy = NULL;
  delete loop_copy;
  loop_copy = NULL;
  delete original_copy_bb_pool;
  original_copy_bb_pool = NULL;
}

Предупреждение анализатора PVS-Studio: V519 The ‘bb_copy’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 1076, 1078. cfg.c 1078

Обратите внимание на эти 4 строчки кода:

delete bb_copy;
bb_copy = NULL;
delete bb_original;
bb_copy = NULL;

Случайно дважды обнуляется указатель bb_copy. Правильный вариант:

delete bb_copy;
bb_copy = NULL;
delete bb_original;
bb_original = NULL;

Assert, который ничего не проверят

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

static void
output_loc_operands (dw_loc_descr_ref loc, int for_eh_or_skip)
{
  unsigned long die_offset
    = get_ref_die_offset (val1->v.val_die_ref.die);
  ....
  gcc_assert (die_offset > 0
        && die_offset <= (loc->dw_loc_opc == DW_OP_call2)
             ? 0xffff
             : 0xffffffff);
  ....
}

Предупреждение анализатора PVS-Studio: V502 Perhaps the ‘?:’ operator works in a different way than it was expected. The ‘?:’ operator has a lower priority than the ‘<=’ operator. dwarf2out.c 2053

Приоритет тернарного оператора ?: ниже, чем у оператора сравнения <=. Это значит, что мы имеем дело с условием вида:

die_offset > 0 &&
  ((die_offset <= (loc->dw_loc_opc == DW_OP_call2)) ?
    0xffff : 0xffffffff);

Таким образом, второй операнд оператора && может принимать значение 0xffff или 0xffffffff. Оба эти значения обозначают истину, поэтому выражение можно упростить до:

(die_offset > 0)

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

gcc_assert (die_offset > 0
      && die_offset <= ((loc->dw_loc_opc == DW_OP_call2)
           ? 0xffff
           : 0xffffffff));

Оператор ?: очень коварен и его лучше не использовать в сложных выражениях. Уж очень легко допустить ошибку. У нас собрано большое количество примеров таких ошибок, найденных анализатором PVS-Studio в различных открытых проектах. Подробнее об операторе ?: я писал в уже упомянутой ранее книге (см. главу N4: Бойтесь оператора ?: и заключайте его в круглые скобки).

Кажется, забыли про «cost»

Структура alg_hash_entry объявлена следующим образом:

struct alg_hash_entry {
  unsigned HOST_WIDE_INT t;
  machine_mode mode;
  enum alg_code alg;
  struct mult_cost cost;
  bool speed;
};

В функции synth_mult программист решил проверить, тот ли это объект, который ему нужен. Для этого ему требуется сравнить поля структуры. Однако, кажется в этом месте допущена ошибка:

static void synth_mult (....)
{
  ....
  struct alg_hash_entry *entry_ptr;
  ....
  if (entry_ptr->t == t
      && entry_ptr->mode == mode
      && entry_ptr->mode == mode
      && entry_ptr->speed == speed
      && entry_ptr->alg != alg_unknown)
  {
  ....
}

Предупреждение анализатора PVS-Studio: V501 There are identical sub-expressions ‘entry_ptr->mode == mode’ to the left and to the right of the ‘&&’ operator. expmed.c 2573

Два раза подряд проверяется mode, но зато нет проверки cost. Возможно, одно из сравнений нужно просто удалить, а возможно, нужно сравнивать cost. Мне сложно судить, но код явно стоит поправить.

Дубликаты присваиваний

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

Случай N1

type_p
find_structure (const char *name, enum typekind kind)
{
  ....
  structures = s;                   // <=
  s->kind = kind;
  s->u.s.tag = name;
  structures = s;                   // <=
  return s;
}

Предупреждение анализатора PVS-Studio: V519 The ‘structures’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 842, 845. gengtype.c 845

Случай N2

static rtx
ix86_expand_sse_pcmpistr (....)
{
  unsigned int i, nargs;
  ....
    case V8DI_FTYPE_V8DI_V8DI_V8DI_INT_UQI:
    case V16SI_FTYPE_V16SI_V16SI_V16SI_INT_UHI:
    case V2DF_FTYPE_V2DF_V2DF_V2DI_INT_UQI:
    case V4SF_FTYPE_V4SF_V4SF_V4SI_INT_UQI:
    case V8SF_FTYPE_V8SF_V8SF_V8SI_INT_UQI:
    case V8SI_FTYPE_V8SI_V8SI_V8SI_INT_UQI:
    case V4DF_FTYPE_V4DF_V4DF_V4DI_INT_UQI:
    case V4DI_FTYPE_V4DI_V4DI_V4DI_INT_UQI:
    case V4SI_FTYPE_V4SI_V4SI_V4SI_INT_UQI:
    case V2DI_FTYPE_V2DI_V2DI_V2DI_INT_UQI:
      nargs = 5;         // <=
      nargs = 5;         // <=
      mask_pos = 1;
      nargs_constant = 1;
      break;
  ....
}

Предупреждение анализатора PVS-Studio: V519 The ‘nargs’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 39951, 39952. i386.c 39952

Случай N3

Последний случай более странный, чем остальные. Возможно, тут есть какая-то ошибка. Переменной steptype значение присваивается 2 или 3 раза. Это подозрительно.

static void
cand_value_at (....)
{
  aff_tree step, delta, nit;
  struct iv *iv = cand->iv;
  tree type = TREE_TYPE (iv->base);
  tree steptype = type;                 // <=
  if (POINTER_TYPE_P (type))
    steptype = sizetype;                // <=
  steptype = unsigned_type_for (type);  // <=
  ....
}

Предупреждение анализатора PVS-Studio: V519 The ‘steptype’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 5173, 5174. tree-ssa-loop-ivopts.c 5174

Заключение

Я рад, что написал эту статью. Теперь мне есть что отвечать на комментарии вида «PVS-Studio не нужен, так как все те же предупреждения выдаёт и GCC». Как видите, PVS-Studio очень мощный инструмент и превосходит по диагностическим возможностям GCC. Я не отрицаю, что в GCC реализованы отличные диагностики. Этот компилятор, при должной настройке, действительно выявляет много проблем в коде. Но PVS-Studio — это специализированный и быстро развивающийся инструмент, а это значит, он всегда будет лучше выявлять ошибки в коде, чем это делают компиляторы.

Приглашаю познакомиться с проверками других известных открытых проектов, посетив этот раздел нашего сайта. А также, тем, кто использует Twitter, последовать за мной @Code_Analysis. Я регулярно публикую ссылки на интересные статьи по программированию на языке C и C++, а также рассказываю о новых достижениях нашего анализатора.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey karpov. Bugs found in GCC with the help of PVS-Studio.

C++, Информационная безопасность, Open source, Разработка под Linux, Блог компании PVS-Studio

---

Рекомендация: подборка платных и бесплатных курсов 3D max — https://katalog-kursov.ru/

Около двух месяцев назад я написал статью о проверке компилятора GCC с помощью анализатора PVS-Studio. Идея статьи была следующая: предупреждения GCC — это хорошо, но недостаточно. Надо использовать специализированные инструменты анализа кода, например, PVS-Studio. В качестве подтверждения я показал ошибки, которые PVS-Studio смог найти в коде GCC. Ряд читателей заметили, что качество кода GCC и его диагностики так себе, в то время как компилятор Clang современен, качественен, свеж и молод. В общем Clang — это ого-го! Что ж, значит пришло время мне проверить с помощью PVS-Studio проект LLVM.

Проверяем LLVM с помощью Linux версии PVS-Studio

Думаю, мало тех, кто не знает, что такое LLVM. Тем не менее, сохраню традицию кратко описывать проект, который был проверен.

LLVM (Low Level Virtual Machine) — универсальная система анализа, трансформации и оптимизации программ, реализующая виртуальную машину с RISC-подобными инструкциями. Может использоваться как оптимизирующий компилятор этого байткода в машинный код для различных архитектур, либо для его интерпретации и JIT-компиляции (для некоторых платформ). В рамках проекта LLVM был разработан фронтенд Clang для языков C, C++ и Objective-C, транслирующий исходные коды в байткод LLVM, и позволяющий использовать LLVM в качестве полноценного компилятора.

Официальный сайт: http://llvm.org/

Проверке подвергалась ревизия 282481. Анализ проводился новой версией PVS-Studio, работающей под Linux. Поскольку PVS-Studio for Linux — это новый продукт, то ниже я расскажу подробнее как выполнялась проверка. Уверен, это покажет, что использовать наш анализатор в Linux совсем не сложно, и вы можете, не откладывая, попробовать проверить собственный проект.

Linux-версия анализатора доступна для скачивания на следующей странице: http://www.viva64.com/ru/pvs-studio-download-linux/

Предыдущие проекты мы проверяли с помощью универсального механизма, который отслеживает запуски компилятора. В этот раз мы воспользуемся для проверки информацией, которую PVS-Studio возьмёт из JSON Compilation Database. Подробности можно почерпнуть из раздела документации «Как запустить PVS-Studio в Linux».

В LLVM 3.9 полностью отказались от autoconf в пользу CMake, и это стало хорошим поводом опробовать в действии поддержку JSON Compilation Database. Что это такое? Это формат, используемый утилитами Clang. В нём хранится список вызовов компилятора в следующем виде:

[
  {
    "directory": "/home/user/llvm/build",
    "command": "/usr/bin/c++ .... file.cc",
    "file": "file.cc"
  },
  ....
]

Для CMake-проектов получить такой файл очень просто — достаточно выполнить генерацию проекта с дополнительной опцией:

cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=On ../llvm

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

make -j8

Теперь всё готово для анализа. Запускается он одной строчкой:

pvs-studio-analyzer analyze -l ~/PVS-Studio.lic -o PVS-Studio.log -j

Для проектов, не использующих CMake, получить compile_commands.json можно с помощью утилиты Bear. Но для сложных сборочных систем, активно использующих переменные окружения или кросс-компиляцию, полученные команды не всегда предоставляют подробную информацию о юните трансляции.

Примечание N1. Как работать с отчетом PVS-Studio в Linux.

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

Результаты проверки

Кстати, это уже не первая проверка LLVM. Статьи, написанные по мотивам предыдущих проверок:

• PVS-Studio vs Clang (2011);
• Статический анализ следует применять регулярно (2012).

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

Всё, лирика закончилась, перейду к самому интересному. Рассмотрим подозрительные места в коде LLVM, на которые указал мне PVS-Studio.

Небитовые поля

В коде имеется вот такое перечисление:

enum Type {
  ST_Unknown, // Type not specified
  ST_Data,
  ST_Debug,
  ST_File,
  ST_Function,
  ST_Other
};

Это, если так можно сказать, «классическое перечисление». Каждому имени в перечислении присваивается целочисленное значение, которое соответствует определенному месту в порядке значений в перечислении:

• ST_Unknown = 0
• ST_Data = 1
• ST_Debug = 2
• ST_File = 3
• ST_Function = 4
• ST_Other = 5

Ещё раз подчеркну, что это просто перечисление, а не набор масок. Если бы эти константы можно было сочетать между собой, то они бы являлись степенью числа 2.

Теперь пришло время взглянуть на код, где это перечисление используется неправильно:

void MachODebugMapParser::loadMainBinarySymbols(....)
{
  ....
  SymbolRef::Type Type = *TypeOrErr;
  if ((Type & SymbolRef::ST_Debug) ||
      (Type & SymbolRef::ST_Unknown))
    continue;
  ....
}

Предупреждение PVS-Studio: V616 The ‘SymbolRef::ST_Unknown’ named constant with the value of 0 is used in the bitwise operation. MachODebugMapParser.cpp 448

Вспомним, что константа ST_Unknown равна нулю. Следовательно, выражение можно сократить:

if (Type & SymbolRef::ST_Debug)

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

if ((Type == SymbolRef::ST_Debug) || (Type == SymbolRef::ST_Unknown))

Чтобы избежать подобных ошибок, думаю, следовало использовать enum class. В этом случае некорректное выражение просто бы не скомпилировалось.

Одноразовые циклы

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

Parser::TPResult Parser::TryParseProtocolQualifiers() {
  assert(Tok.is(tok::less) && "Expected '<' for qualifier list");
  ConsumeToken();
  do {
    if (Tok.isNot(tok::identifier))
      return TPResult::Error;
    ConsumeToken();
    
    if (Tok.is(tok::comma)) {
      ConsumeToken();
      continue;
    }
    
    if (Tok.is(tok::greater)) {
      ConsumeToken();
      return TPResult::Ambiguous;
    }
  } while (false);
  
  return TPResult::Error;
}

Предупреждение PVS-Studio: V696 The ‘continue’ operator will terminate ‘do {… } while (FALSE)’ loop because the condition is always false. Check lines: 1642, 1649. ParseTentative.cpp 1642

Разработчики LLVM, конечно, сразу смогут понять, есть здесь ошибка или нет. Мне же придётся поиграть в детектива. Рассматривая этот код, я рассуждал следующим образом. Функция должна прочитать открывающуюся скобку ‘<‘, затем она в цикле читает идентификаторы и запятые. Если запятой нет, то ожидается закрывающаяся скобка. Если что-то пошло не так, то функция возвращает код ошибки. Я думаю, что был задуман следующий алгоритм работы функции (псевдокод):

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

Беда в том, что цикл пытаются возобновить с помощью оператора continue. Он передает управление вовсе не на начало тела цикла, а на проверку условия продолжения цикла. А условие у всегда false. В результате цикл сразу завершается и алгоритм выглядит следующим образом:

• Начало цикла:
• Прочитать идентификатор. Если это не идентификатор, то вернуть статус ошибки.
• Прочитать запятую. Если это запятая, завершить цикл и вернуть из функции статус ошибки.
• Ага, у нас не запятая. Если это закрывающаяся скобка, то все хорошо, выходим из функции.
• Иначе вернем статус ошибки.

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

Рассмотрим теперь другой случай, когда выполняется не более, чем 1 итерация цикла:

static bool checkMachOAndArchFlags(....) {
  ....
  unsigned i;
  for (i = 0; i < ArchFlags.size(); ++i) {
    if (ArchFlags[i] == T.getArchName())
      ArchFound = true;
    break;
  }
  ....
}

Предупреждение PVS-Studio: V612 An unconditional ‘break’ within a loop. MachODump.cpp 1206

Обратите внимание на оператор break. Он прервёт цикл сразу после первой итерации. Мне кажется, оператор break должен относиться к условию, и тогда корректный код станет выглядеть так:

for (i = 0; i < ArchFlags.size(); ++i) {
  if (ArchFlags[i] == T.getArchName())
  {
    ArchFound = true;
    break;
  }
}

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

• V612 An unconditional ‘return’ within a loop. R600OptimizeVectorRegisters.cpp 54
• V612 An unconditional ‘break’ within a loop. llvm-size.cpp 525

Перепутан оператор || и &&

static bool containsNoDependence(CharMatrix &DepMatrix,
                                 unsigned Row,
                                 unsigned Column) {
  for (unsigned i = 0; i < Column; ++i) {
    if (DepMatrix[Row][i] != '=' || DepMatrix[Row][i] != 'S' ||
        DepMatrix[Row][i] != 'I')
      return false;
  }
  return true;
}

Предупреждение PVS-Studio: V547 Expression is always true. Probably the ‘&&’ operator should be used here. LoopInterchange.cpp 208

Выражение не имеет смысла. Я упрощу код, чтобы выделить суть ошибки:

if (X != '=' || X != 'S' || X != 'I')

Переменная X всегда будет чему-то не равна. В результате условие всегда истинно. Скорее всего, вместо операторов «||» следовало использовать операторы «&&», тогда выражение приобретает смысл.

Функция возвращает ссылку на локальный объект

SingleLinkedListIterator<T> &operator++(int) {
  SingleLinkedListIterator res = *this;
  ++*this;
  return res;
}

Предупреждение PVS-Studio: V558 Function returns the reference to temporary local object: res. LiveInterval.h 679

Функция представляет традиционную реализацию постфиксного инкремента:

• Текущее состояние сохраняется во временном объекте;
• Изменяется текущее состояние объекта;
• Возвращается старое состояние объекта.

Ошибка в том, что функция возвращает ссылку. Эта ссылка не валидна, так как при выходе из функции временный объект res будет разрушен.

Чтобы исправить ситуацию, нужно возвращать значение, а не ссылку:

SingleLinkedListIterator<T> operator++(int) { .... }

Повторное присваивание

Приведу функцию целиком, чтобы никто не подумал, что перед повторным присваиванием переменная ZeroDirective как-то используется.

HexagonMCAsmInfo::HexagonMCAsmInfo(const Triple &TT) {
  Data16bitsDirective = "t.halft";
  Data32bitsDirective = "t.wordt";
  Data64bitsDirective = nullptr;
  ZeroDirective = "t.skipt";                            // <=
  CommentString = "//";

  LCOMMDirectiveAlignmentType = LCOMM::ByteAlignment;
  InlineAsmStart = "# InlineAsm Start";
  InlineAsmEnd = "# InlineAsm End";
  ZeroDirective = "t.spacet";                           // <=
  AscizDirective = "t.stringt";

  SupportsDebugInformation = true;
  MinInstAlignment = 4;
  UsesELFSectionDirectiveForBSS  = true;
  ExceptionsType = ExceptionHandling::DwarfCFI;
}

Предупреждение PVS-Studio: V519 The ‘ZeroDirective’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 25, 31. HexagonMCAsmInfo.cpp 31

Переменная ZeroDirective представляет собой простой указатель типа const char *. В начале он указывает на строку «t.skipt», а чуть ниже ему назначают адрес строки «t.spacet». Это странно и не имеет смысла. Высока вероятность, что одно из присваиваний должно изменять совсем другую переменную.

Рассмотрим ещё один случай повторного присваивания.

template <class ELFT>
void GNUStyle<ELFT>::printFileHeaders(const ELFO *Obj) {
  ....
  Str = printEnum(e->e_ident[ELF::EI_OSABI], makeArrayRef(ElfOSABI));
  printFields(OS, "OS/ABI:", Str);
  Str = "0x" + to_hexString(e->e_version);                  // <=
  Str = to_hexString(e->e_ident[ELF::EI_ABIVERSION]);       // <=
  printFields(OS, "ABI Version:", Str);
  Str = printEnum(e->e_type, makeArrayRef(ElfObjectFileType));
  printFields(OS, "Type:", Str);
  ....
}

Предупреждение PVS-Studio: V519 The ‘Str’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 2407, 2408. ELFDumper.cpp 2408

По всей видимости мы имеем дело с опечаткой. Вместо повторного присваивания надо было конкатенировать две строки с помощью оператора +=. Тогда корректный код должен выглядеть так:

Str = "0x" + to_hexString(e->e_version);
Str += to_hexString(e->e_ident[ELF::EI_ABIVERSION]);

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

• V519 The variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 55, 57. coff2yaml.cpp 57
• V519 The ‘O’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 394, 395. llvm-pdbdump.cpp 395
• V519 The ‘servAddr.sin_family’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 63, 64. server.cpp 64

Подозрительная работа с умными указателями

Expected<std::unique_ptr<PDBFile>>
PDBFileBuilder::build(
  std::unique_ptr<msf::WritableStream> PdbFileBuffer)
{
  ....
  auto File = llvm::make_unique<PDBFile>(
    std::move(PdbFileBuffer), Allocator);

  File->ContainerLayout = *ExpectedLayout;

  if (Info) {
    auto ExpectedInfo = Info->build(*File, *PdbFileBuffer);
  ....
}

Предупреждение PVS-Studio: V522 Dereferencing of the null pointer ‘PdbFileBuffer’ might take place. PDBFileBuilder.cpp 106

Код мне не понятен, так как, например, я не изучал, что такое llvm::make_unique и как вообще всё это работает. Тем не менее, анализатор и меня настораживает то, что на первый взгляд владение объектом от умного указателя PdbFileBuffer переходит к File. После чего происходит разыменование умного указателя PdbFileBuffer, который, по идее, в этот момент уже содержит внутри себя nullptr. То есть настораживает следующее:

.... llvm::make_unique<PDBFile>(::move(PdbFileBuffer), Allocator);
....
.... Info->build(*File, *PdbFileBuffer);

Если это ошибка, то её следует поправить ещё в 3 местах в этом же файле:

• V522 Dereferencing of the null pointer ‘PdbFileBuffer’ might take place. PDBFileBuilder.cpp 113
• V522 Dereferencing of the null pointer ‘PdbFileBuffer’ might take place. PDBFileBuilder.cpp 120
• V522 Dereferencing of the null pointer ‘PdbFileBuffer’ might take place. PDBFileBuilder.cpp 127

Опечатка в условии

static bool areExclusiveRanges(BinaryOperatorKind OpcodeLHS,
                               const APSInt &ValueLHS,
                               BinaryOperatorKind OpcodeRHS,
                               const APSInt &ValueRHS) {
  ....
  // Handle cases where the constants are different.
  if ((OpcodeLHS == BO_EQ ||
       OpcodeLHS == BO_LE ||                 // <=
       OpcodeLHS == BO_LE)                   // <=
      &&
      (OpcodeRHS == BO_EQ ||
       OpcodeRHS == BO_GT ||
       OpcodeRHS == BO_GE))
    return true;
  ....
}

Предупреждение PVS-Studio: V501 There are identical sub-expressions ‘OpcodeLHS == BO_LE’ to the left and to the right of the ‘||’ operator. RedundantExpressionCheck.cpp 174

Это классическая опечатка. Переменная OpcodeLHS дважды сравнивается с константой BO_LE. Как мне кажется, одну из констант BO_LE следует заменить на BO_LT. Как видите имена констант схожи между собой и несложно спутать.

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

std::pair<Function *, Function *>
llvm::createSanitizerCtorAndInitFunctions(
    ....
    ArrayRef<Type *> InitArgTypes, ArrayRef<Value *> InitArgs,
    ....)
{
  assert(!InitName.empty() && "Expected init function name");
  assert(InitArgTypes.size() == InitArgTypes.size() &&
    "Sanitizer's init function expects "
    "different number of arguments");
  ....

}

Предупреждение PVS-Studio: V501 There are identical sub-expressions ‘InitArgTypes.size()’ to the left and to the right of the ‘==’ operator. ModuleUtils.cpp 107

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

Нам важно то, что в функции createSanitizerCtorAndInitFunctions() используются макросы assert() для проверки корректности входных значений. Вот только из-за опечатки второй assert() бесполезен.

К счастью, нам помогает статический анализатор, который замечает, что размер массива сравнивается сам с собой. В результате мы можем исправить проверку, а правильное условие в assert() со временем может помочь предотвратить какую-то другую ошибку.

По всей видимости, в условии должны сравниваться размеры массивов InitArgTypes и InitArgs:

assert(InitArgTypes.size() == InitArgs.size() &&
  "Sanitizer's init function expects "
  "different number of arguments");

Путаница между release() и reset()

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

std::unique_ptr<DiagnosticConsumer> takeClient()
  { return std::move(Owner); }

VerifyDiagnosticConsumer::~VerifyDiagnosticConsumer() {
  ....
  SrcManager = nullptr;
  CheckDiagnostics();
  Diags.takeClient().release();
}

Предупреждение PVS-Studio: V530 The return value of function ‘release’ is required to be utilized. VerifyDiagnosticConsumer.cpp 46

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

Избыточные условия

bool ARMDAGToDAGISel::tryT1IndexedLoad(SDNode *N) {
  LoadSDNode *LD = cast<LoadSDNode>(N);
  EVT LoadedVT = LD->getMemoryVT();
  ISD::MemIndexedMode AM = LD->getAddressingMode();
  if (AM == ISD::UNINDEXED ||
      LD->getExtensionType() != ISD::NON_EXTLOAD ||
      AM != ISD::POST_INC ||
      LoadedVT.getSimpleVT().SimpleTy != MVT::i32)
    return false;
  ....
}

Предупреждение PVS-Studio: V590 Consider inspecting this expression. The expression is excessive or contains a misprint. ARMISelDAGToDAG.cpp 1565

Условие длинное, поэтому я выделю самое главное:

AM == ISD::UNINDEXED || AM != ISD::POST_INC

Это условие избыточно и его можно упросить до:

AM != ISD::POST_INC

Таким образом, здесь мы наблюдаем просто избыточность в условии или какую-то ошибку. Возможно, избыточность указывает нам на то, что хотели написать какое-то другое условие. Я не берусь судить насколько опасно это место, но проверить его стоит. Заодно хочу обратить внимание разработчиков ещё на 2 предупреждения анализатора:

• V590 Consider inspecting this expression. The expression is excessive or contains a misprint. ASTReader.cpp 4178
• V590 Consider inspecting this expression. The expression is excessive or contains a misprint. BracesAroundStatementsCheck.cpp 46

Мои любимые предупреждения V595

Указатели в C и C++ — бесконечная головная боль программистов. Проверяешь их на ноль, проверяешь, а где-то — раз! — и опять разыменование нулевого указателя. Диагностика V595 выявляет ситуации, когда проверка указателя на равенство нулю происходит слишком поздно. До этой проверки указатель уже успевают использовать. Это одна из самых типовых ошибок, находимых нами в коде разнообразнейших приложений (доказательство). Впрочем, в защиту C/C++ скажу, что в C# ситуация не намного лучше. От того, что указатели в C# назвали ссылками, такие ошибки не пропали (доказательство).

Вернемся к коду LLVM и рассмотрим простой вариант ошибки:

bool PPCDarwinAsmPrinter::doFinalization(Module &M) {
  ....
  MachineModuleInfoMachO &MMIMacho =
      MMI->getObjFileInfo<MachineModuleInfoMachO>();

  if (MAI->doesSupportExceptionHandling() && MMI) {
  ....
}

Предупреждение PVS-Studio: V595 The ‘MMI’ pointer was utilized before it was verified against nullptr. Check lines: 1357, 1359. PPCAsmPrinter.cpp 1357

Случай простой и всё сразу видно. Проверка (… && MMI) говорит нам, что указатель MMI может быть равен нулю. Если это так, поток выполнения программы не доберётся до этой проверки. Он будет прерван раньше из-за разыменования нулевого указателя.

Рассмотрим ещё один фрагмент кода:

void Sema::CodeCompleteObjCProtocolReferences(
  ArrayRef<IdentifierLocPair> Protocols)
{
  ResultBuilder 
    Results(*this, CodeCompleter->getAllocator(),
            CodeCompleter->getCodeCompletionTUInfo(),
            CodeCompletionContext::CCC_ObjCProtocolName);
  
  if (CodeCompleter && CodeCompleter->includeGlobals()) {
    Results.EnterNewScope();
  ....
}

Предупреждение PVS-Studio: V595 The ‘CodeCompleter’ pointer was utilized before it was verified against nullptr. Check lines: 5952, 5955. SemaCodeComplete.cpp 5952

Указатель CodeCompleter сначала разыменовывается, а уже ниже располагается проверка на равенства этого указателя нулю. Такой же код ещё трижды встречается в этом же файле:

• V595 The ‘CodeCompleter’ pointer was utilized before it was verified against nullptr. Check lines: 5980, 5983. SemaCodeComplete.cpp 5980
• V595 The ‘CodeCompleter’ pointer was utilized before it was verified against nullptr. Check lines: 7455, 7458. SemaCodeComplete.cpp 7455
• V595 The ‘CodeCompleter’ pointer was utilized before it was verified against nullptr. Check lines: 7483, 7486. SemaCodeComplete.cpp 7483

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

• V595 The ‘Receiver’ pointer was utilized before it was verified against nullptr. Check lines: 2543, 2560. SemaExprObjC.cpp 2543
• V595 The ‘S’ pointer was utilized before it was verified against nullptr. Check lines: 1267, 1296. SemaLookup.cpp 1267
• V595 The ‘TargetDecl’ pointer was utilized before it was verified against nullptr. Check lines: 4037, 4046. CGExpr.cpp 4037
• V595 The ‘CurrentToken’ pointer was utilized before it was verified against nullptr. Check lines: 705, 708. TokenAnnotator.cpp 705
• V595 The ‘FT’ pointer was utilized before it was verified against nullptr. Check lines: 540, 554. Expr.cpp 540
• V595 The ‘II’ pointer was utilized before it was verified against nullptr. Check lines: 448, 450. IdentifierTable.cpp 448
• V595 The ‘MF’ pointer was utilized before it was verified against nullptr. Check lines: 268, 274. X86RegisterInfo.cpp 268
• V595 The ‘External’ pointer was utilized before it was verified against nullptr. Check lines: 40, 45. HeaderSearch.cpp 40
• V595 The ‘TLI’ pointer was utilized before it was verified against nullptr. Check lines: 4239, 4244. CodeGenPrepare.cpp 4239
• V595 The ‘SU->getNode()’ pointer was utilized before it was verified against nullptr. Check lines: 292, 297. ResourcePriorityQueue.cpp 292
• V595 The ‘BO0’ pointer was utilized before it was verified against nullptr. Check lines: 2835, 2861. InstCombineCompares.cpp 2835
• V595 The ‘Ret’ pointer was utilized before it was verified against nullptr. Check lines: 2090, 2092. ObjCARCOpts.cpp 2090

Странный код

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

static bool print_class_ro64_t(....) {
  ....
  const char *r;
  uint32_t offset, xoffset, left;
  ....
  r = get_pointer_64(p, offset, left, S, info);
  if (r == nullptr || left < sizeof(struct class_ro64_t))
    return false;
  memset(&cro, '', sizeof(struct class_ro64_t));
  if (left < sizeof(struct class_ro64_t)) {
    memcpy(&cro, r, left);
    outs() << "   (class_ro_t entends past the .......)n";
  } else
    memcpy(&cro, r, sizeof(struct class_ro64_t));
  ....
}

Предупреждение PVS-Studio: V649 There are two ‘if’ statements with identical conditional expressions. The first ‘if’ statement contains function return. This means that the second ‘if’ statement is senseless. Check lines: 4410, 4413. MachODump.cpp 4413

Обратите внимание на проверку:

if (.... || left < sizeof(struct class_ro64_t))
  return false;

Если значение, содержащееся в переменной left, меньше размера класса, то произойдёт выход из функции. Получается, что вот этот выбор поведения не имеет смысла:

if (left < sizeof(struct class_ro64_t)) {
  memcpy(&cro, r, left);
  outs() << "   (class_ro_t entends past the .......)n";
} else
  memcpy(&cro, r, sizeof(struct class_ro64_t));

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

Заодно следует проверить вот это место:

• V649 There are two ‘if’ statements with identical conditional expressions. The first ‘if’ statement contains function return. This means that the second ‘if’ statement is senseless. Check lines: 4612, 4615. MachODump.cpp 4615

Разная мелочь

Внутри шаблонного класса RPC объявлен класс SequenceNumberManager. В нём есть вот такой перемещающий оператор присваивания (move assignment operator):

SequenceNumberManager &operator=(SequenceNumberManager &&Other) {
  NextSequenceNumber = std::move(Other.NextSequenceNumber);
  FreeSequenceNumbers = std::move(Other.FreeSequenceNumbers);
}

Предупреждение PVS-Studio: V591 Non-void function should return a value. RPCUtils.h 719

Как видите в конце забыли написать return:

return *this;

На самом деле в этом нет ничего страшного. Компиляторы, как правило, никак не работают с телами функций шаблонных классов, если эти функции не используются. Здесь, видимо, именно такой случай. Хотя я не проверял, но я уверен: если вызвать такой оператор перемещения, компилятор выдаст ошибку компиляции или громкий warning. Так что ничего страшного здесь нет, но решил указать на эту недоработку.

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

LLVMDisasmContextRef LLVMCreateDisasmCPUFeatures(....) {
  ....
  // Set up the MCContext for creating symbols and MCExpr's.
  MCContext *Ctx = new MCContext(MAI, MRI, nullptr);
  if (!Ctx)
    return nullptr;
  ....
}

Предупреждение PVS-Studio: V668 There is no sense in testing the ‘Ctx’ pointer against null, as the memory was allocated using the ‘new’ operator. The exception will be generated in the case of memory allocation error. Disassembler.cpp 76

И ещё 2 предупреждения:

• V668 There is no sense in testing the ‘DC’ pointer against null, as the memory was allocated using the ‘new’ operator. The exception will be generated in the case of memory allocation error. Disassembler.cpp 103
• V668 There is no sense in testing the ‘JITCodeEntry’ pointer against null, as the memory was allocated using the ‘new’ operator. The exception will be generated in the case of memory allocation error. GDBRegistrationListener.cpp 180

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

Заключение

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

Ещё важно отметить, что основной эффект применения методологии статического анализа достигается при регулярном использовании статических анализаторов кода. Многие ошибки будут выявлены на самом раннем этапе, и их не потребуется отлаживать или упрашивать пользователя подробно описать последовательность действий, приводящих к падению программы. Здесь полная аналогия с предупреждениями компилятора (собственно, это те же самые предупреждения, но более интеллектуальные). Вы ведь смотрите предупреждения компилятора постоянно, а не раз в месяц?!

Приглашаем скачать и попробовать PVS-Studio на коде своего проекта.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey karpov. Finding bugs in the code of LLVM project with the help of PVS-Studio.

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

• Зачем нужен компилятор?
• Как работает компилятор?
• На чем написан компилятор?
• Какие бывают компиляторы?
• Какие ошибки может определить компилятор?
• Выводы и рекомендации
• Частые вопросы
• Дополнительные материалы

Зачем нужен компилятор?

Процессор — самая важная часть компьютера. Он обрабатывает информацию, выполняет команды пользователя и следит за работой всех подключенных устройств. Но процессор может разобрать только машинный код — набор 0 и 1, которые записаны в определённом порядке.

Почему именно 0 и 1? В процессор поступают электрические сигналы. Сильный сигнал обозначается цифрой 1, а слабый — 0. Набор таких цифр обозначает какую-то команду. Процессор ее распознает и выполняет.

Программы для первых компьютеров выглядели как огромные наборы 0 и 1. Чтобы записать такую программу, инженеры пользовались гибкими картонными карточками — перфокартами. Цифры на перфокарте записывались поочередно, в несколько строк. Чтобы записать 1, программист делал отверстие в карте. Места без отверстия обозначали 0.

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

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

Как работает компилятор?

Преобразование программного кода в машинный называется компиляцией. Компиляция только преобразует код. Она не запускает его на исполнение. В этот момент он «статически» (то есть без запуска) транслируется в машинный код. Это сложный процесс, в котором сначала текст программы разбирается на части и анализируется, а затем генерируется код, понятный процессору.

Разберём этапы компиляции на примере вычисления периметра прямоугольника:

#include <iostream>

int main()
{
    double a=2.5, b=5, P;
    P = 2 * (a + b);
    printf("Width of the rectangle - %4.1f", a);// => Width of the rectangle - 2.5
    printf("nLength of the rectangle - %4.1f", b);// => Length of the rectangle - 5.0
    printf("nPerimeter of the rectangle is %4.1f", P);// => Perimeter of the rectangle is 15.0
    return 0;
}

После запуска программы компилятору нужно определить, какие команды в ней записаны. Сначала компилятор разделяет программу на слова и знаки — токены, и записывает их в список. Такой процесс называется лексическим анализом. Его главная задача — получить токены.

# include <iostream> int main ( ) { double a = 2.5 , b = 5 , P ;  P = 2 * ( a + b ) ; printf ( " Width of the rectangle - % 4.1 f " , a ) ; printf ( "  n Length of the rectangle - % 4.1 f " , b ) ; printf ( "  n Perimeter of the rectangle is % 4.1 f " ,   P ) ; return 0 ; }

Затем компилятор читает список и ищет токен-операторы. Это могут быть оператор присваивания(=), арифметические операторы(+,-,*,/), оператор вывода(printf()) и другие операторы языка программирования. Такие операторы работают с числами, текстом и переменными.

Компилятор должен понять, какие токены в списке связаны с токен-оператором. Чтобы сделать это правильно, для каждого оператора строится специальная структура — логическое дерево или дерево разбора.

Так операция P = 2*(a + b) будет преобразована в логическое дерево:

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

• Взять переменную a, взять переменную b, сложить их
• Взять результат сложения, взять число 2 и найти их произведение
• Результат произведения присвоить (записать) в переменную P

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

10111011 00010001 00000001 10111001 00001101 00000000 10110100 00001110 10001010 00000111 01000011 11001101 00010000 11100010 11111001 11001101 00100000 01001000 01100101 01101100 01101100 01101111 00101100 00100000 01010111 01101111 01110010 01101100 01100100 00100001

На чем написан компилятор?

В 1950-е годы группа разработчиков IBM под руководством Джона Бэкуса разработала первый высокоуровневый язык программирования Fortran, который позволил писать программы на понятном человеку языке. Помимо языка, инженеры работали и над компилятором. Он представлял собой программу с набором исполняемых команд, которая могла компилировать другие программы на Fortran, в том числе и улучшенную версию себя.

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

Какие бывают компиляторы?

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

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

Если программа будет работать на нескольких операционных системах, то нужен кросс-компилятор — компилятор, который преобразует универсальный машинный код. Например, GNU Compiler Collection(сокращенно GCC) поддерживает C++, Objective-C, Java, Фортран, Ada, Go и поддерживает разную архитектуру процессоров.

Начинающие программисты даже не знают о наличии компилятора на компьютере. Они пишут программы в интегрированной среде разработки, в которую встроен компилятор, а иногда и не один. В этом случае, выбор компилятора делает среда, а не программист. Например, MS Visual Studio поддерживает компиляторы для операционных систем Windows, Linux, Android. Выбирая тип проекта, Visual Studio определяет процессор и операционную систему компьютера, и после этого выбирает подходящий компилятор.

Какие ошибки может определить компилятор?

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

• ошибки объявления переменных или отсутствие их начальных значений
• ошибки несоответствия типов
• ошибки неправильной записи операторов и функций

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

Выводы и рекомендации

Компилятор — переводчик между программистом и процессором. Он преобразует текст программы в машинный код, определяет ряд ошибок в программе и оптимизирует ее работу.
Выбирая, где компилировать программу, важно помнить о том, что машинный код для процессоров и операционных систем будет разным, и подобрать правильный компилятор.
Чем точнее компилятор определит команды, тем корректнее и быстрее будет работать программа. Для этого следуйте простым рекомендациям:

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

Частые вопросы

Чем компилятор отличается от интерпретатора?

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

Дополнительные материалы

• Компилятор
• ARM против x86: В чем разница между двумя архитектурами процессоров?

• D.1.Сообщения об ошибках компилятора.
  • D.1.1. Сообщения о фатальных ошибках.
  • D.1.2. Сообщения об ошибках компилятора.
  • D.1.3. Предупреждающие сообщения.
  • D.1.4. Ограничения компилятора.
• D.2.Сообщения об ошибках в командной строке.
  • D.2.1. Неисправимые ошибки командной строки.
  • D.2.2. Сообщения об ошибках командной строки.
  • D.2.3. Предупреждающие сообщения командной строки.
    • D.3. Сообщения об ошибках периода выполнения.
  • D.3.1. Исключительные ситуации операций с плавающей точкой.
  • D.3.1. Сообщения об ошибках периода выполнения.
  • D.3.3. Ограничения периода выполнения.
• D.4. Сообщения об ошибках компановщика.
• D.5.Сообщения об ошибках утилиты LIB.
• D.6. Сообщения об ошибках утилиты MAKE.

В данном Приложении приводится список сообщений об ошибках, на которые вы можете натолкнуться в процессе разработки программ, и, кроме того, дает краткое описание действий, которые вам следует предпринять для исправления ошибок. Следующий список покащывает вам, где искать ошибочные сообщения различных компонентов компилятора Microsoft Quick-C:

Компонент                         Раздел

Компилятор Microsoft Quick-C      Раздел D.1, "Сообщения об ошибках
                                  компилятора.
Командная строка, используемая    Раздел D.2, "Сообщение об ошибках
для вызова компилятора Quick-C    командной строки".
Библиотеки исполняющей системы    Раздел D.3, "Сообщения об ошибках
Microsoft C и другие ситуации     периода выполнения".
периода выполнения.
Оверлейный компановщик Microsoft, Раздел D.4, "Сообщения об ошибках
утилита LINK.                     компановщика".
Диспетчер библиотек фирмы         Раздел D.5, "Сообщения об ошибках
Microsoft-утилита LIB             утилиты LIB".
Утилита поддержки разработки      Раздел D.6, "Сообщения об ошибках
программ MAKE                     утилиты MAKE".

Обратите внимание, что все ошибочные сообщения компилятора, командной строки, периода выполнения приведены в данном приложении в алфавитном порядке.

В Разделе D.1.4 вы найдете информацию об ограничениях компилятора, а в Разделе D.3.3-ограничения периода выполнения.

D.1.Сообщения об ошибках компилятора.

Сообщения об ошибках, Полученные при сбоях СИ-компилятора, делятся на три категории:

1.Сообщения о фатальных ошибках.

2.Сообщения об ошибках компиляции.

3.Предупреждающие сообщения.

Сообщения каждой категории даны ниже в пронумерованном порядке, с кратким объяснением каждой ошибки. Чтобы найти требуемое сообщение, сначала определите категорию сообщения, затем найдите соответствующий номер ошибки. Каждое сообщение, сгенерированное в среде Quick-C, появляется в окне ошибок; курсор устанавливается на строке, вызвавшей ошибку (подробности в Разделе 7.3.4). Каждое сообщение об ошибке, сгенерированное во время компиляции с помощью команды QCL, содержит имя файла и номер строки, вызвавшей ошибку.

Сообщения о фатальных ошибках.

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

имя файла(строка): fatal error C1xxx: текст сообщения После того, как компилятор высветит сообщение о фатальной ошибке, он завершит выполнения без создания объектного файла и какой-либо проверки на последующие ошибки.

Сообщения об ошибках компилятора.

Сообщения об ошибках компилятора индицируют реальные программные ошибки. Данные сообщения выводятся в следующем формате:

имя файла(строка):error C2xxx:текст сообщения

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

Предупреждающие сообщения.

Предупреждающие сообщения носят только информативный характер; они не прерывают процесс компиляции или компановки. Данные сообщения появляются в следующем формате:

имя файла(строка): warning C4xxx: текст сообщения

Вы можете использовать опцию /W для управления уровнем сообщений, генерируемых компилятором. Данная опция описана в Разделе 9.3.1.

D.1.1. Сообщения о фатальных ошибках.

Следующие сообщения идентифицируют фатальные ошибки. Компилятор не может исправить фатальную ошибку; он прекращает работу после распечатки сообщения об ошибке.

Номер Сообщение о фатальной ошибке C1000 "Неизвестная фатальная ошибка, Свяжитесь с Техническим сервисом фирмы Microsoft". Компилятор обнаружил неизвестную ошибку. Пожалуйста, сообщите фирме Microsoft Corporation условия возникновения данной ошиб- ки посредством специальной формы "Product Assistan Request", на обложке данного руководства. C1001 "Внутренняя ошибка компилятора, свяжитесь с Техническим серви- сом фирмы Microsoft". Компилятор обнаружил внутреннее несоответствие. Пожалуйста, со- общите условия возникновения данной ошибке с помощью бланка "Product Assistance Request" на обложке данного руководства. Пожалуйста, включите в ваше сообщение имя файла и номер стро- ки, вызвавшей ошибку; обратите внимание, что "имя файла" отно- носится к внутреннему файлу компилятора, а не к вашему исход- ному файлу. C1002 "Выход за пределы динамической области". Компилятор вышел за пределы динамическогй области памяти. Дан- ная ситуация обычно означает, что ваша программа имеет слишком много символических имен и/или комплексных выражений. Чтобы из- бавиться от данной проблемы, разделите файл на несколько мень- ших исходных файлов, либо разбейте выражения на меньшие подвы- ражения. C1003 "Счетчик ошибок превысил n; компиляция остановлена". Ошибок в программе слишком много, либо они слишком серьезны, чтобы возможно было восстановление, компилятор должен прервать выполнение. C1004 "Неожиданный конец файла (EOF). Данное сообщение появляется, если у вас не достаточно памяти на стандартном дисковом устройстве, чтобы компилятор создал требу- емые временные файлы. Требуемое пространство примерно в 2 раза больше размера исходного файла. Данное сообщение может быть также сгенерировано, если комментарий не имеет закрывающего ограничителя (*/), либо если директиве #if не хватает закры- вающей директивы #endif. C1005 "Строка слишком велика для буфера". Строка в промежуточном файле компилятора переполняет буфер. C1006 "Ошибка записи в промежуточный файл компилятора". Компилятор не может создать промежуточные файлы, используемые в процессе компиляции. К данной ошибке обычно приводят следую- щие ситуации: 1.Слишком мало файлов в строке files = number файла CONFIG.SYS (компилятор требует чтобы число number было не меньше 15). 2.Не хватает памяти на устройстве, содержащем промежуточные файлы компилятора. C1007 "Нераспознанный флаг 'string' в 'option'" string-в опции командной строки option не является корректной опцией. C1009 "Ограничения компилятора, возможно рекурсивно определенное мак- роопределение". Расширение макрокоманды превышает размеры доступной памяти. Проверьте, не было ли рекурсивно-определенных макрокоманд, либо не слишком велик расширяемый текст. C1010 "Ограничения компилятора: макро-расширение слишком большое". Расширение макрокоманды превышает доступную память. C1012 "Неверное вложение скобок-пропущенный 'character' (символ)". Несоответствие скобок в директиве препроцессора; 'character'- -это либо левая, либо правая скобка. C1013 "Невозможно открыть исходный файл 'filename'". Данный файл 'filename' либо не существует, либо не может быть открыт, либо не найден. Удостоверьтесь, что параметры установ- ки среды корректны, и что для файла задано корректное имя марш- рута. C1014 "Слишком много включаемых файлов". Вложение директив #include превышает 10-уровневый предел. C1015 "Невозможно открыть включаемый файл 'filename'". Данный файл либо не существует, либо не может быть открыт, либо не найден. Удостоверьтесь, что параметры неазначений среды за- даны корректно, и что вы определили корректное имя маршрута для данного файла. C1016 "Директиве #if [n]def требуется идертификатор". С директивами #ifdef и #ifndef вы обязательно должны употреб- лять идентификатор. C1017 "Неверное выражение целой константы". Выражение в директиве #if должно вычисляться в константу. C1018 "Неожиданная директива '#elif'". Появление директивы #elif разрешено только внутри директив #if, #ifdef, или #ifdef. C1019 "Неожиданная директива '#else'". Появление директивы #else возможно только внутри директив #if, #ifdef, или #ifndef. C1020 "Неожиданная директива '#endif'" Директива #endif появилась без соответствующей директивы #if, #ifdif, или #ifndef. C1021 "Неверная команда препроцессора 'string'" Символы, следующие за знаком (#) формируют неверную директиву препроцессора. C1022 "Ожидается директива '#endif'". Директива #if, #ifdef или #ifndef не заканчивается директивой #endif. C1026 "Переполнение стэка, пожалуйста, упростите вашу программу." Ваша программа не может быть далее обработана, поскольку па- мять, требуемая для "разбора" программы переполняет стэк ком- пилятора. Чтобы разрешить данную проблему, упростите вашу программу. C1027 "Ограничения компилятора: вложение структур/смесей". Определения структур и смесей вложены более 10 раз. C1028 "Сегмент segment занимает более 64К" В данном сегменте размещены более 64 "дальних" данных. Один мо- дуль может иметь не более 64К "дальних" данных. Чтобы разрешить данную проблему, либо разбейте объяснения на отдельные модули, сократите общий объем используемых данных, либо откомпилируйте вашу программу с помощью Оптимизирующего компилятора Microsoft-C. C1032 "Невозможно открыть файл, содержащий объектный листинг 'filename'". Имеет силу одно из следующих утверждений, касающихся имени фай- ла или имени маршрута: 1.Данное имя не верно. 2.Файл с данным именем не может быть открыт из-за нехватки памяти. 3.Уже существует файл с данным именем и атрибутом "только-чте- ние". C1033 "Невозможно открыть выходной файл на языке ассемблер 'filename'". Одно из условий, рассмотренных в описании ошибки с кодом C1032, привело к невозможности открыть данный файл. C1034 "Невозможно открыть исходный файл 'filename'". Одно из условий, рассмотренных в описании ошибки с кодом C1032, привело к невозможности открыть данный файл. C1035 "Выражение является слишком сложным, пожалуйста упростите". Компилятор не смог сгенерировать код для сложного выражения. Чтобы разрешить данную проблему, разбейте выражение на более простые подвыражения и повторите компиляцию. C1036 "Невозможно открыть файл, содержащий исходный листинг 'filename'". Одно из условий, рассмотренных в описании ошибки с кодом C1032, привело к невозможности открыть данный файл. C1037 "Невозможно открыть объектный файл 'filename'". Одно из условий, рассмотренных в описании ошибки с кодом C1032, привело к невозможности открыть данный файл. C1039 "Невосстанавливаемое переполнение динамической области в треть- ем проходе компилятора": В третьем оптимизирующем проходе компилятор переполнил динами- ческую область и прекратил работу. Попытайтесь повторить компиляцию с включенной опцией Optimiza- tions (в среде программирования Quick-C), либо с опцией /Od (в командной строке QCL), либо попытайтесь отделить функцию, со- держащую строку, вызвавшую ошибку. C1040 "Неожиданный EOF в исходном файле 'filename'". В процессе создания листинга исходного файла, либо исходного/ объектного файла компилятор обнаружил неожиданный конец файла. Данная ошибка произошла, вероятно, если исходный файл был отре- дактирован в процессе компиляции. C1041 "Невозможно открыть промежуточный файл компилятора-больше нет". Компилятор не может создать промежуточный файл, используемый в процессе компиляции, поскольку больше нет логических номеров файлов. Данная ошибка может быть исправлена путем изменения строки files=number в файле CONFIG.SYS, чтобы задать большее число од- новременно открытых файлов (рекомендуется назначить число 20). C1042 "Невозможно открыть промежуточный файл компилятора-нет такого файла или каталога". Компилятор не может создать промежуточные файлы, используемые в процессе компиляции, поскольку в переменной операционный среды TMP задан неправильный каталог, или маршрут. C1043 "Невозможно открыть промежуточный файл компилятора". Компилятор не может создать промежуточные файлы, используемые в процессе компиляции. Точная причина неизвестна. C1044 "Нехватка дисковой памяти для промежуточного файла компилятора" Из-за недостатка памяти компилятор не может создать промежуточ- ный файл, используемый в процессе компиляции. Для исправления данной ситуации освободите место на диске и повторите компиля- цию. C1045 "Переполнение при операции с плавающей точкой". Компилятор получил ошибку при присваивании арифметических конс- тант элементам с плавающей точкой, как в следующем примере: float fp val = 1.0e100; В данном примере константа двойной точности 1.0е100 превышает максимально-допустимое значение для данных с плавющей точкой. C1047 "Слишком много появлений опции 'string'". Данная опция упоминается слишком много раз. Строка 'string' со- держит опцию, вызвавшую ошибку. C1048 "Неизвестная опция 'character' в 'optionstring'". Символ является некорректной буквой для опции 'optionstring'. C1049 "Неверный числовой аргумент 'string'". Вместо string ожидался числовой аргумент. C1050 "Сегмент кода 'segmentname' слишком большой". В процессе компиляции сегмент кода вырос за пределы 36 байтов от 64К. В данном случае используется 36-байтовый заполнитель, поскольку сбой на некоторых платах микропроцессоров 80286 могут вызвать непредсказуемое поведение программ, если среди прочих условий размер кодового сегмента находится в пределах 36 байтов от 64К. C1052 "Слишком много директив #if/#ifdef's". В программе превышено максимальное число уровней вложения ди- #if/#ifdef. C1053 "Размещение данных DGROUP превышает 64К". В стандартном сегменте данных были размещены более 64К перемен- ных. Для программ компактной, средней и большой модели памяти выпол- няйте компиляцию с помощью команды QCL, используя опцию /GT для размещения элементов данных в отдельных сегментах. C1054 "Ограничения компилятора: слишком глубокая вложенность инициа- заторов". Были превышены ограничения компилятора на вложенность инициали- заторов. Предел - от 10 до 15 уровней, в зависимости от комби- нации инициализируемых типов. Чтобы решить данную проблему, для сокращения уровней вложен- ности упростите тип инициализируемых данных, либо после опи- санияия присваивайте первоначальное значение в отдельных опе- раторах. C1056 "Ограничения компилятора: переполнение в процессе макро-расши- рения". Компилятор переполнил внутренний буфер при расширения макрокоманды. C1057 "Неожиданный EOF в макро-расширении; (пропущено ')'?)". Компилятор обнаружил конец исходного файла в процессе сборки аргументов макро-вызова. Обычно, это является результатом опу- щенной закрывающей правой скобки) в макро-вызове, как и в сле- дующем примере: #define print(a) printf(string is(,#a)) main() { print(the quick brown fox; } C1059 "Превышены пределы "ближней" динамической области". При размещении элементов данных в "ближней" динамической обла- сти (стандартный сегмент данных), компилятор вышел за допусти- мые пределы. C1060 "Превышены пределы "дальней" динамической области". При размещении элементов данных в "дальней" динамической облас- ти компилятор вышел за допустимые пределы памяти. Обычно дан- ная ошибка происходит во встроенных в память программах, по причине того, что таблица имен содержит слишком много имен. Чтобы исправить данную ситуацию, попробуйте выполнить компиля- цию с выключенной опцией Debug, либо попытайтесь подключить меньше включаемых файлов. Если такой способ не спасает ситу- ацию, выполните компиляцию программы посредством команды QCL. C1061 "Ограничения компилятора: слишком глубокое вложение блоков". Вложенность блоков в данной прогамме превышает возможности ком- пилятора. Для исправления данной ситуации перепишите программу так, чтобы вложенность блоков была меньшей. C1063 "Ограничения компилятора-переполнение стека компилятора". Ваша программа слишком сложна, поскольку привела к переполнению стека. Упростите вашу программу и повторите компиляцию. 

D.1.2. Сообщения об ошибках компилятора.

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

Номер Сообщения об ошибках компилятора C2000 "Нераспознанная ошибка. Обратитесь в Технический сервис фирмы Microsoft". Компилятор не может определить тип обнаруженной ошибки. Пожа- луйста, сообщите условие возникновения данной ошибки в фирму Microsoft, воспользовавшись специальным бланком "Product Assis- tance Reguest", находящимся на обложке данного руководства. C2001 "В константе обнаружен символ перехода на новую строку (newline)". Символ перехода на новую строку в символьной или строковой константе употребляется не в корректной форме управляющей последовательности (/n). C2002 "Фактические параметры макрокоманды превышают допустимые пре- делы памяти". Аргументы макро-препроцессора превышабт 256 байтов. C2003 "Требуется идентификатор". Идентификатор для проверки условия в #if не найден. C2004 "Требуется идентификатор". Директива #if вызвала синтаксическую ошибку. C2005 "В директиве #line требуется номер строки". В директиве #line не хватает заданного номера строки. C2006 "Директиве #include требуется имя файла". В директиве #include не хватает спецификации имени файла. C2007 "Синтаксическая ошибка директивы #define". В директиве #define была обнаружена синтаксическая ошибка. C2008 "'character': невозможен в макроопределении". Данный символ был использован в макроопределении некорректно. C2009 "Повторное использование формального параметра 'identifier' макроопределения". Данный идентификатор был дважды использован в списке формальных параметров макроопределения. C2010 "'character': невозможен в формальном списке". Данный символ был некорректно использован в списке формальных параметров макроопределения. C2011 "'identifier': определения слишком велико". Данное макроопределение превышает 256 байтов. C2012 "Пропущено имя, следующее за '<'". В директиве #include не хватает требуемой спецификации имени файла. C2013 "Не хватает знака '>'". В директиве #include пропущена закрывающая угловая скобка (>) C2014 "Команда препроцессора должна начинаться с первого значащего (не пробельного) символа". В директиве препроцессора на той же самой строке появились не пробельные символы перед знаком #. C2015 "Слишком много символов в константе". Символьная константа содержит более одного символа, либо была использована управляющая последовательность. C2016 "Отсутствует закрывающая одинарная кавычка". Символьная константа не была заключена в одинарные кавычки. C2017 "Некорректная управляющая последовательность". Символ или символы, следующие за знаком () не имеют корректной формы для управляющей последовательности. C2018 "Неизвестный символ 'Oxcharacter'". Данное шестнадцатеричное число не соответствует символу. C2019 "Требуется команда препроцессора, обнаружен символ 'character'" Данный символ следует за знаком (#), но не является первой бук- вой директивы препроцессора. C2020 "Неверное восьмеричное число 'character'". Данный символ не является корректной восьмеричной цифрой. C2021 "Число 'number'слишком велико для символа". Число 'number' слишком велико, чтобы представлять символ. C2023 "Деление на нуль". Второй операнд операции деления (/) при вычислении дает нуль. что может привести к непредсказуемым результатам. C2024 "По модулю 0". Второй операнд в остатке операции (%) при вычислении дает нуль, что может привести к непредсказуемым результатам. C2025 "'identifier': переопределение типа enum/struct/union". Данный идентификатор уже был использован в перечислении, струк- туре или тэге смеси. C2026 "'identifier': переопределение числа перечисления ". Данный идентификатор уже был использован в константе перечисле- ния, либо в том же самом типе перечисления, либо в другом типе перечисления в том же самом виде. C2028 "Член структуры/смеси должен находиться внутри структуры/смеси" Члены структуры или смеси должны быть описаны внутри структу- ры или смеси. Данная ошибка может быть вызвана описанием пе- речисления, содержащим описание члена структуры, как в следу- ющем примере: enum a { january, february, int march; /* описание структуры : ** некорректно */ }; C2029 "'identifier': битовые поля разрешены только в структурах". Только структуры могут содержать битовые поля. C2030 "'identifier': переопределение члена структуры/смеси". Данный идентификатор был более одного раза использован в качес- тве члена одной и той же структуры/смеси. C2031 "'identifier': функция не может быть членом структуры или сме- си". Данная функция была описана в качестве члена структуры или смеси. Для исправления данной ошибки воспользуйтесь указателем на функцию. C2032 "'identifier': базовый тип с ключевыми словами near/far/huge не разрешен". Данный член структуры или смеси был описан с ключевыми слова- ми far и near. C2033 "'identifier': к битовым полям нельзя применять оператор кос- венного обращения (*)". Данное битовое поле было описано как указатель (*), что не разрешено. C2034 "'identifier': битовое поле слишком мало для данного количества разрядов". Количество разрядов, заданное в описаний битового поля превы- ша%т количест-о разрядов в данеод базовом т(пе. C2040 "'.'требует имя структуры или смеси". Выражение перед оператором выбора структуры или смеси (.) явля- ется указателем на структуру или смесь, а не структурой или смесью, как требуется. C2041 "Ключевое слово 'enum' некорректно". В описании структуры или смеси появилось ключевое слово 'enum', либо определение типа 'enum' было сформировано некор- ректно. C2042 "ключевые слова signed/unsigned является взаимо-исключающими". Оба ключевых слова signed и unsigned были одновременно исполь- зованы в одном описании, как в следующем примере: unsigned signed int i; C2043 "Некорректный оператор break". Оператор break разрешен только внутри операторов do, for, while или switch. C2044 "Некорректный оператор continue". Оператор continue разрешен только внутри операторо do, for, или while. C2045 "'identifier': повторное определение метки". Данная метка появилась перед более, чем одним оператором в од- ной и той же функции. C2046 "Некорректное ключевое слово case". Ключевое слово case может находиться только внутри оператора switch. C2047 "Некорректное ключевое слово default". Ключевое слово default может находиться только внутри оператора switch. C2048 "Более одного default". Оператор switch содержит более одной метки default. C2050 "Не целое выражение switch". Выражение switch не является целым. C2051 "Выражение case не константное". Выражения case должны быть целыми константами. C2052 "Выражение case не является целым". Выражения case должны быть целыми константами. C2054 "Значение case 'number' уже было использовано". Данное значение case уже было использовано в операторе switch. C2054 "Требуется знак '(' после идентификатора 'identifier'". По контексту требуются скобки после функции 'identifier'. C2055 "Требуется список формальных параметров, а не тип list". В определении функции вместо списка формальных параметров поя- вился тип аргумента list. C2056 "Некорректное выражение". Из-за предыдущей ошибки выражение является некорректным (Пре- дыдущая ошибка могла не вызвать ошибочного сообщения). C2057 "Требуется константное выражение". По контексту требуется константное выражение. C2058 "Константное выражение не является целым". По контексту требуется целое константное выражение. C2059 "Синтаксическая ошибка: 'token'". Данная лексема вызвала синтаксическую ошибку. C2060 "Синтаксическая ошибка: EOF". Был обнаружен неожиданный конец файла, что вызвало синтак- сическую ошибку. Данная ошибка может быть вызвана опущенной зак рывающей скобкой '}' в конце вашей программы. C2061 "Синтаксическая ошибка: идентификатор 'identifier'". Данный идентификатор вызвал синтаксическую ошибку. C2062 "Тип 'type' не требуется". Данный тип был некорректно употреблен. C2063 "'identifier': не является функцией". Данный идентификатор не объявлен как функция, но сделана попы- тка использовать его в качестве функции. C2064 "Данный терм не вычисляется в функцию". Сделана попытка вызова функции с помощью выражения, которое при вычислении не дает указатель функции. C2065 "'identifier': не определен". Данный идентификатор не определен. C2066 "Преобразование к функции некорректно". Объект был преобразован к типу функции. C2067 "Преобразование к типу массива некорректно". Объект был преобразован к типу массива. C2068 "Некорректное приведение типов". Тип, используемый в приведении типов, не является корректным. C2069 "Приведение типа void к типу, не являющемуся void". Тип void был приведен к другому типу. C2070 "Некорректный операнд sizeof". Операнд выражения sizeof не является идентификатором, либо наи- менованием типа. C2071 "'class': неверный класс памяти". Данный класс памяти не может быть использован в таком контекс- те. C2072 "'identifier': инициализация функции". Была сделана попытка инициализации функции. C2073 "'identifier': невозможно инициализировать массив в функции". Была сделана попытка проинициализировать данный массив внутри функции. Массив можно поринициализировать только на внешнем уровне. C2074 "В функции запрещено инициализировать структуру или смесь". Была сделана попытка проинициализировать данную структуру или смесь внутри функции. Структуры и функции могут быть проинициа- лизированы только на внешнем уровне. C2075 "'identifier': инициализация массива требует только фигурных скобок". При инициализации массива были пропущены фигурные скобки {}. C2076 "'identifier': инициализация структуры или смеси требует только фигурных скобок". При инициализации структуры или смеси были пропущены фигурные скобки {}. C2077 "Нецелый инициализатор поля 'identifier'". Была сделана попытка инициализации члена структуры-битового по- ля нецелым значением. C2078 "Слишком много инициализаторов". Количество инициализаторов превышает количество инициализируе- мых объектов. C2079 "'identifier'-неопределенная структура или смесь". Данный идентификатор был описан, как структура или смесь, тип которой не определен. C2082 "Повторное определение формального параметра 'identifier'". Формальный параметр функции был повторно описан в теле функции. C2083 "Массив 'identifier' уже имеет размер". Размерность для данного массива уже была описана. C2084 "Функция 'identifier' уже имеет тело". Данная функция уже была определена. C2085 "'identifier': не в списке формальных параметров". Данный параметр был объявлен в определении функции для несущес- твующего формального параметра. C2086 "'identifier': переопределение". Данный идентификатор был определен более одного раза. C2087 "'identifier': пропущенный описатель". В определении массива с несколькими описателями было опущено значение описателя для размерности, отличной от первой, как в следующем примере: int func(a) char a[10][]; /* некорректно */ { . . . } int func(a) char a[][5]; /* корректно */ { . . . } C2088 "Использование неопределенного идентификатора 'identifier' пе- речисления/структуры/смеси". Данный идентификатор обращается к структуре или смеси, тип ко- торой не определен. C2089 "typedef определяет функцию near/far". Использование ключевых слов near или far в объявлении typedef не согласуется с использованием ключевых слов near или far для объявленного элемента, как в следующем примере. typedef int far FARFUNC(); FARFUNC near *fp; C2090 "Функция возвращает массив". Функция не может возвращать массив (она может возвращать только указатель на массив). C2091 "Функция возвращает функцию". Функция не может возвращать функцию (она может возвращать толь- ко указатель на функцию). C2092 "Элемент массива не может быть функцией". Массивы функций не разрешаются; однако, можно использовать мас- сивы указателй на функции. C2093 "Невозможно инициализировать статические данные или структуры адресами автоматических переменных". C2098 "Не-адресное выражение". Была сделана попытка инициализации элемента данных, не являю- щегося адресным выражением. C2099 "Неконстантное смещение". Инициализатор использовал неконстантное смещение. C2100 "Некорректное использование оператора (*)". Оператор (*) был применен к неуказателю. C2101 "'&' в константе". Оператор (&) не имеет адресного значения в качестве операнда. C2102 "'&' требуется адресное значение". Оператор адресации (&) должен применяться к адресному значению. C2103 "'&' в регистровой переменной". Была сделана попытка взять адрес регистровой переменной. C2104 "'&' в битовом поле". Была сделана попытка взять адрес битового поля. C2105 "'operator' требует адресного значения". Данный оператор не имеет адресного операнда. C2106 "'operator': левый операнд должен быть адресным". Левый операнд данного оператора не является адресным. C2107 "Некорректный индекс, косвенное наименование (*) не разрешено". Описатель был применен к выражению, которое не вычисляется в указатель. C2108 "Не-целый индекс". В качестве описателя массива было использовано не-целое выраже- ние. C2109 "Описатель в не-массиве". Описатель был использован в переменной, которая не является массивом. C2110 "'+': 2 указателя". Была сделана попытка сложить один указатель с другим. C2111 "Указатель + не-целое значение". Была сделана попытка сложить не-целое значение с указателем. C2112 "Некорректное вычитание указателей". Была сделана попытка вычесть указатели, не указывающие на один и тот же тип. C2113"'-': правый операнд-указатель". Правый операнд в операции вычитания (-) является указателем, а левый операнд-нет. C2114 "'operator': указатель слева; требуется целое справа". Левый операнд в данном операторе является указателем; правый операнд должен быть целым значением. C2115 "'identifier': несовместимые типы". Выражение содержит несовместимые типы. C2116 "'operator': неправильный левый (или правый) операнд". Заданный операнд данного оператора не соответствует данному оператору. C2117 "'operator': Некорректно для структуры или смеси". Значение структуры и смеси не разрешено с данным оператором. C2118 "Отрицательный описатель". Значение, определяющее размер массива, -отрицательно. C2119 "'typedefs' оба определяют косвенное наименование (*)". Были использованы одновременно два типа typedef для объявления элемента данных и оба типа typedef имеют косвенное наимено- вание. Например, объявление p в следующем примере-некорректно: typedef int *P INT; typedef short *P SHORT; /* данное объявление некорректно */ P SHORT P INT P; C2120 "'void'-некорректно со всеми типами". Тип void был использован в объявлении с другим типом. C2121 "typedef определяет другое перечисление". Была попытка использовать тип, объявленный в операторе typedef для задания, как типа перечисления, так и другого типа. C2122 "typedef определяет другую структуру". Была сделана попытка использовать тип, объявленный в операторе typedef, для задания как типа структуры, так и другого типа. C2123 "typedef определяет другую смесь". Была сделана попытка использовать тип, объявленный в операторе typedef, для задания как типа смеси, так и другого типа. C2125 "'idetifier': память, занятая данными, превышает 64К": Данный элемент данных превышает предельный размер 64К. C2126 "'identifier': данные типа automatic превышают размер 32К". Память, занятая локальными переменными функции, превышает зада- нный предел. C2127 "Память, занятая параметрами, превышает 32К". Память, требуемая для парметров функции превышает предел 32К. C2129 "Статическая функция 'identifier' не найдена". Была сделана ссылка на статическую функцию, которая никогда не была определена. C2130 "#line требуется строка, содержащая имя файла". В директиве #line было опущено имя файла. C2131 "Атрибуты near/far/huge заданы более одного раза". Ключевые слова near и far были применены к элементу данных бо- лее одного раза, как в следующем примере: typedef int near NINT; NINT far a; /* некорректно */ C2132 "Синтаксическая ошибка: неожиданный идентификатор". Идентификатор появлился в синтаксически некорректном формате. C2133 "Массив 'identifier': неизвестный размер" Была сделана попытка описать массив с неназначенным размером, как в следующем примере: int mat add(array1) int array1[]; /* корректно */ { int array2[]; /* некорректно */ . . . } C2134 "'identifier': структура или смесь слишком велики". Размер структуры или смеси превышает предел, установленный ком- пилятором (232 байтов). C2135 "Пропущен знак ')' в макро-расширении". В обращении к макрокоманде с аргументами была опущена закрыва- ющая скобка. C2137 "Пустая символьная константа". Была использована некорректная пустая символьная константа (' '). C2138 "Несоответствие закрывающей границы комментария '/*'". Компилятор обнаружил открывающий ограничитель комментария (/*) без соответствующего закрывающего ограничителя (*/). Данная ошибка может возникнуть из-за попытки использования не- корректных вложенных коментариев. C2139 "Тип, за которым следует 'type', некорректен". Некорректная комбинация типов, как в следующем примере: long char a; C2140 "Тип аргумента не может быть функцией, возвращающей ...". Функция была объявлена, как формальный параметр другой функ- ции, как в следующем примере: int funcl (a) int a(); /* некорректно */ C2141 "Для константы перечисления значение превышает допустимые пре- делы". Константа перечисления имеет значение, превышающее допустимые пределы для типа int. C2142 "Для многоточия требуется три точки". Компилятор обнаружил лексему, содержащую две точки (..) и пред- C2143 "Синтаксическая ошибка: недостает лексемы 'token1' перед лексе- мой 'token2'". Компилятор ожидает появления перед token2-token1. Данное сооб- щение может появиться, если пропущена требуемая закрывающая фи- гурная скобка (}), правая скобка ()) либо точка с запятой (;). C2144 "Синтаксическая ошибка: недостает лексемы 'token' перед типом 'type'". Компилятор требует наличия данной лексемы перед данным типом. Данное сообщение может появиться пре пропущенной закрывающей фигурной скобке (}), правой скобке ()), или точке с запятой (;). C2145 "Синтаксическая ошибка: перед идентификатором не хватает лексе- мы 'token'". Компилятор требует наличия перед идентификатором данной лексе- мы. Данное сообщение может появиться при пропущенной точке с запятой (;) в последнем объявлении блока. C2146 "Синтаксическая ошибка: перед идентификатором 'identifier' не хватает лексемы 'token'". Компилятор требует наличия данной лексемы перед данным иденти- фикатором. C2147 "Массив: неизвестный размер". Сделана попытка увеличить индекс, либо указатель на массив, ба- зовый тип которого еще не объявлен. C2148 "Слишком большой массив". Массив превышает максимально-допустимый размер (232 байта). C2149 "'identifier': данное битовое поле не может иметь нулевую шири- ну". Битовое поле с данным именем имеет нулевую ширину. Нулевой раз- мер разрешается иметь только неименованным битовым полям. C2150"'identifier': битовое поле должно иметь тип int, signed int или unsigned int. Стандарт ANSI C требует, чтобы битовые поля имели типы int, signed int или unsigned int. Данное сообщение может появиться только при компиляции с опцией /Za. C2151 "Задано более одного атрибута cdecl/fortran/pascal". Было задано более одного ключевого слова, определяющего согла- щения о вызове функций. C2152 "'identifier': указатели на функции с различными атрибутами". Была сделана попытка присвоить указатель на функцию, объявлен- ную с одними соглашениями о связях (cdecl, fortran или pascal)- -указателю на функцию, объявленную с другими соглашениями о связях. C2153 "Шестнадцатеричные константы должны иметь по крайней мере одну шестнадцатеричную цифру". Ox или OX-являются некорректными шестнадцатеричными константа- ми. За "x" или "X" должна следовать хотя бы одна шестнадца- теричная цифра. C2154 "'name': не относится к сегменту". Имя функции name было первым идентификатором, заданным в аргу- ментном списке прагмы alloc_text, и уже определено как какое- -либо имя, отличное от имени сегмента. C2155 "Имя 'name': уже имеется в сегменте". Имя функции name появляется более, чем в одной прагме alloc_ text. C2156 "Прагма должна быть на внешнем уровне". Некоторые прагмы должны быть определены на глобальном уровне, вне тела функции, а одна из таких прагм оказалась внутри фун- кции. C2157 "'name': перед использованием в списке прагмы данное имя долж- но быть описано". Данное имя функции из списка функций прагмы alloc_text не было описано перед включением в список. C2158 "'name': является функцией". Имя name было задано в списке переменных прагмы same_seg, но ранее было объявлено, как функция. C2159 "Определено более одного класса памяти". В описании было задано более одного класса памяти, как в сле- дующем примере: extern static int i; C2160 "## не может встретиться в начале макро-определения". Макро-определение начинается с оператора подстановки лексем, как в следующем примере: #define mac(a,b) ##a... C2161 "## не может находиться в конце макро-определения". Макро-определение заканчивается оператором подстановки лексем (##). C2162 "Требуется формальный параметр макрокоманды". Лексема, следующая за оператором (#), не является именем фор- мального параметра, как в следующем примере: #Define print(a) printf(#b) C2163"'string': отсутствует, как intrinsic". Функция, определенная в списке функций для прагмы intrinsic или function, не является одной из имеющихся в форме intrinsic фун- кций. C2165 "'keyword': невозможно изменить указатели на данные". Были некорректно использованы ключевые слова fortran, pascal или cdecl для модификации указателя на данные, как в следующем примере: char pascal *p; C2166 "Значение определяет объект, относящийся к классу памяти 'const'". Была сделана попытка присвоить значение элементу данных, объяв- ленному с классом памяти const. C2167 "'name': слишком много фактических параметров для intrinsic. Ссылка на имя intrinsic function содержит слишком много факти- ческих параметров. C2168 "'name': слишком мало фактических параметров для intrinsic". Ссылка на имя содержит слишком мало фактических параметров. C2169 "'name': является intrinsic оно не может быть определено ". Была сделана попытка задать определение для функции, уже описа- нной, как intrinsic. C2171 "'operator': неверный операнд". Данный унарный оператор был использован с операндом некоррект- ного типа, как в следующем примере: int (*fp)(); double d, d1; . . . fp++; d=~d1 C2172 "'function': фактически не указатель, параметр номер'number'. Была сделана попытка передать аргумент, не являющийся указате- лем, функции, требующей указатель. Данный номер указывает, ка- кой аргумент ошибочен. C2173 "'function': фактически не указатель, параметр 'number': спи- сок параметров 'number'". Была сделана попытка передать аргумент, не являющийся указате- лем, функции, требующей указатель. Данная ошибка может произой- ти в вызовах, возвращающих указатель на функцию. Первый номер указывает, какой аргумент вызвал ошибку; второй номер показы- вает, какой список аргументов содержит неверный аргумент. C2174 "'function': фактически имеет тип void: параметр 'number', спи- сок параметров 'number'". Была сделана попытка передать аргумент типа void функции. Фор- мальные параметры и аргументы функции не могут иметь тип void; однако, они могут иметь тип void* (указатель на void). Данная ошибка происходит в вызовах, возвращающих указатель на функцию. Первый номер показывает, какой аргумент вызвал ошибку; второй номер показывает, какой список аргументов содержит неправильный аргумент. C2175 "'function': неразрешенная внешняя ссылка". Данная функция неопределена в исходном файле, либо встроена в среду программирования QUICK-C, либо находится в библиотеке QUICK, если она загружена. Данная ошибка возникает только в одно-модульных, встроенных в среду Quick-C программах. Чтобы разрешить данную проблему, либо определите функцию в исходном файле, либо загрузите библиотеку QUICK,содержащую данную функцию, либо (если функция содержится в стандартной библиотеке СИ-функций), создайте для программы программный список. C2177 "Константа слишком велика". Информация была потеряна, поскольку константа слишком велика, чтобы заменить тип, которому она присваевается. (1) 

D.1.3. Предупреждающие сообщения.

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

Номер Предупреждающее сообщение C4000 "Нераспознанное предупреждение, свяжитесь с техническим сер- висом фирмы Microsoft". Компилятор обнаружил неизвестную ошибку. Пожалуйста, сообщите условия возникновения данной ошибке фирме Microsoft Corpora- tion, воспользовавшись бланком "Product Assistant Request", находящимся в конце данного руководства. C4001 "Макрокоманда 'identifier'требует параметров". Данный идентификатор был определен, как макрокоманда, имеющая один или более аргументов, но используется в программе без ар- гументов. (1). C4002 "Слишком много фактических параметров для макрокоманды 'identi- fier'". Число фактических аргументов, употребляемых с данным идентифи- катором, больше, чем число формальных параметров, заданных в макроопределении данного идентификатора. (1). C4003 "Не достаточно фактических параметров для макрокоманды 'identifier'". Число фактических аргументов, употребляемых с данным идентифи- катором, меньше, чем число формальных параметров, заданных в макроопределении данного идентификатора. (1). C4004 "Не хватает закрывающей скобки после 'defined'". После фразы #if defined пропущена закрывающая скобка. (1). C4005 "'identifier': повторное определение". Данный идентификатор был повторно определен. (1). C4006 "Директиве #indef требуется идентификатор". В директиве #indef задан идентификатор, определение которого отсутствет. (1). C4009 "Строка слишком велика, хвостовые символы отсекаются". Размер строки превышает предел, установленный компилятором. Для исправления данной ситуации разбейте строку на две или бо- лее подстроки. (1). C4011 "Идентификатор усечен до 'identifier'". Принимаются только первые 31 символ идентификатора. (1). C4014 "'identifier': битовое поле должно иметь тип unsigned. Данное битовое поле не было описано с типом unsigned. Битовые поля должны быть описаны, как целые без знака. Компилятор со- ответственно конвертирует данное битовое поле. (1). C4014 "'identifier': битовое поле должно иметь целый тип". Данное битовое поле было описано, не как целое. Битовые поля должны быть описаны, как целые без знака. Было применено пре- образование. (1). C4016 "'identifier': нет типа, возвращаемого функцией". Данная функция еще не была описана либо определена, поэтому тип возвращаемого значения неизвестен. Подразумевается стандартный тип (int). (2). C4017 "Приведение целого выражения к 'дальнему' указателю". Дальние указатели содержат полные адреса сегментов. На процес- соре 8086/8088 приведение целого (int) значения к "дальнему" указателю может создать адрес с бессмысленным значением сегмен- та. (1). C4020 "Слишком много фактических параметров". Число аргументов, определенных в вызове функции, больше числа формальных аргументов, заданных в списке аргументов определения функции. (1). C4021 "Слишком мало фактических параметров". Число аргументов, заданных в вызове функции, меньше числа фор- мальных параметров, определенных в списке аргументов определе- ния функции. (1). C4022 "Несоответствие указателей: параметр n". Тип указателя данного параметра отличен от типа указателя, за- данного в списке аргументов определения функции. (1). C4024 "Различные типы: параметр n". Тип данного параметра функции не согласуется с типом, заданным в списке аргументов определения функции. (1). C4025 "Описание функции задает переменный список аргументов". Список типов аргументов определения функции заканчивается запя- той, за которой следует многоточие, что означает, что функция может принимать переменное число аргументов, но для функции не были описаны формальные параметры. (1). C4026 "Функция была описана со списком формальных параметров". Функция была описана, как принимающая аргументы, но в определе- нии функции не задано формальных параметров. (1). C4027 "Функция была описана без списка формальных параметров". Функция была описана, как не принимающая аргументов (список типов аргументов состоит из слова void), но в определении функ- ции заданы формальные параметры, либо в вызове функции заданы фактические параметры. (1). C4028 "Отличается описание параметра n". Тип данного параметра не согласуется с соответствующим типом в списке типов аргументов, либо с соответствующим формальным па- раметром. (1). C4029 "Описание списка параметров отлично от определения": Список типов аргументов, заданный в описании функции, не со- гласуется с типами формальных параметров, заданных в опреде- лении функции. (1). C4030 "Первый список параметров длиннее второго". Функция была описана более одного раза, причем с различными списками типов аргументов. (1). C4031 "Второй список параметров длиннее, чем первый". Функция была описана более одного раза, причем с различными списками типов аргументов. (1). C4032 "Неименованная структура/смесь в качестве параметра". Тип структуры или смеси был передан как неименованный аргумент, то есть описание формального параметра не может использовать имя и должно описать тип. (1). C4033 "Функция должна возвращать значение". Если функция не описана, как void, она должна возвращать зна- чение. (2). C4034 "Оператор sizeof возвратил 0". Оператор sizeof был применен к операнду, причем в результате был получен 0. (1). C4035 "'identifier': нет возвращаемого значения". Функция описана, как возвращающая значение, но не делает этого. (2). C4036 "Не ожидаемый список формальных параметров". Список формальных параметров был задан в описании функции. Список формальных параметров игнорируется. (1). C4037 "'identifier': формальные параметры игнорируются". В описании функции не найдено перед описанием формальных параметров ни класса памяти, ни наименование типа, как в сле- дующем примере: int * f(a,b,c); Формальные параметры игнорируются. (1). C4038 "'identifier':формальный параметр имеет некорректный класс па- мяти". Данный формальный параметр был описан с классом памяти, от- личным от auto или register. (1). C4039 "'identifier': функция используется в качестве аргумента" Формальный параметр функции был описан, как функция, что не- корректно.Формальный параметр будет преобразован в указатель функции (1). C4040 "Ключевое слово near/far/ в идентификаторе 'identifier' игнори- руется". Ключевые слова near или far не оказывают никакого действия на данный идентификатор и потому игнорируются.(1). C4041 "Формальный параметр 'identifier' переопределен". Данный формальный параметр был в теле функции определен повтор- но, сделав соответствующий фактический параметр для функции не- доступным. (1). C4042 "'identifier' имеет не корректный класс памяти". Заданный класс памяти не может быть использован в данном конте- ксте (например, параметрам функции не может быть присвоен класс extern). Для данного контекста использован вместо некорректного стандартный класс памяти. (1). C4043 "'identifier': тип void изменен на int". Элемент данных, отличный от функции, был описан с типом void. (1). C4045 "'identifier': массив переполнен". Для данного массива было задано слишком много инициализаторов. Лишние инициализаторы будут игнорированы. (1). C4046 "Знак '&' в функции/массиве игнорируется". Была сделана попытка применить оператор адресации (&) к иден- тификатору, обозначающему функцию или массив. (1). C4047 "'operator': различные уровни косвенного наименования". Данную ситуацию иллюстрирует следующий пример: char **p; char *q; . . . p=q; C4048 "Массив описан с помощью различных описателей". Массив был описан дважды с различными размерами. Используется большой размер. (1). C4049"'operator': косвенное наименование применяется к различным ти- пам". Оператор косвенного наименования (*) был использован в выраже- нии для доступа к значениям различных типов. (1). C4051 "Преобразование данных". В выражении два элемента данных имеют различные типы, что при- ведет к преобразованию данных к одному типу. (2). C4052 "Различные типы enum". В выражении были использованы два различных типа enum. (1). C4053 "По крайней мере один операнд void" Выражение с типом void было использовано в качестве операнда. (1). C4056 "Переполнение в константной арифметике". Результат операции превышает 0x7FFFFFFF. (1). C4057 "Переполнение при перемножении констант". Результат операции превышает 0x7FFFFFFF. (1). C4058 "Взят адрес переменной фрейма, DS!=SS". Программа была скомпилирована со стандартным сегментом данных (DS), не равным стэковому сегменту (SS), программа пытается об- ратиться к переменной фрейма посредством ближнего указателя.(1) C4059 "В результате преобразования адрес сегмента потерян". Преобразование "дальнего" указателя (полного адреса сегмента) к "ближнему" указателю (смещение) привело к потере адреса сегмен- та. (1). C4060 "Преобразование 'длинного' адреса в 'короткий' адрес". Преобразование длинного адреса (32-разрядного указателя) в ко- роткий адрес (16-разрядного указателя) привело к потере адреса сегмента. (1). C4061 "long/short несоответствие в аргументе: применено преобразо- вание". Базовые типы действительных и формальных параметров функции различны. Фактический параметр преобразовывается к типу фор- мального параметра. (1) C4063 "'identifier': функция слишком велика для шага оптимизации". Данная функция не была оптимизирована, поскольку для этого недостаточно памяти. Чтобы исправить данную ситуацию, сократи- те размер функции путем разделения ее на две или более меньших функций. (0). C4066 "Таблица локальных имен переполнена-некоторые локальные имена могут быть пропущены в списке". Генератор листинга вышел за пределы динамической области, отве- денной под локальные переменные, поэтому исходный листинг может не включать в себя полную таблицу имен для всех локальных пере- менных C4067 "За директивой 'directive' следуют непонятные символы-требует- ся символ перехода на следующю строку". За директивой препроцессора следуют лишние символы, как в следующем примере: #endif NO_EXT_KEYS Это принимается в некоторых версиях компилятора Microsoft C, исключая версию 1.0 Microsoft Quick C. (1). C4068 "Неизвестная прагма". Компилятор не смог распознать прагму и игнорировал ее. (1). C4069 "Преобразование ближнего указателя к длинному целому". Ближний указатель был преобразован к длинному целому, что за- полнило старшие разряды текущим значением сегмента данных, не равным нулю. (1). C4071 "'identifier': прототип функции не задан". Данная функция была вызвана компилятором перед тем, как компи- лятор обработал соответствующий прототип функции. (3). C4072 "Недостаточно памяти для обработки отладочной информации". Вы скомпилировали программу с опцией /Zi, но для создания со- ответствующей отладочной информации недостаточно памяти. (1). C4073 "Вложенность слишком глубока, дальнейшая вложенность во время отладки игнорируется". Описания появились на уровне вложенности, большем 13. В ре- зультате, все описания будут восприниматься как бы на одном уровне. (1). C4074 "Было использовано нестандартное расширение-'extension'". Было использовано данное нестандартное расширение в то время, как опция Language Extension в диалоговой рамке Compile была выключена, либо опция /Ze не действовала. Данные расширения да- ны в Разделе 8.1.4.6. "Использование расширений языка СИ фирмы Microsoft: Опция Language Extension". (если включена опция /Za, данная ситуация дает ошибку). (3). C4075 "Размер выражения в операторе switch или константа в операторе case имеют слишком большой размер-преобразуются к типу int". Значение, появляющееся в операторах switch или case, больше ти- па int. Компилятор преобразует данное некорректное значение в тип int. (1). C4076 "'type': может быть использовано только с целыми типами". Модификатор типа signed или unsigned был применен к не целому типу, как в следующем примере: unsigned double b; C4077 "Неизвестная опция прагмы check_stack". Со старой формой прагмы check_stack была задана неизвестная опция, как в следующем примере: #pragma check_stack yes В старой форме прагмы check_stack аргумент прагмы должен быть пустым + или -. C4079 "Неожиданный символ 'character'". В аргументном списке прагмы был найден неожиданный разделитель 'character'". C4080 "Пропущено имя сегмента". В первом аргументе аргументного списка прагмы alloc_text про- пущено имя сегмента. Это случается, если первая лексема в ар- гументном списке не является идентификатором. C4082 "Требуется идентификатор". В списке аргументов прагмы пропущен идентификатор. C4083 "Пропущено'('". В аргументном списке прагмы пропущена открывающая левая скобка, как в следующем примере: #pragma check_pointer on) C4084 "Требуется ключевое слово pragma". Лексема, следующая за ключевым словом pragma, не является иден- тификатором, как в следующем примере: #pragma (on) C4085 "Требуется [on/off] Для новой формы прагмы check_stack был задан некорректный аргу- мент, как в следующем примере: #pragma check_stack (yes) C4087 "'name': описана с пустым списком параметров". Данная функция была описана, как не принимающая параметров, в то время как вызов функции определяет фактические параметры, как в следующем примере: int fl(void); . . . fl(10); C4090 "Различные атрибуты 'const'". Указатель на элемент данных, описанный, как const, был пере- дан функции, соответствующий формальный параметр которой явля- ется указателем на элемент данных, не являющийся const. Это значит, что данный элемент данных может быть незаметно изме- нен, как в следующем примере: const char *p = "ascde"; int str(char *s); . . . str(p); C4091 "Не описано никаких имен". Компилятор обнаружил пустое описание, как в следующем примере (2): int; C4092 "Описание перечисления/структуры/смеси не имеет имени". Компилятор обнаружил пустое описание, использующее не имеющую соответствующего тэга структуру, смесь или перечисление, как в следующем примере: struct { . . . }; C4093 "Некорректный символ перехода на новую строку в символьной кон- танте в не действующем коде". Константное выражение в директиве препроцессора #if, #ifdef или #ifndef вычисляется в 0, что делает соответствующий код неактив ным, причем символ перехода на новую строку появляется в данном не активном коде между соответствующими одиночными или двойными кавычками. C4095 "Слишком много аргументов для прагмы". В прагме, имеющей только один аргумент, появляется более одного аргумента. C4096 "Элемент типа huge трактуется, как far". Поскольку компилятор Microsoft Quick-C не поддерживает ключевое слово huge, элемент данных трактуется, как описанный с ключе- вым словом far. Если элемент данных или функция должны все же иметь тип huge, перекомпилируйте программу с помощью Оптимизиру ющего компилятора Microsoft C. C4097 "В строке встретился символ 'hex-character', не относящийся к коду ASCII". Данный не ASCII-символ был использован в данной символьной строке. 

D.1.4. Ограничения компилятора.

Для работы с компилятором Microsoft Quick-C вам нужно иметь достаточное количество памяти для обработки временных файлов, используемых для обработки. Требуется память приблизительно в два раза большая, чем размер исходного файла.

В таблице D.1 приводятся ограничения,накладываемые СИ-компиля- тором. Если ваша программа превышает один из заданных пределов, вас информирует об этом сообщение об ошибке.

 Таблица D.1. Ограничения СИ-компилятора. Элемент программы Описание Ограничения Строковые литералы Максимальная длина строки, 512 байтов включающая нулевое оконча- ние (). Константы Максимальный размер констан- ты зависит от ее типа; смот- рите "Справочное руководство по языку СИ". Идентификаторы Максимальная длина идентифи- 31 байт (дополни- катора тельные символы не воспринимают- ся). Описания Максимальный уровень вло- 10 уровней женности для определений структуры или смеси. Директивы препроцес- Максимальный размер макро- 512 байтов. сора определения. Максимальное количество 8 аргументов фактических параметров в макроопределении. Максимальная длина реально- 256 байтов го аргумента препроцессора. Максимальный уровень вложен- 32 уровня ности директив #if, #ifdef, #ifndef. Максимальный уровень вложен- 10 уровней ности для подключаемых фай- лов. 

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

D.2.Сообщения об ошибках в командной строке.

Сообщения, указывающие на ошибки в командной строке, используемой для вызова компилятора, имеют один из следующих форматов:

command line fatal error D1xxx: messagetext Fatal error (Фатальная ошибка командной строки D1xxx: текст сообщения Фатальная ошибка) command line error D2xxx: messagetext Error (Ошибка командной строки D2xxx: текст сообщения Ошибка) command line warning D4xxx: messagetext Warning (Предупреждение командной строки D4xxx: текст сообщения Предупреждение). 

Если возможно, компилятор продолжает работу, распечатывая предупреждающее сообщение. В некоторых случаях ошибки командной строки являются неисправимыми и компилятор прекращает работу. Сообщения, приведенные в разделах D.2.1-D.2.3 описывают ошибки командной строки.

D.2.1. Неисправимые ошибки командной строки.

Следующие сообщения описывают фатальные ошибки. Драйвер компилятора не может восстановить работу после фатальной ошибки; он прекращает работу после распечатки сообщения.

Номер Сообщение о фатальной ошибке в командной строке D1000 Неизвестная фтатальная ошибка командной строки. Свяжитесь с тех нической службой фирмы Microsoft. Компилятор обнаружил нераспоз нанную неисправимую ошибку. Пожалуйста, сообщите условия возникновения данной ошибки в фир- му Microsoft Corporation с помощью формы Product Assistance Request, находящейся в конце данного руководства. D1001 "Невозможно выполнить 'filename'". Компилятор не может найти данный файл в текущем рабочем катало- ге, либо в других каталогах, определяемых посредством перемен- ной PATH. D1002 "Слишком много открытых файлов, невозможно переадресовать 'filename'". Больше нет файлов, чтобы переадресовать вывод опции /P в файл. Попробуйте изменить ваш файл CONFIG.SYS и увеличьте значение num в строке files=num (если num меньше 20). 

D.2.2. Сообщения об ошибках командной строки.

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

Номер Сообщение об ошибках командной строки D2000 "Нераспознанная ошибка командной строки, обратитесь в техничес- кий сервис фирмы Microsoft". Компилятор обнаружил неизвестную ошибку. Пожалуйста, сообщите условия возникновения данной ошибки фирме Microsoft Corporati- on, используя бланк "Product assistance Request", находяцийся в конце данного руководства. D2001 "Слишком много имен определены с -D". Слишком много символических констант были определены с помощью опции /D командной строки. Обычный предел определений на командной строке 16; если вы ис- пользуете опции /U или /u-предел увеличивается до 20. D2002 "Предварительно определенная модель была отменена". Были определены две различные модели памяти; используется мо- дель, заданная на командной строке позже. D2003 "Пропущено имя исходного файла". Вы не задали имя компилируемого исходного файла. D2007 "Неверно задана опция, следует заменить 'string1' на 'string2'". Данная опция была задана более одного раза с конфликтующими ар- гументами string1 и string2. D2008 "Слишком много флажков опции 'string'". С заданной опцией было определено слишком много букв (например, с опцией /O). D2009 "Неизвестный символ опции 'option string'". Одна из букв данной опции нераспознана. D2010 "Неизвестная опция плавающей точки". Данная опция плавающей точки ( опция /FP) не является коррект- ной. D2011 "Разрешена только одна опция плавающей точки". На командной строке вы задали более одной опции плавающей точ- ки (/FP). D2012 "На командной строке слишком много опций компановщика". Вы сделали попытку задать на командной строке более 128 отдель- ных опций и объектных файлов для компановщика. D2015 "Ассемблерные файлы не обрабатываются". Вы задали на командной строке имя файла с расширением .ASM. Поскольку компилятор не может автоматически вызывать Макроас- семблер (MASM), он не может ассемлировать данные файлы. D2018 "Невозможно открыть файл компановщика cmd". Файл соответствий, передающий компановщику имена объектных фай- лов и опции, не может быть открыт. Данная ошибка может произойти, если какой-либо файл с атрибутом "только-чтение" имеет то же самое имя, что файл соответствий компановщика. D2019 "Невозможно перезаписать исходный файл 'name'". Вы задали исходный файл в качестве выводного. Компилятор не позволяет исходному файлу быть перезаписанным одним из выход- ных файлов компилятора. D2020 "Опция -Gc требует возможности разрешения расширенных ключевых слов (-Ze)". Опция /Gc и опция /Za были заданы на одной командной строке. Опция /Gc требует возможности задания расширенного ключевого слова cdecl, если осуществляется доступ к библиотечным функ- циям. D2021 "Неверный числовой аргумент 'string'". Нечисловая строка была задана за опцией, требующей числового аргумента. D2022 "Невозможно открыть файл помощи cl.hlp". Была задана опция /HELP, но файл содержащий вспомогательные сообщения не был найден в текущем каталоге, либо в каталогах, заданных с помощью переменной PATH. 

D.2.3. Предупреждающие сообщения командной строки.

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

Номер Предупреждающие сообщения D4000 "Неизвестное предупреждение командной строки, свяжитесь с тех- нической службой фирмы Microsoft". Компилятором была обнаружена неизвестная ситуация. Пожалуйста, сообщите условия возникновения данной ситуации фир- ме Microsoft Corporation, используя бланк "Product Assistance Request", находящийся в конце данного руководства. D4002 "Неизвестная опция 'string' игнорируется". Одна из опций, заданных на командной строке, была нераспоз- нана и потому проигнорирована. D4003 "Для генерации кода выбран 80186/286, а не 8086". Были заданы обе опции: /G0 и /G2; преимущество дано опции /G2. D4004 "Оптимизация по времени, а не по размеру". Данное сообщение подтвердило использование для оптимизации оп- ции /Ot. D4005 "Невозможно выполнить 'filename'; пожалуйста, вставьте дискету и нажмите любой ключ". Команда QCL не может найти заданный выполняемый файл по задан- ному маршруту. D4006 "Разрешена только одна из опций -P/-E/-EP, выбрана -P". Было задано более одной выводной опции препроцессора. D4007 "Опция -C игнорируется (нужно задать также -P или -E, либо -EP)". Опция /C должна использоваться вместе с одной из выводных опций препроцессора (/E, /EP, /P). D4009 "Порог только для данных far/huge, игнорируется". Опция /Gt была использована в модели памяти, имеющей ближние указатели на данные. Она может применяться только для ком- пактной и большой моделей. D4010 "Опция -Gp не применяется, игнорируется". Версия операционной системы DOS Microsoft C не поддерживает профайлинг. D4013 "Комбинированный листинг имеет преимущество над объектным листингом" Если опция /Fc задана вместе с одной из опций /Fl или /Fa, соз- дается комбинированный листинг (/Fc). D4014 "Неверное значение number для строки 'string'. Используете ста- ндартное значение number". В контексте, требующем определенное числовое значение, было за- дано некорректное значение. D4017 "Конфликтующие опции проверки стэка-проверка стека отменяется". Вы задали на командной строке CL обе опции /Ge и /Gs. Опция Gs имеет преимущество, поэтому в данной программе стэковый конт- роль отменяется. 

D.3. Сообщения об ошибках периода выполнения.

Ошибки периода выполнения подразделяются на четыре категории: 1.Исключительные ситуации при выполнении операций с плавающей точкой математическим сопроцессором 8087/80287 или эмулятором. Данные ситуации описаны в Разделе D.3.1.

2. Сообщения об ошибках, сгенерированные библиотекой периода выполнения, информирующие вас о серьезных ошибках. Данные сообщения перечислены и описаны в Разделе D.3.2.

3. Сообщения об ошибках, сгенерированные во время обращения к процедурам обработки ошибок библиотеки периода выполнения — abort, assert, perror-как только программа вызовет процедуру. Данная процедура направляет сообщения в стандартный вывод. Описание данных процедур и соответствующих сообщений об ошибках смотрите в документе: «Справочное руководство по библиотеке процедур Microsoft-C».

4. Сообщения об ошибках, сгенерированные вызовами математических процедур из библиотеки СИ периода выполнения. В случае ошибки математические процедуры возвращают ошибочное значение, а некоторые выводят сообщение на стандартной вывод. Описание математических процедур и соответствующие сообщения об ошибках смотрите в документе «Справочное руководство по библиотеке проц Microsoft-C».

D.3.1. Исключительные ситуации операций с плавающей точкой.

Сообщения об ошибках, перечисленные ниже, генерируются математическим сопроцессором 8087/80287. Описание сбоев оборудования смотрите в документации по процессорам семейства Intel. Данные ошибки могут быть также выявлены эмулятором операций с плавающей точкой, встроенным в стандартную библиотеку Quick-C.

С помощью назначений управляющего слова сопроцессора 8087/80287, следующие исключительные ситуации маскируются и потому не происходят Исключительная Стандартное маскирующее действие

ситуация

Слишком малое число Ситуация маскируется Потеря значимости Результат приводится к нулю Потеря точности Ситуация маскируется 

Информацию о том, как изменить управляющее слово операций с плавающей точкой, смотрите в справочных страницах, посвященных _control87, в документе «Справочное руководство по библиотеке процедур Microsoft C».

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

 Квадратный корень Выход за нижнюю границу стэка Неэмулируется 

Исключительные ситуации при операциях с плавающей точкой имеют следующий формат:

 run-time error M61nn: MATH - floating-point error: messagetext 

Номер Исключительные ситуации при операциях с плавающей точкой

М6101 "Неверно". Произошла некорректная операция. Обычно это происходит при дей- ствиях с с неопределенностями. Данная ошибка приводит к останову программы с кодом завершения 129. Номер Исключительные ситуации при операциях с плавающей точкой М6102 "Слишком малое число". Было сгенерировано слишком малое число с плавающей точкой, даль нейшее его использование приведет к потере значимости. Такие ситуации обычно маскируются, они отлавливаются и обрабатывают- ся. Программа заканчивается с кодом завершения 130. М6103 "Деление на нуль". Была сделана попытка деления на нуль. Программа заканчивается с кодом 131. М6104 "Переполнение". При выполнении операции с плавающей точкой произошло переполне- ние. Программа заканчивается с кодом 132. М6105 "Потеря значимости". Во времы операции с плавающей точкой произошла потеря значимос- ти. Такие ситуации обычно маскируются; слишком малое значение заменяется нулем. Программа заканчивается с кодом завершения 133. М6106 "Потеря точности". Во время операции с плавающей точкой произошла потеря точности. Данная ситуация обычно проходит незамеченной, поскольку почти все операции с плавающей точкой могут привести к потере точнос- ти. Программа заканчивается с кодом 134. М6107 "Невозможна эмуляция" Была сделана попытка выполнить инструкцию сопроцессора 8087/ /80287, являющуюся некорректной и не поддерживаемую эмулятором. Программа завершается с кодом 135. М6108 "Квадратный корень". Операнд операции извлечения квадратного корня отрицателен. Про- грамма завершается с кодом 136. (обратите внимание, функция sqrt из библиотеки процедур языка СИ проверяет аргумент перед выполнением и возвращает ошибку, если аргумент отрицателен; описание функции sqrt смотрите в документе: "Справочное руко- водствопо библиотеке процедур Microsoft-C": М6110 "Переполнение стэка". Выражение с плавающей точкой привело к переполнению стэка на сопроцессоре 8087/80287 или эмуляторе. (ситуации переполнения стэка отлавливаются до предела 7 уровней в дополнение к восьми уровням, обычно поддерживаемым сопроцессором 8087/80287). Прог- рамма завершается с кодом 138. М6111 "Выход за нижнюю границу стэка". Выполнение операции с плавающей точкой на сопроцессоре 8087/80287 или эмуляторе вызвало выход за нижнюю границу стэка. Программа завершается с кодом 139. М6112 "Явно сгенерирована ошибка". Сигнал, означающий ошибку при выполнении операции с плавающей точкой, был послан с помощью вызова raise (SIGFPE). Программа завершается с кодом 140. 

D.3.1. Сообщения об ошибках периода выполнения.

Следующие сообщения описывают ошибки, сгенерированные в процессе выполнения программы. Номера ошибок периода выполнения лежит в пределах от R6000 до R6999.

Сообщения об ошибках периода выполнения имеют следующую основную форму:

 run-time error R6nnn - messagetext (ошибка периода выполнения R6nnn) (- текст сообщения) 

Номер Сообщение об ошибке периода выполнения

R6000 "Переполнение стэка". Ваша программа переполнила пространство, отведенное под стэк. Это может произойти, если ваша программа использует большое количество локальных данных или является рекурсивной. Программа завершается с кодом 255. Чтобы исправить данную ситуацию, перекомпилируйте программу с помощью команды QCL с опцией /F и перекомпануйте программу, ис- пользуя опцию компановщика /STACK для размещения большого стэка R6001 "Присваивание нулевого указателя". В процессе выполнения программы было изменено содержимое сег- мента NULL. Сегмент NULL-это специальное место, расположенное по младшим адресам памяти, которое обычно не используется. Ес- ли содержимое сегмента NULL изменилось в процессе выполнения программы, это означает, что программа была записана на эту об- ласть, обычно, из-за примененного по небрежности нулевого ука- зателя. Заметим, что ваша программа может содержать нулевые указатели, но данное сообщение не будет генерироваться; данное сообщение появляется только в случае обращения к области памяти с помощью нулевого указателя Данная ошибка не будет вызывать останов программы; за сообщени- ем об ошибке следует нормальное завершение программы. Ошибка возвращает ненулевой код завершения. Данное сообщение отражает возможность серьезных ошибок в программе. Хотя программа, в ко- торой возникла такая ошибка, может работать правильно, она ве- роятно дает ошибки в будущем, и может дать сбой при работе в другой операционной среде. R6002 "Библиотека процедур операций с плавающей точкой не загружена". Ваша программа требует библиотеку с плавающей точкой, но данная библиотека не загружена. Программа завершается по ошибке с ко- дом 255. Такая ошибка может произойти в следующих двух ситуа- циях: 1.Программа была скомпилирована или скомпанована с такой опци- ей, как /FPi87, требующей сопроцессор 8087 или 80287, но прог- рамма выполняется на машине, не имеющей такого. Для исправления ошибки либо перекомпилируйте программу с опцией /FPi, либо ус- тановите сопроцессор. (В разделе 9.3.5 данного руководства вы найдете более подробную информацию о данных опциях и билиоте- ках. 2.Строка формата для одной из процедур семейства printf или scanf содержит спецификацию для формата с плавающей точкой, в то время, как значений или переменных с плавающей точкой в про- грамме нет. Компилятор Quick-C делает попытку минимизировать размер программы посредством загрузки библиотеки поддержки пла- вающей точки только в случае крайней необходимости. Поскольку в форматных строках не обнаружено спецификаций плавающей точки, необходимые процедуры для работы с плавающей точкой не были за- гружены. Для исправления данной ошибки используйте какой-либо аргумент с плавающей точкой для соответствия заданной специфи- кации формата. Это приведет к тому, что библиотека поддержки плавающей точки будет загружена. R6003 "Целое, деленное на нуль". Была сделана попытка разделить целое число на нуль, что дало неопределенный результат. Программа завершается с кодом 255. R6004 "Требуется версия DOS 2.0 или выше". Компилятор Quick-C не может работать на версиях операционной системы DOS младше 2.0. R6005 "Не хватает памяти для exec". Ошибки с R6005 по R6007 происходят при сбое в процедурах, вызы- ваемых одной из библиотечных, когда операционная система DOS не может вернуть управление в родительский процесс. Данная ошибка показывает, что для загрузки вызываемой программы не хватает памяти. R6006 "Неверный формат для exec". Файл, выполняемый одной из функций exec, не имеет формата, тре- буемого для выполняемого файла. R6007 "Некорректная среда для exec". Во время вызова одной из функций exec, операционная система DOS обнаружила некорректность среды для детского процесса. R6008 "Не хватает памяти для аргументов". R6009 "Не хватает памяти для программной среды". Ошибки R6008 и R6009 могут произойти при старте программы, если для загрузки программы хватает памяти, но недостаточно места для вектора argv, либо вектора envp, либо для обоих. Чтобы избежать данной проблемы перепишите процедуры _setargv или _setenvp R6012 "Некорректное обращение к ближнему указателю". В программе был использован нулевой ближний указатель. Данная ошибка может произойти только при включенном контроле на указатели (то есть, если программа была скомпилирована с опцией Pointer Check в диалоговой рамке Compile, опцией /Zr на команд- ной строке, либо при действующей прагме pointer_check). R6015 "Неожидаемое прерывание". Программа не может выполняться, поскольку она содержит неожида- емые прерывания. Когда прерывания создаются в программе из программного списка, работающей в программной среде, Quick-C автоматически создает объектные файлы и передает компановщику. Объектные файлы, пере- данные компановщику, содержат прерывания , требуемые для про- граммной среды Quick-C. Однако, вы не сможете запускать програ- мму, полученную из данных объектных файлов, вне программной среды Quick-C. 

D.3.3. Ограничения периода выполнения.

В таблице D.2 приведены ограничения, накладываемые на программы в период выполнения. Если ваша программа нарушает одно из данных ограничений, система выдает соответствующее сообщение об ошибке.

 Таблица D.2. Программные ограничения периода выполнения. Элемент данных Описание Ограничения Файлы Максимальный размер файла 232-1 байт (4 гигабайта) Максимальное число одновременно от- 20 крытых файлов (потоков). Командная строка Максимальное количество символов 128 (включая имя программы). Таблица операци- Максимальный размер. 32К онной среды. 

---

Примечание:

Пять стандартных потоков открываются автоматически (stdin, stdout, stderr, stdaux, stdprn), оставляя еще 15 потоков для нужд программы.

---

D.4. Сообщения об ошибках компановщика.

Данный раздел описывает сообщения об ошибках, генерируемые компановщиком LINK (Оверлейный компановщик фирмы Microsoft). При возникновении фатальной ошибки компановщик прерывает выполнение. Сообщения о фатальных ошибках имеют следующий формат:

место возникновения: fatal error L1xxx: текст сообщения Нефатальные ошибки выявляют проблемы в выполняемом файле. Компановщик LINK строит выполняемый файл. Нефатальные ошибки имеют следующий формат:

место возникновения: error L2xxx: текст сообщения

Предупреждения также обозначают возможные проблемы в выполняемом файле. Компановщик LINK строит выполняемый файл. Предупреждения имеют следующий формат:

место возникновения: warning L4xxx: текст сообщения

В данных сообщениях-место возникновения-это входной файл, в котором обнаружена ошибка, либо программа LINK, если входного файла нет. Если входной файл-это файл .OBJ или .LIB и известно имя модуля, имя модуля заключается в скобки, как показано в следующем примере:

SLIBC.LIB( file) MAIN.OBJ(main.c) TEXT.OBJ 

Ошибки компановщика могут возникнуть, как при неявном его вызове с помощью команды QCL, так и при явном вызове с помощью команды LINK. Они могут также произойти и при компиляции программы, имеющей программный список, либо когда вы создаете на диске выполняемый файл в среде Quick-C. Если ошибка компановщика возникает в программной среде Quick-C, Quick-C высвечивает сообщение:

Error during link phase No .EXE file produced (Ошибка в процессе компановки Выполняемого файла не создается). 

Для просмотра ошибок компановщика нажмите ENTER, либо отметьте «мышью» командную кнопку OK. Ошибки последнего прохода компановщика хранятся в файле с именем LINK.ERR. В следующем списке приведены ошибки, возникающие во время компановки объектных файлов с помощью Microsoft Overlay Linker, LINK.

Номер Сообщение об ошибке компановщика L1001 "'option': имя опции неясно". После индикатора опции (/) не появилось уникального имени оп- ции. Например, команда Link /N main; сгенерирует ошибку, поскольку программа LINK не может опреде- лить, какая из опций, начинающихся на букву "N" имеется в виду. L1002 "'option': нераспознанное имя опции". За индикатором опции (/) появился нераспознанный символ, как в следующем примере: LINK /ABCDEF main; L1004 "'option': неверное числовое значение". Для одной из опций было задано некорректное числовое значение. Например, для опции, требующей числовое значение, задана сим- вольная строка. L1006 "'option': размер стэка превышает 65535 байтов". Размер, определенный для стэка, превышает 65535 байтов. l1007 "'option': номер прерывания превышает 255". В качестве значения опции /OVERLAYINTERRUPT задано число, более 255. l1008 "'option': слишком большое предельное число сегментов". Было установлено предельное число сегментов, большее 3072 ( с помощью опции /SEGMENTS). L1009 "'option': CPARMAXALLOC: некорректное значение". Число, определенное в опции /CPARMAXALLOC не лежит в пределах 1-65535. L1020 "Не заданы объектные модули". Для компановщика не заданы имена объектных файлов. L1021 "Файлы соответствий вкладывать невозможно". Один файл соответствий оказался внутри другого файла соответст- вий. L1022 "Файл соответствий слишком длинный". Строка в файле соответствий длиннее 127 символов. L1023 "Выполнение прекращено пользователем". Вы нажали CONTROL+C. L1024 "Вложение правых скобок". В командной строке содержимое оверлея было написано некоррекн- но. L1025 "Вложение левых скобок". В командной строке содержимое оверлея было написано некоррекн- но. L1026 "Несоответствие правых скобок". В командной строке в спецификации содержимого оверлея пропуще- на правая скобка. L1027 "Несоответствие левых скобок". В командной строке в спецификации содержимого оверлея пропуще- на левая скобка. L1043 "Таблица распределения памяти переполнена". В программе задано более 32768 длинных вызовов, длинных перехо- дов, либо других длинных указателей. Попытайтесь заменить длинные ссылки короткими, если возможно, и перестроить объектный модуль L1045 "Слишком много записей TYPDEF. Объектный модуль содержит более 255 записей TYPDEF. Данные за- писи описывают общие переменные. Такая ошибка может возникнуть только в программах, созданных компилятором Microsoft Quick-C или другими компиляторами, поддерживающими общие переменные. (TYPDEF-это термин операционной системы DOS. Он разъясняется в документе "Справочное руководство программиста по операционной системе MS-DOS фирмы Microsoft" или других справочных книг по DOS.) L1046 "Слишком много внешних имен в одном модуле". В объектном модуле определено более 1023 внешних имен. Разбейте модуль на меньшие части. L1047 "Слишком много имен групп, сегментов, классов в одном модуле". Программа содержит слишком много имен групп, сегментов, клас- сов. Сократите число групп, сегментов или классов и перестройте объектный файл. L1048 "Слишком много сегментов в одном модуле". Объектный модуль имеет более 255 сегментов. Расщепите модуль или объедините сегменты. L1049 "Слишком много сегментов". Программа имеет более, чем максимально разрешенное число сег- ментов. (опция /SEGMENTS определяет максимально разрешенное число; стандартно 128). Повторите компановку с опцией /SEGMENTS с соответствующим чис- лом сегментов. L1050 "Слишком много групп в одном модуле". Программа LINK обнаружила более 21 определения групп (GRPDEF) в одном модуле. Сократите число определений групп или расщепите модуль. (Опре- деления групп разъясняются в документе "Справочное руководство программиста по MS-DOS" и в других справочных книгах по DOS. L1051 "Слишком много групп". В программе определено более 20 групп, не считая DGROUP. Сократите количество групп. L1052 "Слишком много библиотек". Была сделана попытка скомпановать более 32 библиотек. Объедините библиотеки, либо используйте модули, требующие мень- шего количества библиотек. L1053 "Переполнение таблицы имен". Компановщик не имеет достаточно места для размещения таблицы имен программы (таких, как глобальные, внешние, имена сегмен- тов, групп, классов, файлов). Объедините модули или сегменты и перестройте объектные файлы. Исключите столько глобальных имен, сколько возможно. L1054 "Требуемое количество сегментов слишком велико". Компановщик не имеет достаточно памяти для размещения таблицы, описывающей количество требуемых сегментов (стандартное число 128 или значение, определенное в опции /SEGMENTS). Повторите компановку снова, используя опцию /SEGMENTS для задания меньше- го количества сегментов (например, 64, если ранее было исполь- зовано стандартное значение), либо освободите некоторое коли- чество памяти путем удаления резидентных программ или паралле- льных задач. L1056 "Слишком много оверлеев". В программе определно более 63 оверлеев. L1057 "Запись данных слишком велика". Запись LIDATA (в объектном модуле) содержит более 1024 байтов данных. Это ошибка транслятора. (LIDATA-это термин операционной системы DOS, его объяснение можно найти в документе "Справочное руководство программиста по MS-DOS фирмы Microsoft" или в дру- гих справочных книгах по DOS. Обратите внимание, какой транслятор (компилятор или ассемблер) построил некорректный объектный модуль и при каких обстоятель- ствах. Пожалуйста, сообщите о данной ошибке, используя форму Product Assistance Request, находящуюся в конце данного руко- водства. L1070 "'name': размер сегмента превышает 64К". Заданный сегмент содержит более 64К кода или данных. Повторите компиляцию и компановку в большой модели памяти. L1071 "Сегмент _TEXT больше 65520 байтов". Данная ошибка вероятнее всего может случиться только в СИ-прог- раммах малой модели памяти, однако она может произойти и, если любая программа с сегментом, названным _TEXT, компануется пос- редством команды LINK с опцией /DOSSEG. Программы на языке СИ малой модели памяти должны резервировать адреса кода 0 и 1; для целей выравнивания этот предел увеличивается до 16. L1072 "Общая область больше 65536 байтов". Программа имеет более 64 общих переменных. Данная ошибка не мо- жет возникнуть в объектных файлах, сгенерированных с помощью Макроассемблера MASM (Microsoft Macro Assembler). Она возникает только в программах, полученных с помощью компилятороа, поддер- живающих общие переменные. L1080 "Невозможно открыть файл-листинг". Диск или корневой каталог переполнены. Удалите или переместите файлы, чтобы освободить место. L1081 "Переполнение при записи выполняемого файла". Диск, на который записывается выполняемый файл .EXE, переполнен Освободите место на диске и повторите компановку. L1083 "Невозможно открыть выполняемый файл". Диск или корневой каталог переполнены. Удалите или переместите файлы, чтобы освободить место. L1084 "Невозможно создать временный файл". Диск или корневой каталог переполнены. Освободите место на диске и повторите компановку. L1085 "Невозможно открыть временный файл". Диск или корневой каталог переполнены. Удалите или переместите файлы, чтобы освободить место. L1086 "Не хватает временного файла". Заметьте обстоятельства возникновения данной ситуации и свяжи- тесь с фирмой Microsoft Corporation, воспользовавшись формой "Product Assitance Request", находящейся в конце данного руко- водства. L1087 "Неожиданный конец временного файла". Диск с временным выходным файлом компановщика удален. L1088 "Переполнение при записи файла-листинга". При записи на диск файла-листинга диск переполнился. Освободите место на диске и повторите компановку. L1089 "'filename': невозможно открыть файл соответствий". Программа LINK не может найти заданный файл соответствий. Обыч- но, это опечатка при задании имени файла. L1090 "Повторно открыть файл-листинг невозможно" По запросу оригинальный диск не был заменен. Повторите компа- новку. L1091 "Неожиданный конец файла в библиотеке". Диск, содержащий библиотеку, был вероятно, удален. Установите диск, содержащий библиотеку и повторите компановку. L1093 "'filename':объектный файл не найден". Компановщик не может найти заданного объектного файла. Задайте правильное имя объектного файла и повторите компановку. L1101 "Некорректный объектный модуль". Один из объектных модулей является некорректным. Если данная ошибка произошла после перекомпиляции, пожалуйста, свяжитесь с фирмой Microsoft Corporation, воспользовавшись формой "Product Assitance Request", приложенной в конце данного руководства. L1102 "Неожиданный конец файла". Для библиотеки был обнаружен некорректный формат. L1103 "Попытка обращения к данным, лежащим за границами сегмента". Заданная запись в объектном модуле продолжена за границы сег- мента. Это ошибка транслятора. Заметьте, какой транслятор (ком- пилятор или ассемблер) создал некорректный объектный модуль, и обстоятельства, в которых он был создан. Пожалуйста, сообщите о данной ситуации в фирму Microsoft Corporation, воспользовав- шись формой "Product Assistance Request", находящейся в конце данного руководства. L1104 "'filename': некорректная библиотека". Заданный файл не является корректным библиотечным файлом. Дан- ная ошибка прекращает работу программы LINK. L1113 "Неразрешенная COMDEF; системная ошибка". Заметьте обстоятельства возникновения данного сбоя и свяжитесь с фирмой Microsoft Corporation, воспользовавшись формой Product Assistance Request, находящейся в конце данного руководства. L1114 "Файл не подходит для /EXEPACK; повторите компановку без опции /EXEPACK". В компануемой программе размер упакованного загружаемого обра- за плюс заголовок больше, чем неупакованный загружаемый образ. Повторите компановку с помощью опции /EXEPACK. L2001 "Запись fixup без данных". Запись FIXUPP не имеет непосредственно предшествующей записи данных. Вероятно, это ошибка компилятора. (Подробности о FIXUPP смотрите в документе "Справочное руководство программис- та по MS-DOS фирмы Microsoft"). L2002 "Переполнение записи fixup при "ближнем" вызове 'number' frame seg 'segname' target seg 'segname' target offset 'number'" Данную ошибку могут вызвать следующие условия: -Программа компилируется в малой модели памяти с опцией /NT. -Группа больше 64К. -Программа содержит междусегментные короткие переходы или меж- дусегментные короткие вызовы. -Имя элемента данных в программе не соответствует процедуре из библиотеки процедур, подключенной к компановке. -Объявление EXTRN в исходном файле на яхыке ассемблер появилось в теле сегмента, как в следующем примере: code SEGMENT public 'CODE' EXTRN main:far start PROC far call main ret start ENDP code ENDS Предпочтительна следующая конструкция: EXTRN main:far code SEGMENT public 'CODE' start PROC far call main start ENDP code ENDS Перепишите исходный файл и перестройте объектный файл. (Подроб- ную информация о frame segment и target segment вы найдете в документе "Справочное руководство программиста по MS-DOS фирмы Microsoft".) L2003 "Дальний вызов на данные собственного сегмента". Дальние вызовы на данные собственного сегмента не разрешаются. L2005 "Тип fixup не поддерживается". Оказалось, что тип fixup не поддерживается компановщиком фирмы Microsoft. Вероятно, это ошибка компилятора. Обратите внимание на обстоятельства данной ошибки и сообщите их в фирму Microsoft Corporation, воспользовавшись формой "Product Assistance Request", находящейся в конце данного руководства. L2012 "'name': несоответствие размера элемента массива". "Дальний" общий массив был описан с двумя или более различны- ми размерами элементов массива (например, первый раз массив был описан, как массив символов, а второй раз, как массив дейст- вительных чисел). L2013 "Запись LIDATA слишком велика". Запись LIDATA в объектном модуле имеет размер более 512 байтов, максимально разрешенного размера. Это ошибка компилятора. По- жалуйста, сообщите об условиях возникновения данной ошибки в фирму Microsoft, воспользовавшись формой "Product Assistance Request" в конце данного руководства. L2024 "'name': имя уже определено". Одно из специальных оверлейных имен, требуемое для поддержки оверлеев, было определено в объектном файле. L2025 "'name': имя определено более одного раза". Удалите из объектного файла лишние определения имен. L2029 "Неразрешенные внешние ссылки". В одном или более модулей одно или более имен описаны, как внешние, но они не были определены, как публичные ни в одном из модулей или библиотек. После сообщения появляется список нераз- решенных внешних ссылок, как показано в следующем примере: EXIT in file(s): MAIN.OBJ (main.for) OPEN in file(s): MAIN.OBJ (main.for) Имя, которое идет перед 'in file(s)'-это неразрешенное внешнее имя. На следующей строке-список объектных модулей, имеющих ссы- лки на данное имя. Это сообщение и список записываются также в файл карты распределения памяти, если он существует. L2041 "Стэк плюс данные превышает 64К". Общий размер стэкового сегмента программы плюс DGROUP превышает 64К; в результате, программа загружается неверно. L2043 "Стартовый адрес__ aulstart не найден". Если вы строите библиотеку Quick с использованием опции /Q, компановщик требует имя __aulstart, определенное, как стар- товый адрес. L4003 "Неразрешенный вызов: смещение offset". Данная ошибка может быть вызвана компиляцией программы в малой модели памяти с опцией /NT. L4012 "Опция /HIGH отменяет /EXEPACK". Опции /HIGH и /EXEPACK не могут быть использованы одновременно. L4015 "Опция /CODEVIEW отменяет /DSALLOCATE". Опции /CODEVIEW и /DSALLOCATE не могут быть использованы одно- временно. L4016 "Опция /CODEVIEW отменяет /EXEPACK". Опции /CODEVIEW и /EXEPACK не могут быть использованы одно- временно. L4020 "'name': размер сегмента кода превышает 65500". Сегмент кода размером 65501-65536 байтов в длину может на про- цессоре Intel 80286 быть обработан некорректно. L4021 "Нет стэкового сегмента". Программа не имеет стэкового сегмента, определенного с типом STACK. Данное сообщение не возникнет при обработке модулей, скомпилированных с помощью компилятора Microsoft Quick-C, но не с помощью Макроассемблера. Обычно, каждая программа должна иметь стэковый сегмент с типом объединения STACK. Если у вас есть особые причины не определять стэк или определить его без типа объединения STACK, вы можете проигнорировать данное сообщение. Данное сообщение может быть получено и при компановке с помощью LINK версий 2.40 и младше, поскольку данные компановщики просматривают библиотеки только один раз. L4031 "'name': сегмент описан более, чем в одной группе". Сегмент был описан, как член двух различных групп. Исправьте исходный файл и перестройте объектные файлы. L4034 "Более 239 оверлейных сегментов; лишние помещены в корень". В оверлеях не может быть объявлено более 239 кодовых сегментов. Все сегменты свыше данного предела помещаются в корень. L4045 "Имя выходного файла 'name'". Компановщик высветил в запросе "Run file" стандартное выходное имя файла, но поскольку была использована опция /Q, имя выход- ного файла было изменено. L4050 "Слишком много глобальных имен". Для получения отсортированного списка глобальных имен в файле распределения памяти была использована опция /MAP, но задано для сортировки слишком много имен (более 2048 имен по умолча- нию). Повторите компановку с опцией /MAP:number. Компановщик выдает неотсортированный список глобальных имен. L4051 "'filename': невозможно найти библиотеку". Компановщик не может найти заданный файл. Введите новое имя, новую спецификацию маршрута, или и то, и другое. L4053 "VM.TMP: некорректное имя файла; игнорируется". Имя VM.TMP появилось, как объектное имя файла. Переименуйте файл и повторите компановку. L4054 "'filename': невозможно найти файл". Компановщик не может найти заданный файл. Введите новое имя файла, новую спецификацию маршрута, либо и то, и другое. 

D.5.Сообщения об ошибках утилиты LIB.

Сообщения об ошибках, сгенерированные администратором библиотек, программой LIB, имеет один из следующих форматов:

 {filename|LIB}: fatal error U1xxx: текст сообщения {filename|LIB}: error U2xxx: текст сообщения {filename|LIB}: warning U4xxx: текст сообщения 

Сообщение начинается именем входного файла (filename), если он существует, либо именем утилиты. Если возможно, программа LIB распечатывает предупреждение и продолжает работу. В некоторых случаях ошибки неисправимы и утилита LIB прекращает работу. Утилита LIB может высветить следующие сообщения:

Номер Сообщения об ошибках утилиты LIB U1150 "Размер страницы слишком мал". Размер страницы входной библиотеки слишком мал, что означает некорректный входной файл .LIB. U1151 "Синтаксическая ошибка: неверная спецификация файла". Командный оператор, такой как знак минус(-) был задан без соот- ветствующего имени модуля. U1152 "Синтаксическая ошибка: наименование опции опущено". Знак опции слэш (/) был задан без следующей за ним опции. U1153 "Синтаксическая ошибка: значение опции пропущено". Опция /PAGESIZE была задана без соответствующего значения. U1154 "Неизвестная опция". Была задана неизвествная опция. В данный момент программа LIB распознает только опции /PAGESIZE. U1155 "Синтаксическая ошибка: некорректный ввод". Данная команда не следует правильному синтаксису утилиты LIB, описанному в Главе 10, "Создание библиотек Quick и автономных библиотек". U1156 "Синтаксическая ошибка". Данная команда не следует правильному синтаксису утилиты LIB, описанному в Главе 10, "Создание библиотек Quick и автономных библиотек". U1157 "Пропущена запятая или символ перехода на новую строку". В командной строке ожидалась запятая или возврат каретки, кото- рые не появились. Это может означать нечаянно поставленную запятую, как в следующей строке: LIB math.lib, -mod1+mod2; Эта строка должна иметь следующий вид: LIB math.lib -mod1+mod2; U1158 "Пропущен возврат каретки". Либо ответ на запрос "Output library", либо последняя строка в файле соответствий, используемого для запуска программы LIB, не заканчивается возвратом каретки. U1161 "Невозможно переименовать старую библиотеку". Программа LIB не может переименовать старую библиотеку с рас- ширением .BAK, поскольку версия .BAK уже существует с защитой "только-чтение". Измените защиту старой версии .BAK. U1162 "Невозможно повторно открыть библиотеку". Старая библиотека не может быть повторно открыта после того, как она была переименована с расширением .BAK. U1163 "Ошибка при записи файла перекрестных ссылок". Диск или корневая директория переполнены. Удалите или переком- пилируйте файлы, чтобы освободить место. U1170 "Слишком много имен". В библиотечном файле появилось более 4609 имен. U1171 "Не хватает памяти". Программе LIB не хватает памяти для работы. Удалите параллель- ные и резидентные программы и повторите попытку, либо увеличьте память. U1172 "Не хватает виртуальной памяти". Заметьте обстоятельства данного сбоя и уведомите фирму Microsoft Corporation, воспользовавшись формой "Product Assistance Request", находящейся в конце данного руководства. U1173 "Системный сбой". Обратите внимание на обстоятельства данного сбоя и уведомите фирму Microsoft Corporation, воспользовавшись формой "Product Assistance Request", находящейся в конце данного руководства. U1174 "mark: не размещено". Заметьте обстоятельства данного сбоя и уведомите фирму Microsoft Corporation, воспользовавшись формой "Product Assistance Request", находящейся в конце данного руководства. U1175 "free: не размещено". Заметьте обстоятельства данного сбоя и известите фирму Microsoft Corporation, воспользовавшись формой "Product Assistance Request", находящейся в конце данного руководства. U1180 "Запись извлекаемого файла потерпела неудачу". Диск или корневой каталог переполнены. Удалите или перемес- тите файлы, чтобы освободить место. U1181 "Запись в библиотечный файл потерпела неудачу". Диск или корневой каталог переполнены. Удалите или перемес- тите файлы, чтобы освободить место. U1182 "'filename': невозможно создать извлекаемый файл". Диск или корневой каталог переполнены, либо заданный извлекае- мый файл уже существует с защитой "только-чтение". Освободите место на диске, либо измените вид защиты файла. U1183 "Невозможно открыть файл соответствий". Данный файл соответствий не найден. U1184 "Неожиданный конец файла при вводе команды". В ответе на запрос был обнаружен символ конца файла. U1185 "Невозможно создать новую библиотеку". Диск или корневой каталог переполнены, либо библиотечный файл уже существует с защитой "только-чтение". Освободите место на диске или измените атрибуты защиты библиотечного файла. U1186 "Ошибка при записи новой библиотеки". Диск или корневой каталог переполнены. Удалите или переместите файлы для освобождения места. U1187 "Невозможно открыть VM.TMP". Диск или корневой каталог переполнены. U1188 "Невозможно записать в VM". Отметьте обстоятельства возникновения данного сбоя и сообщите в фирму Microsoft Corporation, воспользовавшись бланком "Product Assistance Request", находящейся в конце данного руко- водства. U1189 "Невозможно прочесть из VM". Обратите внимание на обстоятельства возникновения данной ошибки и сообщите в фирму Microsoft Corporation, воспользовавшись бланком "Product Assistance Request", находящейся в конце данного руководства. U1190 "Прервано пользователем". Вы прервали работу программы LIB до завершения работы. U1200 "'name': некорректный заголовок библиотеки". Входной библиотечный файл имеет неправильный формат. Он либо не является библиотечным файлом, либо разрушен. U1203 "'name': некорректный объектный модуль по ближнему адресу". Модуль, заданный по имени 'name', является некорректным объект- ным модулем. U2152 "'filename': невозможно создать листинг". Диск или каталог переполнены, либо файл перекрестных ссылок уже существует с защитой "только-чтение". Освободите место на диске, либо измените атрибуты файла. U2155 "'modulename': модуль не найден в библиотеке; игнорируется". Заданный модуль не найден во входной библиотеке U2157 "'filename': невозможно получить доступ к файлу". Программа LIB не могла открыть заданный файл. U2158 "'libraryname': неверный заголовок библиотеки; файл игнориру- ется". Входная библиотека имеет некорректный формат. U2159 "'filename': неверный формат 'hexnumber'; файл игнорируется". Опознавательный байт слова 'hexnumber' данного файла не имеет одного из следующих распознаваемых типов: библиотека Microsoft, библиотека Intel, объектный файл Micro- soft, архив XENIX. U4150 "'modulname': переопределение модуля игнорируется". Модуль был определен для добавления в библиотеку, но модуль с тем де именем уже есть в библиотеке. Либо, модуль с одним и тем же именем помещен в библиотеку дважды. U4151 "'symbol (modulename): переопределение имени игнорируется". Заданное имя определено более, чем в одном модуле. U4153 "'number': размер страницы слишком мал; игнорируется". Значение, определенное в опции /PAGESIZE меньше 16. U4156 "'libraryname': спецификация выходной библиотеки игнорируется". В дополнение к новому библиотечному имена была задана выходная библиотека. Например, задав: LIB new.lib+one.obj, new.lst,new.lib где new.lib еще не существует-вы получите ошибку. 

D.6. Сообщения об ошибках утилиты MAKE.

Ошибки, высвечиваемые в процессе работы утилиты поддержки программ Microsoft (MAKE) имеют один из следующих форматов:

 {filename|MAKE}: fatal error U1xxx: текст сообщения {filename|MAKE}: warning U4xxx: текст сообщения 

Сообщения начинаются с имени входного файла (filename), если он существует, либо с имени утилиты. Если возможно, утилита MAKE печатает предупреждение и продолжает работу. В некоторых случаях ошибки являются неисправимыми и утилита MAKE прекращает работу. Сообщения, генерируемые утилитой MAKE, перечислены в данном разделе.

Номер Сообщения об ошибках утилиты MAKE U1001 "Макроопределение больше, чем number". Было определено макро, имеющее значение строки, длинее установ- ленного числа, разрешающего максимальную длину. Попытайтесь пе- реписать файл описанний утилиты MAKE и расщепить макро на два меньших. U1002 "Бесконечно рекурсивное макро". Был определен циклический вызов макрокоманд, как в следующем примере: A=$(B) B=$(C) C=$(A) U1003 "Выход за пределы памяти". Во время обработки файла описаний утилита MAKE вышла за пределы памяти. Попытайтесь сократить размер файла описаний утилиты MAKE путем его реорганизации или расщепления на меньшие. U1004 "Синтаксическая ошибка: пропущено имя макрокоманды". Файл описаний утилиты MAKE содержит макроопределение без левой части (то есть строки, начинающейся с =). U1005 "Синтаксическая ошибка: пропущено двоеточие". В строке, которая должна содержать выходной файл/входной файл, не хватает двоеточия, разделяющего выходной файл и входной файл. Утилита MAKE требует любую строку, за которой следует пустая строка, чтобы считать ее строкой выходного/входного фай- ла. U1006 "'targetname': макрорасширение больше числа 'number'". Макрорасширение плюс длина любой строки, с которой оно может быть объединено, длинее установленного числа. Попытайтесь пере- записать файл описаний утилиты MAKE, расшепив макро на два ме- ньших. U1007 "Много источников". Правило вывода были определено более одного раза. U1008 "'name': невозможно найти файл или каталог". Заданные файл или каталог не могут быть найдены. U1009 "'command': список аргументов слишком длинный". Командная строка в файле описаний утилиты MAKE длиннее 128 бай- тов, что максимально разрешено в DOS. Перепишите команды, чтобы сделать список аргументов короче. U1010 "'filename': отказ доступа". Файл, определенный, как 'filename'-имеет атрибут "только-чте- ние. U1011 "'filename': не хватает памяти". Для выполнения программы утилите MAKE не хватает памяти. U1012 "'filename': неизвестная ошибка". Заметьте обстоятельства возникновения данной ошибки и сообщите о них фирме Microsoft Corporation, воспользовавшись бланком "Product Assistance Request", данным в конце данного руко- водства. U1013"'command': ошибка errcode". Одна из программ или команд, вызванная в файле описаний утилиты MAKE, завершилась с ненулевым кодом завершения. U1015 "'file': целевой файл не существует". Обычно, это не означает ошибку. Данное сообщение предупреждает пользователя о том, что целевой файл не существует. Утилита MAKE выполняет любые команды, заданные в блоке описаний, поско- льку в большинстве случаев выходной файл создается последней командой файла описаний утилиты MAKE. U4000 "'filename': не существует". Обычно, это сообщение не свидетельствует об ошибке. Оно пре- дупреждает пользователя о том, что указанный файл не существует MAKE выполняет все команды, заданные в блоке, так как в боль- шистве случаев отсутствующий файл будет создан последующими командами файла MAKE. U4001 "Зависимый файл 'filename' не существует; целевой файл 'filena me' не строится". Утилита MAKE не может продолжать, поскольку требуемый входной файл не существует. Удостоверьтесь, что все имена файлов при- сутствуют и что все они корректно описываются в файле описаний утилиты MAKE. U4013 "'command': ошибка errcode (игнорируется)". Одна из программ или команд, вызванных в файле описаний утилиты MAKE, возвратила ненулевой код ошибки, в то время, как утилита MAKE работала с опцией /I. Ошибки игнорируются и утилита про- должает работу. U4014 "Синтаксис: make options [name-value...] file options=[/n] [/d][/i][/s][/x file] Утилита MAKE была неправильно вызвана. Стартуйте утилиту зано- во, воспользовавшись синтаксисом, представленным в сообщении: make опции[имя-значение...] file опции=[/n][/d][/i][/s] [/x file]. 

Я регулярно проверяю различные открытые проекты, чтобы продемонстрировать возможности статического анализатора кода PVS-Studio (C, C++, C#). Настало время компилятора GCC. Бесспорно, GCC — это очень качественный и оттестированный проект, поэтому найти в нём хотя бы несколько ошибок уже большое достижение для любого инструмента. К моей радости, PVS-Studio справился с этой задачей. Никто не застрахован от опечаток и невнимательности. Именно поэтому PVS-Studio может стать вашей дополнительной линией обороны на фронте бесконечной войны с багами.

GCC

GNU Compiler Collection (обычно используется сокращение GCC) — набор компиляторов для различных языков программирования, разработанный в рамках проекта GNU. GCC является свободным программным обеспечением, распространяется фондом свободного программного обеспечения на условиях GNU GPL и GNU LGPL и является ключевым компонентом GNU toolchain. Проект написан на языке C и C++.

Компилятор GCC имеет хорошие встроенные диагностики, помогающие выявлять многие ошибки на этапе компиляции. Естественно, GCC собирается с помощью GCC и, соответственно, может выявлять ошибки в собственном коде. Дополнительно исходный код GCC проверяется с помощью анализатора Coverity. Да и вообще, думаю GCC проверялся энтузиастами с помощью многих анализаторов и других инструментов. Это делает поиск ошибок в GCC большим испытанием для анализатора кода PVS-Studio.

Для анализа была взята trunk версия из git-репозитория: (git) commit 00a7fcca6a4657b6cf203824beda1e89f751354b svn+ssh://gcc.gnu.org/svn/gcc/trunk@238976

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

Предвидя дискуссию

Как я сказал во введении, я считаю GCC проектом с высоким качеством кода. Уверен, многие захотят поспорить. В качестве примера приведу цитату из Wikipedia на русском языке:

Некоторые разработчики OpenBSD, например Тео де Раадт и Отто Мурбек (Otto Moerbeek), критикуют GCC, называя его «громоздким, глючным, медленным и генерирующим плохой код».

Я считаю такие заявления необоснованными. Да, возможно, код GCC содержит много макросов, которые затрудняют его чтение. Но я никак не могу согласиться с заявлением о его глючности. Если бы GCC глючил, вообще бы нигде ничего не работало. Вы только вспомните, как много программ им компилируется и успешно работает. Создатели GCC делают огромную, сложную работу с большим профессионализмом. Спасибо им. Я рад, что могу протестировать работу PVS-Studio на таком высококачественном проекте.

Для тех, кто скажет, что код компилятора Clang всё равно круче, напомню: в нём PVS-Studio также находил ошибки: 1, 2.

PVS-Studio

Я проверил код GCC с помощью Alpha-версии анализатора PVS-Studio for Linux. Мы планируем начать выдавать заинтересовавшимся программистам Beta-версию анализатора в середине сентября 2016 года. Инструкцию о том, как стать одним из первых, кто сможет попробовать Beta-версию PVS-Studio for Linux на своём проекте, вы найдете в статье «PVS-Studio признаётся в любви к Linux».

Если вы читаете эту статью гораздо позже, чем сентябрь 2016, и хотите попробовать PVS-Studio for Linux, то приглашаю вас на страницу продукта: http://www.viva64.com/ru/pvs-studio/

Результаты проверки

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

К сожалению, я не могу выдать разработчикам компилятора полный отчёт. В нем пока слишком много мусора (ложных срабатываний), связанных с тем, что анализатор не полностью готов к встрече с миром Linux. Нужно проделать работу по уменьшению количества ложных предупреждений на типовые используемые конструкции. Попробую пояснить на одном простом примере. Многие диагностики не должны ругаться на выражения, относящиеся к макросам assert. Эти макросы бывают устроены весьма творчески и надо научить анализатор не обращать на них внимание. Но дело в том, что определяется макрос assert очень по-разному, и надо обучить анализатор всем типовым вариантам.

Поэтому разработчиков GCC прошу подождать выхода по крайней мере Beta-версии анализатора. Я не хочу испортить впечатление отчетом, сгенерированным недоделанной версией.

Классика (Copy-Paste)

Начнем мы с самой классической и распространённой ошибки, которая выявляется с помощью диагностики V501. Как правило, такие ошибки появляются из-за невнимательности при Copy-Paste или просто являются опечатками, допускаемыми при наборе нового кода.

static bool
dw_val_equal_p (dw_val_node *a, dw_val_node *b)
{
  ....
  case dw_val_class_vms_delta:
    return (!strcmp (a->v.val_vms_delta.lbl1,
                     b->v.val_vms_delta.lbl1)
            && !strcmp (a->v.val_vms_delta.lbl1,
                        b->v.val_vms_delta.lbl1));
  ....
}

Предупреждение анализатора PVS-Studio: V501 There are identical sub-expressions ‘!strcmp(a->v.val_vms_delta.lbl1, b->v.val_vms_delta.lbl1)’ to the left and to the right of the ‘&&’ operator. dwarf2out.c 1428

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

Функция strcmp дважды сравнивает одни и те же строки. Мне кажется, второй раз следовало сравнивать не члены класса lbl1, а lbl2. Тогда корректный код должен выглядеть так:

return (!strcmp (a->v.val_vms_delta.lbl1,
                 b->v.val_vms_delta.lbl1)
        && !strcmp (a->v.val_vms_delta.lbl2,
                    b->v.val_vms_delta.lbl2));

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

Ошибки, возможно, удалось бы избежать, если использовать «табличное» выравнивание кода. Например, ошибку было бы легче заметить, если отформатировать код так:

Подробнее я рассматривал такой подход в электронной книге «Главный вопрос программирования, рефакторинга и всего такого» (см. главу N13: Выравнивайте однотипный код «таблицей»). Рекомендую всем, кто заботится о качестве своего кода, познакомиться с приведённой здесь ссылкой.

Давайте рассмотрим ещё одну ошибку, которая, я уверен, появилась из-за Copy-Paste:

const char *host_detect_local_cpu (int argc, const char **argv)
{
  unsigned int has_avx512vl = 0;
  unsigned int has_avx512ifma = 0;
  ....
  has_avx512dq = ebx & bit_AVX512DQ;
  has_avx512bw = ebx & bit_AVX512BW;
  has_avx512vl = ebx & bit_AVX512VL;       // <=
  has_avx512vl = ebx & bit_AVX512IFMA;     // <=
  ....
}

Предупреждение анализатора PVS-Studio: V519 The ‘has_avx512vl’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 500, 501. driver-i386.c 501

В переменную has_avx512vl дважды подряд записываются различные значения. Это не имеет смысла. Я изучил код и обнаружил переменную has_avx512ifma. Скорее всего, именно она и должна инициализироваться выражением ebx & bit_AVX512IFMA. Тогда корректный код должен быть таким:

has_avx512vl   = ebx & bit_AVX512VL;    
has_avx512ifma = ebx & bit_AVX512IFMA;

Опечатка

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

static bool
ubsan_use_new_style_p (location_t loc)
{
  if (loc == UNKNOWN_LOCATION)
    return false;

  expanded_location xloc = expand_location (loc);
  if (xloc.file == NULL || strncmp (xloc.file, "1", 2) == 0
      || xloc.file == '' || xloc.file[0] == 'xff'
      || xloc.file[1] == 'xff')
    return false;

  return true;
}

Предупреждение анализатора PVS-Studio: V528 It is odd that pointer to ‘char’ type is compared with the » value. Probably meant: *xloc.file == ». ubsan.c 1472

Здесь программист случайно забыл разыменовать указатель в выражении xloc.file == ». В результате указатель просто сравнивается с 0, т.е. с NULL. Никакого эффекта это не имеет, так как ранее такая проверка уже выполнялась: xloc.file == NULL.

Хорошо, что терминальный ноль программист записал как ». Это помогает быстрее понять, что код ошибочен и как его надо исправить. Про это я также писал в книге (см. главу N9: Используйте для обозначения терминального нуля литерал »).

Правильный вариант кода:

if (xloc.file == NULL || strncmp (xloc.file, "1", 2) == 0
    || xloc.file[0] == '' || xloc.file[0] == 'xff'
    || xloc.file[1] == 'xff')
  return false;

Хотя, давайте ещё немного улучшим код. Я рекомендую отформатировать выражение так:

if (   xloc.file == NULL
    || strncmp (xloc.file, "1", 2) == 0
    || xloc.file[0] == ''
    || xloc.file[0] == 'xff'
    || xloc.file[1] == 'xff')
  return false;

Обратите внимание: теперь, если допустить ту же ошибку, шанс её заметить будет чуть-чуть выше:

if (   xloc.file == NULL
    || strncmp (xloc.file, "1", 2) == 0
    || xloc.file == ''
    || xloc.file[0] == 'xff'
    || xloc.file[1] == 'xff')
  return false;

Потенциальное разыменование нулевого указателя

Ещё этот раздел можно было бы назвать «стотысячный пример, почему макросы — это плохо». Я очень не люблю макросы и всегда призываю поменьше их использовать. Макросы затрудняют чтение кода, провоцируют появление ошибок, усложняют работу статическим анализаторам. Как мне показалось из недолгого общения с кодом GCC, его авторы очень любят макросы. Я замучался изучать, во что раскрывается тот или иной макрос и возможно поэтому пропустил немало интересных ошибок. Признаюсь, я иногда бываю ленив. Но пару ошибок, связанных с макросами, я всё-таки продемонстрирую.

odr_type
get_odr_type (tree type, bool insert)
{
  ....
  odr_types[val->id] = 0;
  gcc_assert (val->derived_types.length() == 0);
  if (odr_types_ptr)
    val->id = odr_types.length ();
  ....
}

Предупреждение анализатора PVS-Studio: V595 The ‘odr_types_ptr’ pointer was utilized before it was verified against nullptr. Check lines: 2135, 2139. ipa-devirt.c 2135

Видите здесь ошибку? Думаю, нет, и сообщение анализатора ясности не вносит. Всё дело в том, что odr_types — это не имя переменной, а макрос, объявленным следующим образом:

#define odr_types (*odr_types_ptr)

Если раскрыть макрос и убрать всё не относящееся к делу, мы получим следующий код:

(*odr_types_ptr)[val->id] = 0;
if (odr_types_ptr)

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

Рассмотрим ещё один аналогичный случай:

static inline bool
sd_iterator_cond (sd_iterator_def *it_ptr, dep_t *dep_ptr)
{
  ....
  it_ptr->linkp = &DEPS_LIST_FIRST (list);
  if (list)
    continue;
  ....
}

Предупреждение анализатора PVS-Studio: V595 The ‘list’ pointer was utilized before it was verified against nullptr. Check lines: 1627, 1629. sched-int.h 1627

Чтобы увидеть ошибку, нам опять потребуется показать устройство макроса:

#define DEPS_LIST_FIRST(L) ((L)->first)

Раскрываем макрос и получаем:

it_ptr->linkp = &((list)->first);
if (list)
  continue;

И сейчас многие воскликнут: «Стоп, стоп! Здесь нет ошибки. Мы ведь просто получаем указатель на член класса. Никакого разыменования нулевого указателя здесь нет. Да, возможно код не аккуратен, но ошибки здесь нет!».

Всё не так просто. Здесь возникает неопределённое поведение. И то, что такой код может работать на практике, это просто везение. На самом деле, так писать нельзя. Например, оптимизирующий компилятор, увидев list->first, может удалить проверку if (list). Раз мы выполняли оператор ->, значит предполагается, что указатель не равен nullptr. Если это так, то проверять указатель не нужно.

Я написал целую статью на эту тему: «Разыменовывание нулевого указателя приводит к неопределённому поведению». Там как раз рассматривается аналогичный случай. Прежде чем спорить, прошу внимательно познакомиться с этой статьёй.

Впрочем, рассмотренная ситуация действительно сложна и неочевидна. Я допускаю, что могу быть всё-таки неправ и ошибки здесь нет. Однако, до сих пор мне никто не смог это доказать. Будет интересно услышать комментарии разработчиков GCC, если они обратят внимание на эту статью. Уж они-то точно должны знать, как работает компилятор и следует ли интерпретировать такой код как ошибочный, или нет.

Использование разрушенного массива

static void
dump_hsa_symbol (FILE *f, hsa_symbol *symbol)
{
  const char *name;
  if (symbol->m_name)
    name = symbol->m_name;
  else
  {
    char buf[64];
    sprintf (buf, "__%s_%i", hsa_seg_name (symbol->m_segment),
       symbol->m_name_number);
     name = buf;
  }
  fprintf (f, "align(%u) %s_%s %s",
           hsa_byte_alignment (symbol->m_align),
           hsa_seg_name(symbol->m_segment),
           hsa_type_name(symbol->m_type & ~BRIG_TYPE_ARRAY_MASK),
           name);
  ....
}

Предупреждение анализатора PVS-Studio: V507 Pointer to local array ‘buf’ is stored outside the scope of this array. Such a pointer will become invalid. hsa-dump.c 704

Строка формируется во временном буфере buf. Адрес этого временного буфера сохраняется в переменной name и используется далее в теле функции. Ошибка в том, что после записи буфера в переменную name, сам этот буфер будет уничтожен.

Использовать указатель на разрушенный буфер нельзя. Формально мы имеем дело с неопределённым поведением. На практике этот код может вполне успешно работать. Корректная работа программы — это один из вариантов проявления неопределенного поведения.

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

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

static void
dump_hsa_symbol (FILE *f, hsa_symbol *symbol)
{
  const char *name;
  char buf[64];
  ....
}

Выполнение одинаковых действий, независимо от условия

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

bool
thread_through_all_blocks (bool may_peel_loop_headers)
{
  ....
  /* Case 1, threading from outside to inside the loop
     after we'd already threaded through the header.  */
  if ((*path)[0]->e->dest->loop_father
      != path->last ()->e->src->loop_father)
  {
    delete_jump_thread_path (path);
    e->aux = NULL;
    ei_next (&ei);
  }
  else
  {
    delete_jump_thread_path (path);
    e->aux = NULL;
    ei_next (&ei);
  }
  ....
}

Предупреждение анализатора PVS-Studio: V523 The ‘then’ statement is equivalent to the ‘else’ statement. tree-ssa-threadupdate.c 2596

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

Избыточное выражение вида (A == 1 || A != 2)

static const char *
alter_output_for_subst_insn (rtx insn, int alt)
{
  const char *insn_out, *sp ;
  char *old_out, *new_out, *cp;
  int i, j, new_len;

  insn_out = XTMPL (insn, 3);

  if (alt < 2 || *insn_out == '*' || *insn_out != '@')
    return insn_out;
  ....
}

Предупреждение анализатора PVS-Studio: V590 Consider inspecting this expression. The expression is excessive or contains a misprint. gensupport.c 1640

Нас интересует условие: (alt < 2 || *insn_out == ‘*’ || *insn_out != ‘@’)

Его можно сократить до: (alt < 2 || *insn_out != ‘@’)

Рискну предположить, что оператор != следует заменить на ==. Тогда код примет более осмысленный вид:

if (alt < 2 || *insn_out == '*' || *insn_out == '@')

Обнуление не того указателя

Рассмотрим функцию, занимающуюся освобождением ресурсов:

void
free_original_copy_tables (void)
{
  gcc_assert (original_copy_bb_pool);
  delete bb_copy;
  bb_copy = NULL;
  delete bb_original;
  bb_copy = NULL;
  delete loop_copy;
  loop_copy = NULL;
  delete original_copy_bb_pool;
  original_copy_bb_pool = NULL;
}

Предупреждение анализатора PVS-Studio: V519 The ‘bb_copy’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 1076, 1078. cfg.c 1078

Обратите внимание на эти 4 строчки кода:

delete bb_copy;
bb_copy = NULL;
delete bb_original;
bb_copy = NULL;

Случайно дважды обнуляется указатель bb_copy. Правильный вариант:

delete bb_copy;
bb_copy = NULL;
delete bb_original;
bb_original = NULL;

Assert, который ничего не проверят

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

static void
output_loc_operands (dw_loc_descr_ref loc, int for_eh_or_skip)
{
  unsigned long die_offset
    = get_ref_die_offset (val1->v.val_die_ref.die);
  ....
  gcc_assert (die_offset > 0
        && die_offset <= (loc->dw_loc_opc == DW_OP_call2)
             ? 0xffff
             : 0xffffffff);
  ....
}

Предупреждение анализатора PVS-Studio: V502 Perhaps the ‘?:’ operator works in a different way than it was expected. The ‘?:’ operator has a lower priority than the ‘<=’ operator. dwarf2out.c 2053

Приоритет тернарного оператора ?: ниже, чем у оператора сравнения <=. Это значит, что мы имеем дело с условием вида:

die_offset > 0 &&
  ((die_offset <= (loc->dw_loc_opc == DW_OP_call2)) ?
    0xffff : 0xffffffff);

Таким образом, второй операнд оператора && может принимать значение 0xffff или 0xffffffff. Оба эти значения обозначают истину, поэтому выражение можно упростить до:

(die_offset > 0)

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

gcc_assert (die_offset > 0
      && die_offset <= ((loc->dw_loc_opc == DW_OP_call2)
           ? 0xffff
           : 0xffffffff));

Оператор ?: очень коварен и его лучше не использовать в сложных выражениях. Уж очень легко допустить ошибку. У нас собрано большое количество примеров таких ошибок, найденных анализатором PVS-Studio в различных открытых проектах. Подробнее об операторе ?: я писал в уже упомянутой ранее книге (см. главу N4: Бойтесь оператора ?: и заключайте его в круглые скобки).

Кажется, забыли про «cost»

Структура alg_hash_entry объявлена следующим образом:

struct alg_hash_entry {
  unsigned HOST_WIDE_INT t;
  machine_mode mode;
  enum alg_code alg;
  struct mult_cost cost;
  bool speed;
};

В функции synth_mult программист решил проверить, тот ли это объект, который ему нужен. Для этого ему требуется сравнить поля структуры. Однако, кажется в этом месте допущена ошибка:

static void synth_mult (....)
{
  ....
  struct alg_hash_entry *entry_ptr;
  ....
  if (entry_ptr->t == t
      && entry_ptr->mode == mode
      && entry_ptr->mode == mode
      && entry_ptr->speed == speed
      && entry_ptr->alg != alg_unknown)
  {
  ....
}

Предупреждение анализатора PVS-Studio: V501 There are identical sub-expressions ‘entry_ptr->mode == mode’ to the left and to the right of the ‘&&’ operator. expmed.c 2573

Два раза подряд проверяется mode, но зато нет проверки cost. Возможно, одно из сравнений нужно просто удалить, а возможно, нужно сравнивать cost. Мне сложно судить, но код явно стоит поправить.

Дубликаты присваиваний

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

Случай N1

type_p
find_structure (const char *name, enum typekind kind)
{
  ....
  structures = s;                   // <=
  s->kind = kind;
  s->u.s.tag = name;
  structures = s;                   // <=
  return s;
}

Предупреждение анализатора PVS-Studio: V519 The ‘structures’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 842, 845. gengtype.c 845

Случай N2

static rtx
ix86_expand_sse_pcmpistr (....)
{
  unsigned int i, nargs;
  ....
    case V8DI_FTYPE_V8DI_V8DI_V8DI_INT_UQI:
    case V16SI_FTYPE_V16SI_V16SI_V16SI_INT_UHI:
    case V2DF_FTYPE_V2DF_V2DF_V2DI_INT_UQI:
    case V4SF_FTYPE_V4SF_V4SF_V4SI_INT_UQI:
    case V8SF_FTYPE_V8SF_V8SF_V8SI_INT_UQI:
    case V8SI_FTYPE_V8SI_V8SI_V8SI_INT_UQI:
    case V4DF_FTYPE_V4DF_V4DF_V4DI_INT_UQI:
    case V4DI_FTYPE_V4DI_V4DI_V4DI_INT_UQI:
    case V4SI_FTYPE_V4SI_V4SI_V4SI_INT_UQI:
    case V2DI_FTYPE_V2DI_V2DI_V2DI_INT_UQI:
      nargs = 5;         // <=
      nargs = 5;         // <=
      mask_pos = 1;
      nargs_constant = 1;
      break;
  ....
}

Предупреждение анализатора PVS-Studio: V519 The ‘nargs’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 39951, 39952. i386.c 39952

Случай N3

Последний случай более странный, чем остальные. Возможно, тут есть какая-то ошибка. Переменной steptype значение присваивается 2 или 3 раза. Это подозрительно.

static void
cand_value_at (....)
{
  aff_tree step, delta, nit;
  struct iv *iv = cand->iv;
  tree type = TREE_TYPE (iv->base);
  tree steptype = type;                 // <=
  if (POINTER_TYPE_P (type))
    steptype = sizetype;                // <=
  steptype = unsigned_type_for (type);  // <=
  ....
}

Предупреждение анализатора PVS-Studio: V519 The ‘steptype’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 5173, 5174. tree-ssa-loop-ivopts.c 5174

Заключение

Я рад, что написал эту статью. Теперь мне есть что отвечать на комментарии вида «PVS-Studio не нужен, так как все те же предупреждения выдаёт и GCC». Как видите, PVS-Studio очень мощный инструмент и превосходит по диагностическим возможностям GCC. Я не отрицаю, что в GCC реализованы отличные диагностики. Этот компилятор, при должной настройке, действительно выявляет много проблем в коде. Но PVS-Studio — это специализированный и быстро развивающийся инструмент, а это значит, он всегда будет лучше выявлять ошибки в коде, чем это делают компиляторы.

Приглашаю познакомиться с проверками других известных открытых проектов, посетив этот раздел нашего сайта. А также, тем, кто использует Twitter, последовать за мной @Code_Analysis. Я регулярно публикую ссылки на интересные статьи по программированию на языке C и C++, а также рассказываю о новых достижениях нашего анализатора.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey karpov. Bugs found in GCC with the help of PVS-Studio.

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

Содержание

Как проверить коды онлайн (онлайн компилятор)

Вот список некоторых из лучших онлайн компиляторов для проверки кодов онлайн.

• GDB Online

• Codepad

• Codechef

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

  Похожие: Найдите разницу между похожими текстовыми файлами.

1] GDB Online

Он предлагает современный интерфейс с подсветкой синтаксиса и функциями, основанными на предсказаниях. Если вы хотите написать код или протестировать его, скопируйте-вставьте его сюда и запустите. GDB Online поддерживает языки программирования C, C++, Python, PHP, Ruby, C #, VB, Perl, Swift, Prolog, Javascript, Pascal, HTML, CSS, JS.

Он ограничивает размер исходного кода, stdin, stdout, stderr до 64 КБ. Он также поддерживает сторонние библиотеки для CC++, которые включают ncurses, lapack и boost.

Попробуйте GDB Online

2] Codepad

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

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

• C

• C++

• D

• Haskell

• OCaml

• Perl

• Python

• Ruby

• Scheme

• Tcl.

  Вставьте полученный код в редактор и нажмите кнопку run. Если вы не хотите, чтобы ваш код был опубликован в открытом доступе, убедитесь, что вы установили флажок private.

  

  После компиляции и выполнения кода вы получите три вещи:

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

• Правильно отформатированный и выделенный цветом код

• Вывод с деталями ошибки и упоминанием номера строки.

• Редактор снова, если вы хотите сменить язык и повторно запустить код.

  

  Вы также можете посмотреть на коды, которые люди пробуют на Codepad, с помощью ссылки в правом верхнем углу страницы.

  Больше на Codepad

3] Codechef

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

Посмотрите CodeChef

4] Repl.it

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

Вы также можете поделиться кодом с кем угодно, чтобы получить помощь. Подробнее на сайте Repl.it

Какой из этих онлайн-компиляторов вам понравился больше всего? Для меня это GDB Online, который предлагает отличный интерфейс.

YouTube видео: Как проверить коды программирования онлайн (Онлайн-компилятор)

---

Вопросы и ответы по теме: “Как проверить коды программирования онлайн (Онлайн-компилятор)”

Где можно проверить код питон?

Для проверки кода на Python подходит сервис Online Python. Здесь представлена простая IDE, которая поддерживает загрузку с компьютера и скачивание кода в виде файла с расширением *. py.Сохраненная копияПохожие

Где можно проверить код Java?

Если вы хотите быстро проверить какой-нибудь простой код на Java, вам поможет компиляция онлайн (online compile).Сохраненная копия

Как открыть файл в онлайн Компиляторе питон?

Метод open() В Python есть встроенная функция open() . С ее помощью можно открыть любой файл на компьютере.

Что такое онлайн компилятор?

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

Как сделать проверку на питон?

**В Python проверка строки на число можно осуществить двумя способами:**1. Проверить все символы строки что в них записаны цифры. Обычно используется для этого функция isdigit.
2. Попытаться перевести строку в число. В Python это осуществляется с помощью методов float и int. В этом случае обрабатывается возможное исключение.

Какой компилятор в Python?

Python ускорилсяОни создали компилятор Codon, существенно повышающий производительность скомпилированных приложений на фоне их аналогов, вышедших из-под стандартных интерпретаторов. По скорости работы они едва ли не быстрее программ на С и C++, пишет The Register.

Не всегда есть доступ к любимой IDE или время на её запуск. Но когда нужно быстро проверить какой-то простой функционал или воплотить новую идею, пригодятся онлайн-компилятор.

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

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

Содержание

Мультиязычные компиляторы

Online IDE

Среди преимуществ этого редактора — предложения. Стоит ввести одну букву, и вам будут доступны варианты автодополнения, что поможет сохранить время. Компилятор поддерживает работу с несколькими файлами, позволяет их импортировать с компьютера. Кроме того, созданный код можно загружать или делиться им онлайн, сохраняя в облаке. Удобная работа с терминалом, доступна функция аргументов командной строки. Редактор поддерживает тёмный режим и чтобы работать в нём не понадобиться регистрироваться.

IDEONE

Характерная черта — поддерживает не только самые популярные языки, но и ассемблер, фортран и тому подобное. Есть три уровня доступа к коду — публичный (он будет отображаться на отдельной странице), секретный (доступен только по ссылке), частный (сможете просматривать только вы при условии регистрации).

IDEONE имеет некоторые ограничения для незарегистрированных пользователей — время выполнения программы. При наличии аккаунта он составляет 15 секунд, без — 5.

Repl.it

Даёт достаточно много возможностей и максимально приближен к десктопной IDE. Во-первых, здесь можно создавать целостную структуру проекта, разделяя код не только по разным файлам, но и по директориям. Разрешено использовать систему контроля версий, подключить имеющийся репозиторий с GitHub или создать новый. Можно воспользоваться дебагером, устанавливать переменные среды, подсоединить базу данных, пригласить людей для совместной работы. Здесь также отображаются предложения, пока вы пишете. И все это — бесплатно. В платной версии доступно неограниченное количество частных репозиториев, большая скорость и объём памяти.

CodingGround

Довольно простой редактор, без широкого спектра возможностей, но удобный, когда надо быстро проверить что-то в пределах одного файла. Поддерживает более 70 языков и технологий, можно делиться кодом. Вообще это один из проектов ресурса TutorialsPoint, поэтому сайт можно использовать и для обучения — здесь есть много платных курсов и бесплатных детальных туториалов.

OneCompiler

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

GeeksForGeeks

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

W3Schools

Это ещё одна известная платформа с курсами, туториалами, упражнениями и тестами. Онлайн-компиляторы предлагают для тех языков, которые можно изучать на сайте — PHP, Java, C++, C#, R, JavaScript, Go, а также этот онлайн компилятор поддерживает Python и другие. Также есть редакторы для работы с HTML, CSS, SQL и тому подобное. Ресурс имеет простой минималистичный интерфейс, без продвинутых функций.

Компилятор для C, C++

OnlineGDB

Этот компилятор C++ поддерживает несколько языков, но в первую очередь предназначен для C и C++. Есть дебаггер. Интересная функция «beautify», автоматически форматирующая код, в частности отступы в нём, в соответствии со стандартами. 

Компилятор для работы с C#

DotNetFiddle

Этот онлайн компилятор C# поддерживает C#, F# и VB.NET. Он позволяет делиться кодом, как для просмотра, так и для совместной работы. Также есть разные режимы — для консольного приложения, скрипта, по шаблону MVC и с фреймворком Nancy. А ещё имеется опция «tidy up» — если ручная расстановка отступов отнимает много времени.

Компилятор для web-разработки

CodeSandbox

На этой платформе можно работать с HTML и многочисленными JavaScript библиотеками и фреймворками — React, Vue.js, Node.js и многими другими технологиями. Поддерживается создание иерархической структуры проекта, можно подсоединить профиль GitHub. А ещё — развернуть разработанное приложение на одном из предложенных сервисов. Среди возможных недостатков — вся ваша работа будет в публичном доступе. Частные проекты можно разрабатывать в платной версии.

Компилятор для Go

The Go Playground

Это компилятор от официального сайта Go. Возможности довольно ограничены, есть только пространство для работы с кодом и консоль для вывода. Поэтому если нужно быстро проверить небольшой участок кода, сервис справится, а для более широкого функционала можно воспользоваться Repl.it, Online IDE, Online GDB или иной площадкой, что поддерживает Go.

Онлайн компилятор Java

JDoodle

Здесь можно выбирать версию языка, задавать аргументы командной строки, добавлять ввод. Также есть возможность совместной работы над кодом, который можно использовать для проведения интервью. Сервис поддерживает более 70 языков, однако особенно полезен для разработки на Java. Например, именно для неё есть два типа компилятора — базовый, когда нужно быстро выполнить несколько строк кода, и продвинутый — для структуры из многочисленных файлов, работы с чтением и записью к документам.