Discussion :

[mecaplus]

Bonjour,

un petit souci concernant ce warning que je n'arrive pas comprendre. Je rencontrais ce petit souci lorsque je travaillais sur un code monolithique et souvent c'est à la fin du main qu'il manquait une nouvelle ligne, il suffisait alors de faire entrée pour résoudre le problème.

Maintenant, j'ai découpé mon code en module car il y a plus de 10000 lignes et ça devient un peu lourd à trimballer dans un seul fichier... J'ai donc des fichiers.h, des fichiers.h.

J'inclus donc un certain nombre de fichiers, et là, je me retrouve avec quelques warning sur certains fichiers alors qu'il y a bien une ligne à la fin de chaque fichier.

Au passage, il n'y a aucune erreur à la compilation, le programme tourne mais avec ces warning, ce qui n'est pas très propre.

J'ai lu sur la toile, notamment ici mais aucune solution proposée ne me permet de pallier à cette situation.

Quelqu'un connait-il la cause réelle de ces warning et la solution pour les résoudre? Et pourquoi ça marche dans certains cas et pas dans d'autres?

D'avance merci pour vos réponses.

Je suis sous Windows : MinGW, gcc, Notepad++

[Sve@r]

J'inclus donc un certain nombre de fichiers, et là, je me retrouve avec quelques warning sur certains fichiers alors qu'il y a bien une ligne à la fin de chaque fichier.

Quelqu'un connait-il la cause réelle de ces warning et la solution pour les résoudre? Et pourquoi ça marche dans certains cas et pas dans d'autres?

Je suis sous Windows : MinGW, gcc, Notepad++

Salut

Sans exemple réel pas facile d'établir un diagnostic

Je vois 2 hypothèses

1) Le problème ne vient pas du fait qu'il y ait ou pas une ligne en fin de fichier, mais que le fichier contienne une ou plusieurs lignes non terminées. Cela peut venir d'un transfert de ton source du monde Unix vers Windows sans être passé par les outils adéquats.

En effet, une ligne dans un fichier texte standard Unix se caractérise par des lettres faisant partie de la plage ascii des caractères imprimables suivies d'un caractère invisible '\n'. Dans le monde zindow, une ligne se caractérise par des lettres de la même plage suivies de 2 caractères invisibles '\r\n'. Le '\r' symbolisant (comme sur les machines à écrire) le retour du curseur en début de ligne pour afficher la ligne suivante. Si on te demande pourquoi cette aberration qui a entrainé toute cette merde au niveau des échanges ftp avec cette obligation de spécifier text lorsqu'on veut transmettre un fichier texte (donc avec transformation éventuelle du caractère final) ou binary lorsqu'on veut transmettre un fichier binaire (donc sans transformation), c'est parce que 2 types n'ont pas su se mettre d'accord dans les années 1970. Merci à eux...

Donc si tu copies un fichier texte du monde Unix vers Windows en passant par exemple par une clef usb, la copie n'effectue pas la transformation et tu te retrouves avec un fichier texte illisible sous Windows (essaye de l'ouvrir avec notepad et tu verras).
Pour avoir un fichier correct, il te faut au préalable passer ton fichier par un utilitaire "unix2dos" assurant la conversion. Et un utilitaire inverse "dos2unix" assure la conversion dans l'autre sens.
Si ton fichier n'est pas passé par ça, alors il se peut qu'il manque ce symbolisme.
Solution: trouver un Linux qui traine, copier tous tes fichiers dans le Linux, les passer par unix2dos puis les ramener dans ton répertoire. Ou alors en ouvrant le fichier avec Wordpad, en faisant ensuite "sélectionner tout" + "copier" puis en ouvrant un notepad vierge (le notepad de base, pas le notepad++) et en faisant "coller" puis "enregistrer sous"

2) il m'est arrivé en utilisant "vi" (un éditeur Unix) de taper trop vite et d'insérer un caractère invisible dans la ligne parce que j'ai déjà eu des warning sur des lignes pourtant correctes. Ce caractère invisible se plaçant avant ou après le '\n'. La ligne n'étant plus correctement formatée, le compilo me mettait un warning. Donc là, pour réparer le pb, je supprimais la ligne pour la retaper entièrement.

[mecaplus]

Merci pour ta réponse.

Alors je suis passé de Windows xp (au bureau) à Windows 7 (chez moi) mais aussi entre Windows xp et Linux via un client ftp (FileZilla) et là je viens de tester sous Windows vista(chez moi également).

Compilation chez moi sous windows 7 ok, pas de warning en revanche sous Windows xp et vista il y a des warning et sur tous ces pc je travaille avec (MinGW, Notepad++, gcc), un détail : je suis sous 64 bit pour windows 7 et 32 bit pour xp et vista.

Entre ces différents pc Windows, le code se transporte par clé USB.

Je n'ai pas encore testé sous Linux.

Je n'ai pas posté le code parce qu'il contient énormément de lignes, à moins de ne poster que le sous-programme placé à la fin du fichier.c vidé de son contenu puisque le problème se trouve à la dernière ligne du fichier...

