Coucou à tous,

j'ai un petit TP à faire pour la fac et j'ai un problème vraiment très étrange avec la fonction printf, tout est expliqué ici :

http://rafb.net/p/wLiRg263.html

Voilà, si vous pouvez m'aider, un TRES grand merci ^^

Au fait, si je décommente le for dans afficheReleves(...), tout s'affiche correctement mais le programme ne sort pas de la fonction (boucle infinie encore une fois).

Ah non c'est bon laisez tomber c'est dû à une erreur située dans une autre fonction que j'avais mal situé, désolé ^^

Et non ça déconne toujours, j'ai l'impression qu'il y a un facteur externe au programme qui me fait planter totalement au hasard. La fonction afficheReleves se termine, pour en être sur, juste après l'appel dans le main, j'ai écrit printf("Affichage termine"); et ça s'affiche bien.
Ceci dit juste après ce printf j'ai écrit printf("dfdg"); et là ça plante... boucle infinie... la fonction suivante, tabTri_VarEntiere n'est pas appelée.

J'ai absolument aucune idée de ce qui peut faire planter printf, surtout sur un affichage aussi stupide qu'une simple chaîne de caractères, vous avez une idée ?

Quand tu dit j'ai écrit printf("dfdg");, c'est bien printf("dfdg"); et pas printf("dfdg\n"); que tu as écris ?
Si oui, l'appel à printf n'est peut etre pas problèmatique (l'affichage avec printf ne se fait pas à chaque appel mais est bufferisé pour limiter les appels systèmes), et c'est peut être la fonction tabTri_VarEntiere qui plante, est tu vraiment certain que tabTri_VarEntiere n'est pas appelée ? (pour débugguer, si tu tiens absolument à ne pas utiliser de débugueur, write est plus "fiable" que printf pour ce genre de tests).

C'est pas que je tiens absolument à ne pas utiliser de debugger mais je code sur les PCs de la fac et on ne nous a pas appris à nous en servir (j'écris mon code sous Kate).
J'ai fait un printf tout au début de tabTri_VarEntiere et il n'est pas affiché donc je suppose que la fonction n'est même pas appelée.

Je vais peut-être poser une question stupide mais write n'est pas une fonction permettant d'écrire dans des fichiers ? J'ai cherché le prototype sur Internet et je n'ai que ça.

Tiens, tiens...
En C les paramètres se transmettent bien par copie ?
Parce que j'appelle la fonction tabTri_VarEntiere qui copie donc le tableau Releves, et dans cette même fonction, j'appelle une autre fonction qui doit recopier à nouveau le tableau Releves, est-il possible que le système refuse d'allouer assez de mémoire ?

Désolé pour les posts qui s'enchaînent, j'ai résolu le problème, le programme se mettait à me signaler des erreurs de segmentation, en fait il s'agissait d'une mauvaise structure d'une boucle while de ma part. Désolé d'avoir dérange pour si peu et merci à toi UltraSPARC

Content que ton problème soit résolu
Je réponds quand même à tes deux autres questions, ça peut servir.

write(int fd, const void *buf, size_t count);
Permet d'écrire dans un file descriptor quelquonque, ça peut être un fichier, mais aussi la sortie standrard (fd=1), ou la sortie d'erreur (fd=2), voir un socket. Comme c'est un appel système, l'écriture se fait "réellement" à son appel, tandis que si le programme plante après un printf, il est possible que tes donnée n'aient pas été "flushées", et donc tu peux chercher longtemps un bug avant le printf alors qu'il se situe après :p .

1. En C les paramètres se transmettent bien par copie ?

Je vais pas dire de bêtise à propos des struct vu que je suis pas sûr, mais les tableaux sont passés par pointeurs (en fait en c ce *sont* des pointeurs.

Sinon pour débuguer, tu compiles avec gcc -g, et tu lances gdb en lui passant en argument le nom de ton programme, et tu tapes "run tes_params", ton programme se lancera, et s'arrêtera en te donnant des informations sur le nom de la fonction dans laquelle tu te trouves, et te permet d'afficher des variables avec la commande "p nom_de_variable".
Il y a d'autres commandes plus évolués dans gdb, mais avec ça tu peux déjà t'économiser pas mal de temps.

juste pour compléter, je pense (sans en être sûr néanmoins) que les file descriptors du système peuvent aussi être "buffuriser". du moins jusqu'à un \n dans le cas de STDOUT.

(mais je confond peut-être, c'est juste un souvenir que j'ai de mes cours de système).

dnob700

oui les fprintf sont bufferisés. Dans le cas de recherche de bug par des series de fprintf(fd, "jusque la ca va\n"); il faut bien penser a mettre des fflush(fd); sous peine de se retrouver un bug a un endroit où il n'est pas...

oui, mais je me demandais pour les fd de unix (read et write) et pas pour les FILE de stdio.

Bon, je viens de vérifier et il y a effectivement un buffer après la fonction write (en tout cas pour stdout (fd==1), pour les fichiers, c'est évident mais c'est géré par le système).

Mais le buffer est très très court (je suppose que le système l'affiche dès qu'il a un instant) et donc ça ne doit pas poser de problème pour le débogage.

C'est le code que j'ai utilisé pour faire le test :

1. include <termios.h>
2. include <unistd.h>

int main(int argc, char** argv)
{
write(STDOUT_FILENO,"bonjour à tous !!!! comment allez vous ?",41);
tcflush(STDOUT_FILENO,TCOFLUSH);
write(STDOUT_FILENO,"\n",1);
return 0;
}

lancé directement depuis la console j'ai l'affichage qui se fait. Mais si je le lance dans un terminal plus lent (par exemple depuis vim) alors je n'ai que le retour à la ligne qui s'affiche.