Discussion :

[Emmanuel Delahaye]

Une petite remarque au passage, il faut toujours caster le pointeur de retour d'un malloc ans le type de la variable de stockage. Ca évite de chercher les erreurs de compilation de ce genre

Euh, non!
s / toujours / jamais

[Caine]

Bien, ben, voici l'endroit ou ça plante,
je te laisse effectuer la correction.

J'ai laissé les instructions de débug, je fais avec des fprintf, car sous cygwin, je n'arrive pas encore à utiliser gdb.

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
36
37
38
39
40
41
42
43
44
45
46
47
48
 
void reecriture ( ARBRE t, FILE *file_temp, FILE *file_dest ){
 
	unsigned char tmp;
	ARBRE p=t;
	long c=0,taille_file_temp = fsize(file_temp);
 
	while ( c < taille_file_temp ) {
 
		if ( p->fg == NULL && p->fd == NULL ){
	//Caine
	fprintf(stderr,"if \n");
	//End Caine				
 
			fwrite ( &p->e, 1, 1, file_dest );
			p = t;
		}
 
		else{
	//Caine
	fprintf(stderr,"else \n");
	//End Caine						
			fread(&tmp,1,1,file_temp);
	//Caine
	fprintf(stderr,"fread end \n");
	//End Caine									
			c++;
 
			if ( tmp == 0 ) {
	//Caine
	fprintf(stderr,"p = p->fg; \n");
	//End Caine						
				p = p->fg;
			} else {
	//Caine  C'est ici que ça segmente fault :)
	fprintf(stderr,"p = p->fg; \n");
	//End Caine									
				p = p->fd;
			}	
		}
 
	}
 
	fclose(file_temp);
 
	fclose(file_dest);
 
}

[Caine]

Au fait, tu peux enlever le flag résolu,
puisque tu as encore quelques soucis

[ben13]

Bien, ben, voici l'endroit ou ça plante,
je te laisse effectuer la correction.

C theoriquement impossible davoir une erreur de segmentation a ce niveau mais j'ai assuré en rajoutant des tests qui verifient si p->fg et p->fd sont bien non NULL.

Je suis a ma fac la, ici j'ai pas d'erreur de segmentation mais mon fichier decompressé c'est nimporte quoi (ex : ya que des f et des espaces)

J'ai egalement essayé de compressé un binaire ... meme merde

il est a noté qu'une fois decompressé mon fichier n'a pas la meme taille que la source originale....

Je comprends plus ca marche parfaitement chez moi

[Mac LAK]

C theoriquement impossible davoir une erreur de segmentation a ce niveau mais j'ai assuré en rajoutant des tests qui verifient si p->fg et p->fd sont bien non NULL.

Faut te mettre dans la tête que "théoriquement impossible" en C, c'est pas une excuse pour éviter d'effectuer les tests... T'es pas en ADA.

Le SegFault peut se produire ou pas en fonction de l'OS, du modèle mémoire, de l'état précédent de la RAM, etc... De plus, le pointeur peut parfaitement être non-NULL, et pourtant être invalide, c'est même un problème récurrent en C.
Bref, du moment qu'il s'est déclenché sur une plate-forme, c'est que tu as AU MOINS un problème de vérification/blindage !!

Je suis a ma fac la, ici j'ai pas d'erreur de segmentation mais mon fichier decompressé c'est nimporte quoi (ex : ya que des f et des espaces)

CQFD... ;-)

Je comprends plus ca marche parfaitement chez moi

Les options du compilateur peuvent être en cause, dans un premier temps. Ensuite, une autre source d'erreur est le comportement différent d'une fonction entre les deux plate-formes, ce qui peut être fréquent avec les fonctions non-ANSI (ce n'est pas parcequ'elles ont le même nom qu'elles fonctionnent à l'identique)... Et l'API sous-jacente peut aussi avoir son mot à dire !

