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.

[mackintosh]

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

J'ai lu le contraire sur un autre site qui parle du language C

CODE

E/S de chaînes de caractères avec gets, fgets et puts

gets est une fonction à proscrire absolument (dangers de buffer overflow). Cette fonction lit une ligne de l'entrée standard stdin et le copie dans le buffer passé en argument jusqu'à ce que '\n' ou EOF soit rencontré. fgets permet de limiter le nombre de caractères à lire et à copier dans le tableau passé en argument. puts écrit la chaîne passée en argument et rajoute \n à la fin.

Source => http://inferno.cs.univ-paris8.fr/~am/tutor...C/Cours-11.html

A priori le mieux est de vérifier les entrées avec un simple test et bien gérer son malloc ... ?

[chombier]

J'ai lu le contraire sur un autre site qui parle du language C

CODE

E/S de chaînes de caractères avec gets, fgets et puts

gets est une fonction à proscrire absolument (dangers de buffer overflow). Cette fonction lit une ligne de l'entrée standard stdin et le copie dans le buffer passé en argument jusqu'à ce que '\n' ou EOF soit rencontré. fgets permet de limiter le nombre de caractères à lire et à copier dans le tableau passé en argument. puts écrit la chaîne passée en argument et rajoute \n à la fin.

Source => http://inferno.cs.univ-paris8.fr/~am/tutor...C/Cours-11.html

A priori le mieux est de vérifier les entrées avec un simple test et bien gérer son malloc ... ?

Ce n'est pas le contraire: gets est une fonction dangereuse, parcequ'il n'y a pas de limitation sur la taille des données retournées. fgets est la fonction équivalente, mais avec un paramètre supplémentaire qui limite le nombre d'octets à retourner, ce qui permet de s'assurer qu'il n'y aura jamais de débordement.