Bus Error en C, Sous OS X dans le terminal

[mackintosh]

Bonsoir,

j'utilise depuis peu mon imac pour compiler des sources C pour différents tp ...
les exemples de base, boucles etc ... marchent très bien mais je rencontre un souci avec un petit programme qui est sensé lire puis restituer un fichier sur l'ecran du shell

J'obtiens le message suivant : Bus error ....
voici ci dessous la source du programme, si quelqu'un pourrait m'éclairer un peu sur ce problème ?

CODE

#include <stdio.h>
int main()
{
FILE *f;
char c;
char saisie;

printf("saisissez le fichier a lire");

scanf("%c", &saisie);
f=fopen("saisie", "r");


while (! feof(f))
{
c=fgetc(f);
printf("%c", c);
}


}



"lecture.c" 21L, 211C

Ce message a été modifié par mackintosh - 4 Oct 2006, 22:17.

[franklinchef]

Petite rectification pour tout le monde:

Bus error n'est ni une erreur d'overflow ou fichier manquant, mais bien un accès à un pointeur non valide (non existant ou permission non accordé). On peut le comparer à un segmentation fault sous linux.

Une autre erreur:

CODE

char *saisie = (char*) malloc(32*sizeof(char));
        printf("saissisez le fichier a lire !!!");
        scanf("%c", saisie);

Et si malloc fail? Tu te tappes un autre Bus error! TOUJOURS TOUJOURS TOUJOURS vérifier la valeur de retour de n'importe [mcr]alloc()

Sans oublier que scanf est la fonction à utiliser par excellence si on veut se faire un buffer overflow
Cette fonction serait mieux et plus sécuritaire dans ton cas:
http://en.wikipedia.org/wiki/Fgets

Ce message a été modifié par franklinchef - 9 Oct 2006, 21:19.

[noop]

Et si malloc fail? Tu te tappes un autre Bus error! TOUJOURS TOUJOURS TOUJOURS vérifier la valeur de retour de n'importe [mcr]alloc()

C'est la grande question: doit t'on vérifier tous les malloc. Dans le cas que tu cite, si le system n'a pas pu t'allouer 32 * sizeof(char) octets, c'est que tu es dans un position délicate. Il y a de forte probabilité que même le test suivant plante car ta machine ne pourra plus rien faire. Et même a supposer que tu arrive a faire le test, tu va devoir générer une erreur (log, message....) qui va nécessiter beaucoup plus de mémoire ce qui va encore planter.

Je penses qu'il faut vérifier que les grosses allocations, le reste il faut s'en passer celà permet une meilleur lisibilité du code et diminue sa complexité

[franklinchef]

Et si malloc fail? Tu te tappes un autre Bus error! TOUJOURS TOUJOURS TOUJOURS vérifier la valeur de retour de n'importe [mcr]alloc()

C'est la grande question: doit t'on vérifier tous les malloc. Dans le cas que tu cite, si le system n'a pas pu t'allouer 32 * sizeof(char) octets, c'est que tu es dans un position délicate. Il y a de forte probabilité que même le test suivant plante car ta machine ne pourra plus rien faire. Et même a supposer que tu arrive a faire le test, tu va devoir générer une erreur (log, message....) qui va nécessiter beaucoup plus de mémoire ce qui va encore planter.

Je penses qu'il faut vérifier que les grosses allocations, le reste il faut s'en passer celà permet une meilleur lisibilité du code et diminue sa complexité

Je ne suis pas daccord avec toi. Le problème avec les alloc failed, c'est qu'il te retourne un null pointer. Si tu fais un test/acces/modif à ce pointeur, l'OS tue ton process sans aucune chance de sauvegarde de données.

Prenons par exemple un logiciel critique: voir MySQL. Est-ce que tu accepterais de perdre toutes tes données en transaction parce qu'un call d'alloc à échoué? Ceci est tout à fait innacceptable. Peut-être qu'en effet ça diminue la complexité et la lisibilité, mais le but est de garder un programme consistant et efficace.

Il ne faut pas prendre en considération que ta fonction va toujours réussir, c'est une très mauvaise notion de programmation qui amène à des plantages non voulu.Par contre, je t'accorde le fait que ce n'est pas nécessaire pour un petit programme pour apprendre le language. Je ne fais qu'avertir mackintosh aux joies de la famille alloc, vaut mieux ne pas prendre de faux plis dès le départ.

Et pour ce qui est de la complexité... Il suffit de créer son propre call de malloc voir getmem() avec les mêmes params. Cette fonction est un wrap arround de malloc et fait les checks (null pointer?) sinon elle apelle une fonction définie par nous pour flusher les données importants. Tout ça en quittant sans avoir de Bus Error

[noop]

Et si malloc fail? Tu te tappes un autre Bus error! TOUJOURS TOUJOURS TOUJOURS vérifier la valeur de retour de n'importe [mcr]alloc()