J'ai pu passer ton code à PC Lint, tu trouveras le compte-rendu ci-dessous. C'est pas beau du tout... 75 remarques, la sévérité est indiquée dans la première colonne (Error, Warn ou Info). J'ai dû virer le "#include <unistd.h>" pour passer, les erreurs liées aux éléments définis dans cet entête peuvent être de fausses alarmes.

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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
Warn :  huff.c(4,9): Repeated include file '.\include\stddef.h'
Error:  huff.c(37,43): Type mismatch (assignment) (ptrs to void/nonvoid)
Warn :  huff.c(39,13): Possible use of null pointer 'ptr' in left argument to operator '->' [Reference: file huff.c: line 37]
Warn :  huff.c(40,29): Possible use of null pointer 'ptr' in left argument to operator '->' [Reference: file huff.c: line 37]
Warn :  huff.c(41,15): Possible use of null pointer 'ptr' in left argument to operator '->' [Reference: file huff.c: line 37]
Warn :  huff.c(42,15): Possible use of null pointer 'ptr' in left argument to operator '->' [Reference: file huff.c: line 37]
Warn :  huff.c(61,17): Ignoring return value of function 'fclose(FILE *)' (compare with line 172, file .\include\stdio.h)
Warn :  huff.c(68,36): Ignoring return value of function 'fwrite(const void *, unsigned int, unsigned int, FILE *)' (compare with line 189, file .\include\stdio.h)
Info :  huff.c(70): Pointer parameter 'tab_freq' (line 66) could be declared as pointing to const
Warn :  huff.c(75,36): Ignoring return value of function 'fread(void *, unsigned int, unsigned int, FILE *)' (compare with line 181, file .\include\stdio.h)
Info :  huff.c(94): Pointer parameter 'tab_freq' (line 80) could be declared as pointing to const
Info :  huff.c(142,12): Symbol 'tmp' (line 101) conceivably not initialized
Error:  huff.c(155,29): Type mismatch (assignment) (ptrs to void/nonvoid)
Warn :  huff.c(158,36): Possible use of null pointer 'tmp' in left argument to operator '->' [Reference: file huff.c: line 155]
Warn :  huff.c(161,34): Possible use of null pointer 'tmp' in left argument to operator '->' [Reference: file huff.c: line 155]
Warn :  huff.c(164,25): Possible use of null pointer 'tmp' in left argument to operator '->' [Reference: file huff.c: line 155]
Info :  huff.c(186): Pointer parameter 't' (line 150) could be declared as pointing to const
Warn :  huff.c(158): Possible use of null pointer 'tmp' in left argument to operator '->' [Reference: file huff.c: line 155]
Warn :  huff.c(161): Possible use of null pointer 'tmp' in left argument to operator '->' [Reference: file huff.c: line 155]
Warn :  huff.c(164): Possible use of null pointer 'tmp' in left argument to operator '->' [Reference: file huff.c: line 155]
Warn :  huff.c(218,52): Ignoring return value of function 'fwrite(const void *, unsigned int, unsigned int, FILE *)' (compare with line 189, file .\include\stdio.h)
Warn :  huff.c(218,52): Possibly passing a null pointer to function 'fwrite(const void *, unsigned int, unsigned int, FILE *)', arg. no. 4 [Reference: file huff.c: line 214]
Warn :  huff.c(220,14): Ignoring return value of function 'fclose(FILE *)' (compare with line 172, file .\include\stdio.h)
Info :  huff.c(220,14): Conceivably passing a null pointer to function 'fclose(FILE *)', arg. no. 1 [Reference: file huff.c: line 214]
Warn :  huff.c(221,17): Ignoring return value of function 'fclose(FILE *)' (compare with line 172, file .\include\stdio.h)
Info :  huff.c(223): Pointer parameter 'tab_codes' (line 206) could be declared as pointing to const
Info :  huff.c(235,10): while(1) ...
Info :  huff.c(238,28): Loss of precision (assignment) (15 bits to 8 bits)
Info :  huff.c(260,56): Loss of precision (assignment) (15 bits to 8 bits)
Warn :  huff.c(264,44): Ignoring return value of function 'fwrite(const void *, unsigned int, unsigned int, FILE *)' (compare with line 189, file .\include\stdio.h)
Warn :  huff.c(271,24): Ignoring return value of function 'fclose(FILE *)' (compare with line 172, file .\include\stdio.h)
Info :  huff.c(281,15): Significant prototype coercion (arg. no. 2) int to long
Warn :  huff.c(281,26): Ignoring return value of function 'fseek(FILE *, long, int)' (compare with line 186, file .\include\stdio.h)
Warn :  huff.c(283,32): Ignoring return value of function 'fseek(FILE *, long, int)' (compare with line 186, file .\include\stdio.h)
Warn :  huff.c(291,12): Declaration of symbol 'c' hides symbol 'c' (line 30)
Info :  huff.c(294,38): Loss of precision (assignment) (long to int)
Warn :  huff.c(299,40): Ignoring return value of function 'fread(void *, unsigned int, unsigned int, FILE *)' (compare with line 181, file .\include\stdio.h)
Warn :  huff.c(307,50): Ignoring return value of function 'fwrite(const void *, unsigned int, unsigned int, FILE *)' (compare with line 189, file .\include\stdio.h)
Warn :  huff.c(313,37): Ignoring return value of function 'fread(void *, unsigned int, unsigned int, FILE *)' (compare with line 181, file .\include\stdio.h)
Warn :  huff.c(322,47): Ignoring return value of function 'fwrite(const void *, unsigned int, unsigned int, FILE *)' (compare with line 189, file .\include\stdio.h)
Warn :  huff.c(326,20): Ignoring return value of function 'fclose(FILE *)' (compare with line 172, file .\include\stdio.h)
Warn :  huff.c(335,9): Declaration of symbol 'c' hides symbol 'c' (line 30)
Warn :  huff.c(340,42): Ignoring return value of function 'fwrite(const void *, unsigned int, unsigned int, FILE *)' (compare with line 189, file .\include\stdio.h)
Warn :  huff.c(346,34): Ignoring return value of function 'fread(void *, unsigned int, unsigned int, FILE *)' (compare with line 181, file .\include\stdio.h)
Warn :  huff.c(360,20): Ignoring return value of function 'fclose(FILE *)' (compare with line 172, file .\include\stdio.h)
Warn :  huff.c(362,20): Ignoring return value of function 'fclose(FILE *)' (compare with line 172, file .\include\stdio.h)
Warn :  huff.c(368,58): Ignoring return value of function 'printf(const char *, ...)' (compare with line 193, file .\include\stdio.h)
Warn :  huff.c(369,64): Ignoring return value of function 'printf(const char *, ...)' (compare with line 193, file .\include\stdio.h)
Warn :  huff.c(394,62): Ignoring return value of function 'printf(const char *, ...)' (compare with line 193, file .\include\stdio.h)
Warn :  huff.c(395,22): Symbol 'code' (line 384) not initialized
Info :  huff.c(413,22): Loss of precision (arg. no. 1) (15 bits to 8 bits)
Warn :  huff.c(421,27): Ignoring return value of function 'unlink(const char *)' (compare with line 219, file .\include\stdio.h)
Warn :  huff.c(423,21): Ignoring return value of function 'fclose(FILE *)' (compare with line 172, file .\include\stdio.h)
Warn :  huff.c(423,21): Possibly passing a null pointer to function 'fclose(FILE *)', arg. no. 1 [Reference: file huff.c: line 399]
Info :  huff.c(427,72): Loss of precision (assignment) (long to int)
Warn :  huff.c(427,73): Ignoring return value of function 'printf(const char *, ...)' (compare with line 193, file .\include\stdio.h)
Warn :  huff.c(428,21): Ignoring return value of function 'fclose(FILE *)' (compare with line 172, file .\include\stdio.h)
Warn :  huff.c(428,21): Possibly passing a null pointer to function 'fclose(FILE *)', arg. no. 1 [Reference: file huff.c: line 426]
Info :  huff.c(430,70): Loss of precision (assignment) (long to int)
Warn :  huff.c(430,71): Ignoring return value of function 'printf(const char *, ...)' (compare with line 193, file .\include\stdio.h)
Warn :  huff.c(431,21): Ignoring return value of function 'fclose(FILE *)' (compare with line 172, file .\include\stdio.h)
Warn :  huff.c(431,21): Possibly passing a null pointer to function 'fclose(FILE *)', arg. no. 1 [Reference: file huff.c: line 429]
Warn :  huff.c(432,45): unrecognized format
Warn :  huff.c(432,58): Ignoring return value of function 'printf(const char *, ...)' (compare with line 193, file .\include\stdio.h)
Warn :  huff.c(434,6): Symbol 'tab_codes_comp' (line 385) not subsequently referenced
Warn :  huff.c(448,65): Ignoring return value of function 'printf(const char *, ...)' (compare with line 193, file .\include\stdio.h)
Warn :  huff.c(449,25): Symbol 'code' (line 440) not initialized
Warn :  huff.c(460,31): Ignoring return value of function 'unlink(const char *)' (compare with line 219, file .\include\stdio.h)
Warn :  huff.c(462,24): Ignoring return value of function 'fclose(FILE *)' (compare with line 172, file .\include\stdio.h)
Warn :  huff.c(464,9): Symbol 'i' (line 440) not subsequently referenced
Warn :  huff.c(474): function 'main(int, char **, char **)' should return a value (see line 373)
Info :  huff.c(474): Pointer parameter 'argv' (line 373) could be declared as pointing to const
Info :  huff.c(474): Symbol 'arge' (line 373) not referenced
Info :  huff.c(474): Pointer parameter 'arge' (line 373) could be declared as pointing to const
Info :  huff.c(476): Header file '.\include\math.h' not used in module 'huff.c'