Le problème vient certainement de ce tu as évoqué, j'ai essayé d'ouvrir un des fichiers qui pose problème sous wordpad-->sélectionner tout--> copier, ouvrir un nouveau document Notepad++ puis coller et recompiler mais toujours warning. J'ai aussi supprimer les deux dernières lignes pour tout retaper mais le résultat est le même.

[Sve@r]

...mais aussi entre Windows xp et Linux via un client ftp (FileZilla)

Vérifie les paramètres de ton client Filezilla. Il peut programmer le transfert automatique (menu "Transfert" => "type de transfert" => "automatique") ce qui le met automatiquement en mode texte pour certains fichiers selon leur extension.Il faut lui spécifier les ".c", ".h", ".c++", ".cpp" (menu "Edition" => "Paramètres" => "Transferts" => "Type de fichiers"). Ainsi, quand tu transfèreras à l'avenir un fichier .c ou .cpp en environnements hétérogènes (de Unix vers zindow ou inverse), Filezilla spécifiera le ftp en mode text et le ftp fera automatiquement la conversion (quelle merde quand-même !!!)

Compilation chez moi sous windows 7 ok, pas de warning en revanche sous Windows xp et vista il y a des warning et sur tous ces pc je travaille avec (MinGW, Notepad++, gcc), un détail : je suis sous 64 bit pour windows 7 et 32 bit pour xp et vista.

Je ne pense pas que 32/64 bits change quelque chose. Mais apparemment tu as une version qui compile correctement. Alors une solution serait de faire une archive winzip/winrar de ton dossier complet qui compile bien, transférer cette archive sur tes autres postes (en mode binary cette fois puisqu'il ne s'agit plus d'un fichier texte mais d'un fichier compressé) et la dézipper sur tes autres postes. Normalement tu devrais te retrouver de partout avec une bonne version...

Le problème vient certainement de ce tu as évoqué, j'ai essayé d'ouvrir un des fichiers qui pose problème sous wordpad-->sélectionner tout--> copier, ouvrir un nouveau document Notepad++ puis coller et recompiler mais toujours warning. J'ai aussi supprimer les deux dernières lignes pour tout retaper mais le résultat est le même.

J'ai dit "notepad", pas" notepad++" !!!

[Melem]

Dans notepad++, assure-toi que c'est bien ANSI qui est coché dans le menu "Encodage". Dans notepad, au moment de la sauvegarde, assure-toi que la valeur de "Encodage" est bien ANSI.

[mecaplus]

Merci à vous,

Je n'ai pas encore mis la main sur notepad pour le télécharger, je n'ai que notepad2 et notepad++ et ne trouve pour l'instant que des variantes...

Dans notepad++ c'est bel et bien l'option AINSI qui est coché.

Les mêmes warning sont bien présents sous Linux également . Je vérifierai les paramètres du client Filezilla et tester la solution du transfert en zippant le répertoire complet.

[Melem]

Je n'ai pas encore mis la main sur notepad pour le télécharger

Notepad c'est le Bloc-notes de Windows .

[mecaplus]

Merci, on apprend tous les jours ici.

J'ai effectué la minip consillée par Sve@r sur le page des fichiers sources entre wordpad et notepad en veillant à ce que la sauvegarde se fasse en mode AINSI. Tout le code est mis sur un nouveau fichier mais rien n'a fonctionner.

Cependant, en alourdissant un peu moins le main() c'est à dire en mettant le menu ci-dessous dans une fonction que j'appelle ensuite dans le main, le warning est disparu, tant mieux mais je ne comprends pas pourquoi...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
switch(choix){
 
      case 2:
 
 
       break;
 
	case 3:
 
 
 
	break;
 
	case 4:
 
 
	break;
 
	case 5:
 
 
	break;
 
        // etc...
 
	case 20:
 
	break;
 
	default:
 
	break;
 
	}

Tous les prototypes des fonctions sont déclarés en entête et le main() est placé à la fin du fichier.

Entre temps, je suis d'abord revenu sur une version monolithique où toutes les fonctions sont dans le même fichier et passer de 5 warning (version inclusion des sources) à un seul warning puis à plus rien.

Merci, il reste à vérifier la configuration du client FileZilla.

[mecaplus]

Vérifie les paramètres de ton client Filezilla. Il peut programmer le transfert automatique (menu "Transfert" => "type de transfert" => "automatique") ce qui le met automatiquement en mode texte pour certains fichiers selon leur extension.Il faut lui spécifier les ".c", ".h", ".c++", ".cpp" (menu "Edition" => "Paramètres" => "Transferts" => "Type de fichiers"). Ainsi, quand tu transfèreras à l'avenir un fichier .c ou .cpp en environnements hétérogènes (de Unix vers zindow ou inverse), Filezilla spécifiera le ftp en mode text et le ftp fera automatiquement la conversion (quelle merde quand-même !!!)

Les réglages sont correctes, aucun warning également sous linux après transfert par client FileZilla.

Pour l'instant incident résolu en attendant de comprendre le pourquoi?

Merci à vous.