C'est la grande question: doit t'on vérifier tous les malloc. Dans le cas que tu cite, si le system n'a pas pu t'allouer 32 * sizeof(char) octets, c'est que tu es dans un position délicate. Il y a de forte probabilité que même le test suivant plante car ta machine ne pourra plus rien faire. Et même a supposer que tu arrive a faire le test, tu va devoir générer une erreur (log, message....) qui va nécessiter beaucoup plus de mémoire ce qui va encore planter.

Je penses qu'il faut vérifier que les grosses allocations, le reste il faut s'en passer celà permet une meilleur lisibilité du code et diminue sa complexité

Je ne suis pas daccord avec toi. Le problème avec les alloc failed, c'est qu'il te retourne un null pointer. Si tu fais un test/acces/modif à ce pointeur, l'OS tue ton process sans aucune chance de sauvegarde de données.

Prenons par exemple un logiciel critique: voir MySQL. Est-ce que tu accepterais de perdre toutes tes données en transaction parce qu'un call d'alloc à échoué? Ceci est tout à fait innacceptable. Peut-être qu'en effet ça diminue la complexité et la lisibilité, mais le but est de garder un programme consistant et efficace.

Il ne faut pas prendre en considération que ta fonction va toujours réussir, c'est une très mauvaise notion de programmation qui amène à des plantages non voulu.Par contre, je t'accorde le fait que ce n'est pas nécessaire pour un petit programme pour apprendre le language. Je ne fais qu'avertir mackintosh aux joies de la famille alloc, vaut mieux ne pas prendre de faux plis dès le départ.

Et pour ce qui est de la complexité... Il suffit de créer son propre call de malloc voir getmem() avec les mêmes params. Cette fonction est un wrap arround de malloc et fait les checks (null pointer?) sinon elle apelle une fonction définie par nous pour flusher les données importants. Tout ça en quittant sans avoir de Bus Error

Dans les conditions limites tu n'es jamais sur de sauver correctement. Si tes données sont importantes, elles sont aussi surement importante en taille. Or tu viens d'avoir une erreur sur un malloc, tout le code qui va suivre va aussi allouer de la mémoire....donc aussi planter.

Ce message a été modifié par noop - 10 Oct 2006, 13:50.

[franklinchef]

Et si malloc fail? Tu te tappes un autre Bus error! TOUJOURS TOUJOURS TOUJOURS vérifier la valeur de retour de n'importe [mcr]alloc()

C'est la grande question: doit t'on vérifier tous les malloc. Dans le cas que tu cite, si le system n'a pas pu t'allouer 32 * sizeof(char) octets, c'est que tu es dans un position délicate. Il y a de forte probabilité que même le test suivant plante car ta machine ne pourra plus rien faire. Et même a supposer que tu arrive a faire le test, tu va devoir générer une erreur (log, message....) qui va nécessiter beaucoup plus de mémoire ce qui va encore planter.

Je penses qu'il faut vérifier que les grosses allocations, le reste il faut s'en passer celà permet une meilleur lisibilité du code et diminue sa complexité

Je ne suis pas daccord avec toi. Le problème avec les alloc failed, c'est qu'il te retourne un null pointer. Si tu fais un test/acces/modif à ce pointeur, l'OS tue ton process sans aucune chance de sauvegarde de données.

Prenons par exemple un logiciel critique: voir MySQL. Est-ce que tu accepterais de perdre toutes tes données en transaction parce qu'un call d'alloc à échoué? Ceci est tout à fait innacceptable. Peut-être qu'en effet ça diminue la complexité et la lisibilité, mais le but est de garder un programme consistant et efficace.

Il ne faut pas prendre en considération que ta fonction va toujours réussir, c'est une très mauvaise notion de programmation qui amène à des plantages non voulu.Par contre, je t'accorde le fait que ce n'est pas nécessaire pour un petit programme pour apprendre le language. Je ne fais qu'avertir mackintosh aux joies de la famille alloc, vaut mieux ne pas prendre de faux plis dès le départ.

Et pour ce qui est de la complexité... Il suffit de créer son propre call de malloc voir getmem() avec les mêmes params. Cette fonction est un wrap arround de malloc et fait les checks (null pointer?) sinon elle apelle une fonction définie par nous pour flusher les données importants. Tout ça en quittant sans avoir de Bus Error

Dans les conditions limites tu n'es jamais sur de sauver correctement. Si tes données sont importantes, elles sont aussi surement importante en taille. Or tu viens d'avoir une erreur sur un malloc, tout le code qui va suivre va aussi allouer de la mémoire....donc aussi planter.

Si tu utilises des buffers static pour dumper ton data, tu t'en sors vainceur parce qu'ils sont déjà alloués

[noop]

Si tu utilises des buffers static pour dumper ton data, tu t'en sors vainceur parce qu'ils sont déjà alloués

Dans ton code oui (bien que des buffers static c'est limite programmation à la sauvage !). Mais tes données tu va les passer à un autre process (base de données par exemple) qui lui va devoir allouer de la mémoire. Que fais tu ? Tu penses que celà va marcher et que miraculeusement de la mémoire va être libérée ?