Note aux modérateurs : Habituellement, je préfère mettre en upload sur mon site pour un truc aussi lourd, mais le FTP Wanadoo est en maintenance. Message éditable sur demande.

[ben13]

merci a toi mac LAK pour ton test.

Je comprends pas trop les 2 erreurs, je renvoie un ARBRE je vois pas ou est le prob ....

Bon enfin, j'ai fait un test, j'ai compréssé un binaire a ma fac, je me suis envoyé la source et le fichier compressé. Chez moi j'ai compréssé le meme fichier, le fichier compressé qui en resulte a la meme taille que celui de la fac mais n'est pas le meme.

Ca prouve rien mais bon ...

Enfin je pense que je vais laisser tomber pke ca menerve trop, hier j'ai compressé chez moi un divx de 200mo et apres decompression je me le suis maté entierement et tout etait parfait .... alors c pas un solaris de merde qui va me casser les c........

merci a tous pour votre aide ....

ps : mac lak si tu peux juste mexpliquer les 2 erreurs (qui sont les memes apperement) que PC lint a retourné ca serait sympa ....

[Mac LAK]

NOTE : Lorsque PC Lint écrit "huff.c(294,38 )", ça veut dire que l'erreur est dans le fichier "huff.c", ligne 294, colonne 38.

Ca prouve rien mais bon ...

