Bonjour à tous,
 
En cette belle journée de samedi, j'ai l'immense change de devoir débugger en urgence un programme C qui ne fonctionne plus comme avant, suite à changement d'OS (AIX 4 -> AIX 5).
Evidemment, ce prog n'a pas été recompilé.
 
Le truc bizarre, c'est que le programme est très volumineux (il fait énormément de lectures/écritures/déplacements de fichiers + contrôles de chaînes de caractères) mais que j'ai un bug (régression ?) sur une toute petite partie : 2 lectures consécutives dans un fichier texte, avec des fgets.
La première ligne lue ainsi est toujours vide (le programme l'affiche ensuite dans un fichier), la deuxième passe nickel.
 
Alors je ne vais pas vous demander de débugger le programme, mais j'ai quelques questions, n'étant pas du tout spécialiste en C :
 
1- suite à un changement d'OS sans aucune modif d'architecture, faut-il obligatoirement recompiler ?
 
2- Ce type de bug très ciblé est-il courant (12 000 lignes de code marchent, 4 non... évidemment ça fonctionnait avant) ?
 
3- si je souhaite recompiler, dois-je obligatoirement utiliser le même compilateur que celui utilisé initialement (le programme datant de 2003, j'espère avoir toutes les sources et je ne connais pas la version du compilateur utilisé...). J'ai essayé de le recompiler avec gcc4.1, ça compile mais il plante ensuite dès le début de l'exécution.
 
4- des idées sur des bugs de ce genre avec fgets ?
 
Merci beaucoup d'avance
 

Plus je fais d'essais (sans modifier la source puisque je peux pas recompiler) moins je comprends :
le prog lit un fichier texte séquentiellement à coups de fgets.
Tout se passe bien, arrivé à un moment il lit une ligne (40 car), la stocke dans une ligne d'un tableau C, lit la suivante et la stocke à la fin de la même ligne (à l'indice +40).
 
La fin de l'enregistrement du tableau contient bien la deuxième ligne, mais pas le début... quoique je mette dans le fichier d'entrée...
 
comprends pas.

si t'as pas le sources, difficile de comprendre...
 
1) pas forcement, mais des librairies partagées peuvent être lacés différement celon l'os, par exemple... si tu peux le recompiler, pourquoi ne pas le faire
 
2) oui c'est ça le C, une erreur ou tu l'atend pas, un tout petit chose qui va pas/plus...
 
3) non, je ne crois pas. pr contre si tu as les sources et qu'en recompilant ça plante, teste à coup de gdb ce qui se passe (compile avec -g avec gcc)
 
4) sans code... et puis moi j'ai un niveau de C raze motte

C'est le cas le pire. C'est très souvent consécutif à un accès mémoire sur une mémoire non allouée. Le programmeur a oublié d'allouer la mémoire pour son pointeur et il va allègrement y écrire et lire des infos et par chance(ou malchance, ça dépend comment on voit le truc) ça marche. Puis, un jour, différents cas se produisent
1) on rajoute une variable totalement anodine
2) on change d'OS
3) autre chose du même style
Et là, patatrac, le programme ne mrche plus. Et là, il faut trouver le pourquoi du comment...

et ça peu grandement changer au niveau de l'OS.
j'ai developpé un petit projet en C pour l'école.

je developpais sur ma debian, ça marchait nickel. tout content je passe compiler ça sur windows (projet obligatoirement multiplateforme ) là encore pas de probleme. génial . je le fais testé sur une fedora: SegFault. une ubuntu : SegFault...

il y a des différences à ce niveau entre deux os comlpletement différent (windows et linux par exemple) mais même entre différentes distributions du même os sur mêmes architectures !    

J'ai changé de méthode, j'ai fait un awk qui modifie le contenu du fichier de sortie, et basta
 
C'est ça de faire venir des mecs le samedi, ils choisissent la solution de facilité
 
Merci pour vos réponses, je vois un peu mieux ce qui a pu se passer, effectivement il aurait fallu recompiler (j'avais des sources, mais sans doute pas celles de la dernière version, et dans le doute je préfère éviter de prendre tout risque).