5.4. Compiler avec cc

Lors de l'utilisation des fonctions mathématiques comme sin(), vous devez dire à cc de lier avec la librairie math, comme :

% cc -o foobar foobar.c -lm
         

Quand le compilateur voit que vous appelez une fonction, il vérifie s'il a déjà un prototype pour celle-ci. S'il ne l'a pas vu, il suppose que la fonction retourne un int, ce qui n'est absolument pas ce que vous voulez ici.

Les prototypes des fonctions mathématiques sont dans math.h. Si vous incluez ce fichier, le compilateur sera capable de trouver le prototype et il arrêtera de faire des trucs étranges à vos calculs!

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

int main() {
...
         

Après avoir recompilé comme précédemment, exécutez :

% ./a.out
2.1 ^ 6 = 85.766121
         

Si vous utilisez quelques fonctions mathématiques que ce soit, incluez toujours math.h et n'oubliez pas de lier avec la librairie math.

Souvenez-vous, cc appellera l'exécutable a.out sauf si vous lui dites de faire autrement. Utilisez l'option -o nomfichier:

% cc -o foobar foobar.c
         

A l'inverse de MS-DOS, Unix ne regarde pas dans le répertoire courant lorsqu'il essaye de trouver un exécutable que vous voulez exécuter, sauf si vous lui avez dit de le faire. Vous pouvez soit taper ./foobar, ce qui signifie “exécute le fichier nommé foobar dans le répertoire courant”, soit changer votre variable d'environnement PATH de façon à ce qu'elle ressemble à quelque chose comme

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

Le point à la fin signifie “regarde dans le repertoire courant s'il n'est dans aucun autre”.

La plupart des systèmes Unix ont un programme appelé test dans /usr/bin et l'interpréteur prend celui-ci avant de vérifier dans le répertoire courant. Soit vous tapez

% ./test
         

soit vous choisissez un meilleur nom pour votre programme !!

Le nom core dump date des tous premiers jours d'Unix, quand les machines utilisaient la mémoire centrale[5]pour stocker les données. Simplement, si le programme a échoué sous certaines conditions, le système va écrire le contenu de la mémoire centrale sur le disque dans un fichier appelé core, que le programmeur peut ensuite examiner de près pour trouver ce qui s'est mal passé.

Utilisez gdb pour analyser le fichier core (voir Section 5.6).

Cela signifie simplement que votre programme a essayé d'effectuer une opération illégale sur la mémoire; Unix est conçu pour protéger le système d'exploitation et les autres programmes des programmes crapuleux.

Les causes habituelles de cela sont :

• Essayer d'écrire dans un pointeur NULL, par exemple

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

• Utiliser un pointeur qui n'a pas été initialisé, par exemple

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

  Le pointeur va avoir une valeur aléatoire qui avec de la chance, pointera dans une zone de la mémoire qui n'est pas disponible pour votre programme et le noyau va tuer votre programme avant qu'il ne fasse des dommages. Si vous êtes malchanceux, il pointera quelque part dans votre propre programme et altèrera une de vos structures de données, faisant planter votre programme mystérieusement.

• Essayer d'accèder la mémoire au-delà de la fin d'un tableau, par exemple

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

• Essayer de stocker quelque chose dans la mémoire en lecture seule, par exemple

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

  Les compilateurs Unix mettent souvent les chaînes comme "Ma chaine" dans des zones de mémoire en lecture seule.

• Faire des trucs sales avec malloc() et free(), par exemple

  char bar[80];
  free(bar);
         
  

  ou

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

Faire une de ces fautes ne conduit pas toujours à une erreur, mais elles sont toujours de mauvais entrainements. Certains systèmes et compilateurs sont plus tolérants que d'autres, ce qui explique pourquoi des programmes qui fonctionnent bien sur un système peuvent planter si vous les essayer sur un autre.

Non, heureusement non (sauf si bien sûr vous avez réellement un problème matériel...). Cela est habituellement une manière de dire que vous avez accédé à la mémoire d'une façon que vous n'auriez pas dû.

Oui, ouvrez une autre console ou xterm, faites

% ps
       

pour trouver l'identifiant du processus de votre programme, et faites

% kill -ABRT identifiant
       

où identifiant est l'identifiant du processus que vous avez trouvé.

Ceci est utile si votre programme est bloqué dans une boucle infinie, par exemple. Si votre programme arrive à bloquer le signal SIGABRT, il y a d'autres signaux qui ont des effets similaires.

Alternativement, vous pouvez créer un fichier core depuis votre programme, en appelant la fonction abort(). Voir la page de manuel en ligne de abort(3) pour en savoir plus.

Si vous voulez créer un fichier core depuis l'extérieur de votre programme, mais ne voulez pas que le processus s'arrêt,vous pouvez utiliser le programme gcore. Voir la page de manuel en ligne de gcore(1) pour plus d'informations.