Si, ça prouve que c'est ta phase de compression qui merde. Essaye avec la manip inverse, par curiosité. Le stockage de la table des fréquences peut être en cause, ou la construction de l'arbre, ou encore la lecture/écriture bit à bit... Bref, de nombreuses sources d'erreurs sont possibles.

un divx

T'as le DVD original de ton DivX ?

ps : mac lak si tu peux juste mexpliquer les 2 erreurs (qui sont les memes apperement) que PC lint a retourné ca serait sympa ....

Déjà, un truc qu'il faut que tu comprennes : PC Lint indique "Error" pour les conneries tellement grosses qu'on en a brûlé pour moins que ça au Moyen-Age. Les "Warn", c'est la mise au pilori pour 15 jours avec les chiens qui viennent te pisser dessus, et les "Info", t'as juste une légère amende de 300% de tes revenus et des coups de fouet...

Redevenons sérieux : tu n'as pas "que" deux trucs à corriger, tu en as 75, il faudrait que tu en sois conscient.
Pour les "Error", par exemple, c'est très simple :
- Tu n'as pas "casté" le pointeur retourné par malloc,
- Tu n'as pas vérifié que le pointeur était non-NULL.
Ca fait quand même 6 erreurs pour la même ligne de code... Car le premier "Error" provoque les 4 "Warn" suivants !!

