2.4. Компиляция при помощи cc

При использовании таких математических функций, как sin(), вам нужно указать компилятору cc на компоновку с математической библиотекой, вот так:

    % cc -o foobar foobar.c -lm

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

Объявления математических функций находятся в файле math.h. Если вы включаете этот файл, то компилятор сможет найти объявление и перестанет вытворять странные вещи с вашими расчетами!

    #include <math.h>
    #include <stdio.h>

    int main() {
    ...

После компиляции таким же образом, как и раньше, запустите программу снова:

    % ./a.out
    2.1 ^ 6 = 85.766121

Если вы используете какие-либо математические функции, всегда включайте файл math.h и не забудьте выполнить компоновку с математической библиотекой.

Запомните, что cc будет называть выполнимый файл a.out, если вы не зададите имя явно. Воспользуйтесь опцией -o filename:

    % cc -o foobar foobar.c

В отличие от MS-DOS, Unix не просматривает текущий каталог, когда пытается найти выполнимый файл, который вы хотите запустить, если вы явно его укажете. Либо введите команду ./foobar, которая означает, что "нужно запустить файл с именем foobar, располагающийся в текущем каталоге", или измените вашу переменную окружения PATH, чтобы она выглядела примерно как

    bin:/usr/bin:/usr/local/bin:.

Точка в конце означает "посмотреть в текущем каталоге, если в других ничего не найдено".

В большинстве Unix-систем в каталоге /usr/bin присутствует программа с именем test и до того, как оболочка доберется до текущего каталога, она выбирает именно ее. Наберите:

    % ./test

либо выберите более подходящее для вашей программы имя!

Фраза core dump (сброс дампа) своим происхождением обязана ранним дням Unix, когда в качестве устройств для хранения данных в машинах использовалась память на магнитных сердечниках (core). В общем, если в программе при некоторых условиях возникала ошибка, система записывала содержимое памяти на магнитных сердечниках на диск в файл с именем core, в котором затем для обнаружения причины происшедшего мог покопаться программист.

Для анализа дампа воспользуйтесь программой gdb (посмотрите Section 2.6).

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

Часто встречаемыми причинами этого являются:

• Попытка записи в область памяти, на которую ссылается указатель со значением NULL, например

      char *foo = NULL;
      strcpy(foo, "bang!");
  
  

• Использование указателя, Using a pointer that hasn't been initialised, eg

      char *foo;
      strcpy(foo, "bang!");
  
  

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

• Попытка выхода за границы массива, к примеру

      int bar[20];
      bar[27] = 6;
  
  

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

      char *foo = "My string";
      strcpy(foo, "bang!");
  
  

  Компиляторы Unix часто размещают строковые выражения типа "My string" в областях памяти, доступных только для чтения.

• Выполнение сомнительных операций с функциями malloc() и free(), например

      char bar[80];
      free(bar);
  
  

  или

      char *foo = malloc(27);
      free(foo);
      free(foo);
  
  

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

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

Да, просто, перейдя на другую консоль или xterm, выдайте команду

    % ps

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

    % kill -ABRT pid

где pid тем самым идентификатором процесса, который вы нашли.

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