Tu aurais dû écrire :

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
// La fonction renvoie NULL si l'allocation n'a pu être faite.
ARBRE creer_maillon ( unsigned char e, int frequence, ARBRE fg, ARBRE fd ) {
 
  ARBRE ptr = NULL ;
 
  // Le test explicite "!=NULL" sert à lever un warning de compilation.
  if ((ptr=(ARBRE)malloc(sizeof(struct noeud)))!=NULL) {
    ptr->e = e;
    ptr->frequence = frequence;
    ptr->fg = fg;
    ptr->fd = fd;
  }
  // Si ptr==NULL, le return reste valide.
  return ptr;
}

Un autre exemple :

Info : huff.c(238,28 ): Loss of precision (assignment) (15 bits to 8 bits)

Cette ligne veut dire, en langage courant, "t'as défini et assigné tes variables comme un goret"...
Tu as assigné une variable de 15 bits de long (=entier signé) vers une variable de 8 bits de long (=octet non signé) !! Le tout sans cast explicite, ni même de test de débordement ! Et après, tu t'étonnes que tu aie des ennuis ??

Encore un exemple :

Info : huff.c(294,38 ): Loss of precision (assignment) (long to int)

Si, sur ta plate-forme, tu as "sizeof(long int)==sizeof(int)==4", tu n'auras aucune erreur à l'exécution.
Si, comme sur ma cible PC Lint, tu as "sizeof(long int)==4" et "sizeof(int)==2", tu pars en vrille car tu perds de l'information là ou, précédemment, tu n'en perdais pas ! Bref, c'est quand même critique, tu ne crois pas ?

Et ce ne sont que des "Info"... Imagine les "Warn" ou les "Error" !

Dernier exemple :

Warn : huff.c(335,9): Declaration of symbol 'c' hides symbol 'c' (line 30)

Là, c'est pire... Dans la fonction reecriture, tu définis une variable qui masque celle définie ligne 30, c'est à dire... ton "CODE* c". Or, suivant les compilateurs, tu peux malgré tout "voir" le symbole masqué s'il est non-ambigü... Mais ça reste de la bidouille ! On ne déclare jamais une variable globale avec un nom d'une seule lettre, les risques de confusion sont beaucoup trop importants. Et quel que soit le cas, une variable locale ne doit JAMAIS avoir le même identifiant qu'une variable globale !


Bon, désolé d'avoir été un peu sec, mais j'espère que là, tu as compris la criticité de ces erreurs... Et, accessoirement, les faiblesses (devrais-je dire "lacunes abyssales", plutôt ?) des compilateurs C...

[Caine]

Bonjour Ben,
à priori ce n'est pas un problème de plateforme,
puisque j'ai utilisé Cygwin, un linux en mode console, qui respecte posix et tout le trallala.

Une habitude à prendre :

Code :

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

1
2
3
4
5
6
7
 
mon_type *pointeur;
 
pointeur = (mon_type *) malloc ( sizeof(mon_type));
 
if (pointeur == NULL )
   return -1; //N'importe quel code de traitement d'erreur.

Ca ne peut qu'aider

[Emmanuel Delahaye]

Pour les "Error", par exemple, c'est très simple :
- Tu n'as pas "casté" le pointeur retourné par malloc,

Pas de problème en C standard. Attention à activer les bonnes options de PCLint...

// Le test explicite "!=NULL" sert à lever un warning de compilation.
if ((ptr=(ARBRE)malloc(sizeof(struct noeud)))!=NULL) {
ptr->e = e;
ptr->frequence = frequence;
ptr->fg = fg;
ptr->fd = fd;
}
// Si ptr==NULL, le return reste valide.
return ptr;
}[/code]

Ce code est parfaitement conforme au C90 (et C99)

Code :

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

1
2
3
4
 
   ARBRE ptr = malloc (sizeof *ptr);
   if (ptr != NULL)
   {

Si il ne passe pas avec PCLint, c'est qu'il est mal configuré.

[ben13]

Info : huff.c(294,38 ): Loss of precision (assignment) (long to int)
Si, sur ta plate-forme, tu as "sizeof(long int)==sizeof(int)==4", tu n'auras aucune erreur à l'exécution.
Si, comme sur ma cible PC Lint, tu as "sizeof(long int)==4" et "sizeof(int)==2", tu pars en vrille car tu perds de l'information là ou, précédemment, tu n'en perdais pas ! Bref, c'est quand même critique, tu ne crois pas ?

Bon pour la variable c c clair que c trop laid que j'ai fait je vient de la corriger

Pour les tailles des differents types d'entiers qui different selon les machines je le savais mais j'ai pas du bien faire attention .....

Bonjour Ben,
à priori ce n'est pas un problème de plateforme,
puisque j'ai utilisé Cygwin, un linux en mode console, qui respecte posix et tout le trallala.

et ca marche ?????

Pas de problème en C standard. Attention à activer les bonnes options de PCLint...

Emmanuel tu semble dire que mon code est correct c'est ca ????

[Caine]

Non, justement Ben,
Ca ne mar'che pas, j'ai un semgmentation Fault sous Cygwin, à l'endroit que je t'ai indiqué dans mon premier post du thread.

Ha huffman...Que de bon souvenir en ADA, hein Mac Lak

[ben13]

Mac LAK g corrigé tout les probs de types et les cast ainsi que la réutilisation de la var c que javais fait dans 2 fonctions en + ......

sinon je vais retester a ma fac cet aprem et je vais aussi y ammener mon portable

je vais aussi essayer de me procurer pc lint .... apperement ca tourne que sous windows .....


enfin : pourquoi les modes les plus pointilleux de gcc ne font pas etat des 75 erreurs (enfin surement un peu moins car j'en avait corrigé entre temps) de pc lint ????

merci

[Mac LAK]

Pour les tailles des differents types d'entiers qui different selon les machines je le savais mais j'ai pas du bien faire attention .....

C'est un problème fréquent dans ton code : tu ne fais pas très attention à rendre homogènes tes types de variables... Il faut être plus rigoureux. Si tu l'avais été dès le départ (ne pas utiliser un "long int" si un "int" suffit, ne pas mélanger les types sans raison, etc...) tu n'aurais même pas besoin de te préoccuper de ce genre de choses.

Pas de problème en C standard. Attention à activer les bonnes options de PCLint...

Emmanuel tu semble dire que mon code est correct c'est ca ????

Cf. mon post précédent. Non, il ne l'est pas, tu as potentiellement des effets de bord qui peuvent se produire. D'ailleurs, ils se produisent réellement, puisque ton code se comporte différemment à ta fac !!
Que ton code compile sans aucun warning n'est qu'une précondition à un code correct : souvent, les compilateurs C sont "gentils" sur les warnings, et ne détectent pas toujours des erreurs que PC Lint, lui, remonte systématiquement.

Si tu veux rire un bon coup, sache que PC Lint détecte de nombreuses erreurs sur "stdlib.h"... ;-) Comme quoi, le C ANSI, c'est pas forcément "nickel-chrome"...

je vais aussi essayer de me procurer pc lint .... apperement ca tourne que sous windows .....

C'est un soft payant (239.00$). Tu peux aller voir sur http://www.gimpel.com/ pour plus de détails. Souvent, on utilise des versions de PC Lint "incorporées" aux IDE : dans mon cas, j'utilise celle de Paradigm C++ Pro.
Tu as beaucoup d'outils de ce genre, un des plus impressionnant est certainement PolySpace, mais le prix aussi est impressionnant (15 000 € minimum, si ma mémoire est bonne).

enfin : pourquoi les modes les plus pointilleux de gcc ne font pas etat des 75 erreurs (enfin surement un peu moins car j'en avait corrigé entre temps) de pc lint ????

Parceque le C est ultra permissif, et respecter la norme n'est pas suffisant pour garantir un code relativement correct... Il existe beaucoup d'outils de sur-vérification du code, qui utilisent en général au moins un typage fort et un suivi des valeurs (portée/durée de vie).
En général, on fait un Lint sur un code déjà débarrassé de tous ses warnings, sinon tu obtiens des kilomètres d'erreurs...

[ben13]

Si tu veux rire un bon coup, sache que PC Lint détecte de nombreuses erreurs sur "stdlib.h"... Wink Comme quoi, le C ANSI, c'est pas forcément "nickel-chrome"...

effectivement c'est assez ..... déconcertant .....

C'est un soft payant (239.00$). Tu peux aller voir sur http://www.gimpel.com/ pour plus de détails. Souvent, on utilise des versions de PC Lint "incorporées" aux IDE : dans mon cas, j'utilise celle de Paradigm C++ Pro.
Tu as beaucoup d'outils de ce genre, un des plus impressionnant est certainement PolySpace, mais le prix aussi est impressionnant (15 000 € minimum, si ma mémoire est bonne).

Ca fait beaucoup d'argent ....

Parceque le C est ultra permissif, et respecter la norme n'est pas suffisant pour garantir un code relativement correct... Il existe beaucoup d'outils de sur-vérification du code, qui utilisent en général au moins un typage fort et un suivi des valeurs (portée/durée de vie).
En général, on fait un Lint sur un code déjà débarrassé de tous ses warnings, sinon tu obtiens des kilomètres d'erreurs...

OK. Vu que j'ai pas de pc lint sous la main je vais tester apres corrections des erreurs que tu ma ennoncé et je verrai bien .......
Je me rend compte que les 3 semaines de C qu'on a eu comme mise a niveau au debut de l'annee (car j'ai fait ma 1ere annee en Pascal) aurait mieux fait de se transformer en 3 ans lol

[Emmanuel Delahaye]

Pas de problème en C standard. Attention à activer les bonnes options de PCLint...

Emmanuel tu semble dire que mon code est correct c'est ca ????

Sur le point précis que j'ai soulevé, oui.

[Mac LAK]

effectivement c'est assez ..... déconcertant .....

Non, c'est même logique, en fait... Cet entête est truffé de code spécifique à une plate-forme donnée et de "trucs et astuces" pour permettre cette portabilité du langage.

Ca fait beaucoup d'argent ....

Je sais... Ce sont des outils professionnels, ils sont hélas très chers en général, surtout pour un étudiant...

OK. Vu que j'ai pas de pc lint sous la main je vais tester apres corrections des erreurs que tu ma ennoncé et je verrai bien .......

Je pourrais toujours te le repasser à PC Lint, si tu veux.

[ben13]

C BON !!!!!

c passé a ma fac du coup j'ai emmené mon portable pour rien ... si ce n'est pour prouver a mes potes que je pouvais compresser un divx ..... lol

Le prob devait donc venir des erreurs de types effectivement vu la merde que c'est les stations d'accueil SUN de ma fac certains types doivent etres codés sur moins d'octets ....

J'ai donc remit mon projet ...

Je tiens a tous vous remercier pour votre aide (en particulier mac lak) et je voulais vous dire que grace a ce sujet j'ai enormement appris en C notamment sur les fichiers et aussi toutes les precautions qu'il faut prendre dans ce langage ....

Je pourrais toujours te le repasser à PC Lint, si tu veux.

Merci pour la proposition, ptet pour un futur code ..

ps : je coche résolu .... ca fait plaisir !

[Mac LAK]

Merci pour la proposition, ptet pour un futur code ..

ps : je coche résolu .... ca fait plaisir !

No problem !
Effectivement, ça fait plaisir : un post à 7 pages et 98 messages, c'est pas mal... ;-)

[gl]

Sujet nettoyer.

Merci de rester courtois.