pb de warning avec tigcc - Page 1

TIGCC me balance un warning : 'prec' might be used uninitialized in this function, dans une fonction où selon moi c'est impossible de l'utiliser sans qu'il soit défini avant. De plus j'ai ce warning uniquement avec tigcc, j'utilise aussi GCC pour compiler sur PC et il n'a jamais ralé sur cette variable. Je ne vais pas poster la fonction complète mais voici en gros à quoi ça ressemble :

unsigned char ParsePushOperator(struct PARSE *parse, struct STACK *operators, unsigned char tag)
{
	unsigned char loop, prec, prev;
	void *top;

	switch (tag)
	{
		case TAG_OPP_PR1:
			/* Code qui n'utilise pas prec */
		break;

		case TAG_OPP_PR2:
			loop = 1;
			prec = parsePrec[TAG_OPP_PR2];

			/* Code qui utilise prec */
		break;

		default:
			loop = (prec != 255);
			prec = parsePrec[tag - TAG_OPB_ADD];

			/* Code qui utilise prec */
		break;
	}

	return !parse->err;
}

Quelqun sait si y'a une justification, ou si c'est un comportement étrange ? (pas la peine de répondre pour expliquer qu'il suffit de ne pas en tenir compte ou comment on peut le dégager hein, c'est juste pour comprendre pkoi il est là ^^)

J'en profite tant que j'y suis : pour compiler un proj dont les fichiers sont dans des dossiers séparés, avec gcc "normal" ça pose aucun problème, les #include sont tous de la forme #include "Dossier/Fichier.h", mais tigcc ne veut pas de ces chemins, il explique fièrement qu'il n'a pas pu trouver le fichier, la seule solution semble être de dégager tous les chemins à la main. En plus d'être completement illogique je n'arrive ni à comprendre comment on a pu inventer un système pareil, ni à savoir si on peut contourner pour éviter de modifier les sources à chaque fois qu'on veut compiler sur Ti ?

Vertyos
: Quelqun sait si y'a une justification, ou si c'est un comportement étrange ?

Ya peut-être une erreur dans le code que t'as mis, mais là tu peux arriver directement dans le cas "default", avec prec non initialisé, et tu fais loop = (prec != 255);

En plus d'être completement illogique je n'arrive ni à comprendre comment on a pu inventer un système pareil, ni à savoir si on peut contourner pour éviter de modifier les sources à chaque fois qu'on veut compiler sur Ti ?

Tu compiles avec l'IDE (tpr) pour TI je suppose ? Pour que ce soit partout pareil il suffit de ne pas utiliser ce systeme (bancal), et d'utiliser un Makefile. Je suppose que t'en as déjà un pour la compilation avec GCC ?

nitro
: Ya peut-être une erreur dans le code que t'as mis, mais là tu peux arriver directement dans le cas "default", avec prec non initialisé, et tu fais loop = (prec != 255);

Hum #boulet#, j'avais même pas vu que prec était utilisé juste avant d'être initialisé... Ce cas ne peut pas se produire mais au moins c'est normal qu'il gueule. Par contre je comprends pas pourquoi il ne me dit rien sur PC, alors que je compile ac les mêmes switchs.

Tu compiles avec l'IDE (tpr) pour TI je suppose ? Pour que ce soit partout pareil il suffit de ne pas utiliser ce systeme (bancal), et d'utiliser un Makefile. Je suppose que t'en as déjà un pour la compilation avec GCC ?

Heu nop, je suis sous win donc un .bat suffit (au moins pour le moment). C'est quand même dommage si l'IDE est aussi foireuse sur ce point. D'autant plus qu'ils ont du *ajouter* quelque chose pour que ça se comporte de cette façon, ça s'est pas fait tout seul, et j'ai du mal à comprendre la logique de la démarche

Vertyos
: Par contre je comprends pas pourquoi il ne me dit rien sur PC, alors que je compile ac les mêmes switchs.

A mon avis c'est parce que ton GCC sur PC est plus intelligent que TIGCC. Il a sans doute remarqué que le prec non initialisé n'avait aucune influence sur le reste, du coup il ne reporte pas de warning.

C'est quand même dommage si l'IDE est aussi foireuse sur ce point. D'autant plus qu'ils ont du *ajouter* quelque chose pour que ça se comporte de cette façon, ça s'est pas fait tout seul, et j'ai du mal à comprendre la logique de la démarche

#feature#

La mauvaise détection des variables qui risquent d'être utilisées sans être initialisée est quelque chose d'embétant et pas qu'avec GCC, c'est encore pire en JAVA qui considère en plus ça comme une erreur

En ce qui concerne la différence de comportement entre TIGCC et GCC, c'est peut-être tout simplement un problème de version. TIGCC n'est peut-être pas issu de la même version de GGC que celle que tu utilises.

Enfin tu ne l'as peut-être pas signalé parceque ça parrait évident mais on sait jamais, est-ce que tu a passé -W et -Wall en argument?

A mon avis c'est parce que ton GCC sur PC est plus intelligent que TIGCC. Il a sans doute remarqué que le prec non initialisé n'avait aucune influence sur le reste, du coup il ne reporte pas de warning.

Ca m'etonnerait quand même, étant donné que TIGCC est issu de GCC et je ne vois pas pourquoi la TIGCC Team aurait modifié la détection des variables non initialisées.

Uther
: Enfin tu ne l'as peut-être pas signalé parceque ça parrait évident mais on sait jamais, est-ce que tu a passé -W et -Wall en argument?

Oui, même switchs pour les deux compilations. Au pire, l'horrible "unsigned char prec = prec;" résout le problème, même si c'est pas franchement beau ^^

pourquoi quitte à initialiser pas forcer l'ini à zero directement au lieu de ta non-initialisation (et encore tu es sur que GCC ne va pas gueuler pour ca aussi ?)

justement ça n'initialise rien (puisque la valeur d'affectation n'existe même pas encore), c'est juste une syntaxe pas belle pour qu'il évite de sortir le warning.

oui j'ai vu que ca n'initialisait rien ^^ (ca produit du code ?)
c'est poru ca que ca m'ettonnait que ca vire le warning (gcc est vraiment bizarre)

c'est poru ca que ca m'ettonnait que ca vire le warning (gcc est vraiment bizarre)

c une extension conçue spécifiquement pour virer ce warning, histoire de ne le virer que pour quelques variables, et non pour tout le source

(void) prec;
c'est quand même plus beau.

"pourquoi quitte à initialiser pas forcer l'ini à zero directement au lieu de ta non-initialisation"
Peut être que ça prend moins de place ?

peut-être que la réponse a cette question a déjà été donnée 2 fois, juste en-dessous du post que tu as cité ?

On a tous compris que "int a=a;" vire le warning merci. Mais "int a=0;" vire aussi le warning.

"pourquoi quitte à initialiser pas forcer l'ini à zero directement au lieu de ta non-initialisation"

traduction: pourquoi faire "int a=a;" au lieu de "int a=0;" ?

Vertyos :
justement ça n'initialise rien (puisque la valeur d'affectation n'existe même pas encore), c'est juste une syntaxe pas belle pour qu'il évite de sortir le warning.

Pas envie de prendre de la place avec un 0 dont je ne veux pas me servir.

Ou alors la declarer dans le case. ({})

nitro
:

C'est quand même dommage si l'IDE est aussi foireuse sur ce point. D'autant plus qu'ils ont du *ajouter* quelque chose pour que ça se comporte de cette façon, ça s'est pas fait tout seul, et j'ai du mal à comprendre la logique de la démarche

#feature#

TIGCC-IDE copie tous tes fichiers qui sont dans la liste des fichiers du projet dans un repertoire temporaire (dans le meme dossier quoi) et fait la compilation dessus, la "feature" te permet de compiler sans avoir besoin de sauvegarder

C'est a ma connaissance le seul IDE avec une tel feature et aussi foireuse par la meme occazion

Si tu veux garder l'arborescence, il faut creer des repertoires "virtuel" dans l'arborescence des fichiers de ton projet (le trucs a gauche de l'interface)

bref

Godzil :
TIGCC-IDE copie tous tes fichiers qui sont dans la liste des fichiers du projet dans un repertoire temporaire (dans le meme dossier quoi) et fait la compilation dessus, la "feature" te permet de compiler sans avoir besoin de sauvegarder

Bah en soi c'est pas mauvais, mais ils auraient mieux fait de le faire dans l'autre sens (sauvegarder les anciennes versions des fichiers dans un repertoire temporaire le temps de la compilation) ; evidemment ca aurait ete un poil plus complique a implementer puisqu'il faut etre capable de restaurer ces anciennes versions en cas de plantage pdt la compilation, mais c'est tout...

Je me bornerai à vous faire remarquer calmement que vous pourriez très bien faire ça par vous-mêmes, puisque les sources sont disponibles, et même contribuer les modifications à la communauté.
Kevin aurait déjà transformé ce topic en flame en vous engueulant.

C'est interdit de faire des remarques sur un programme open-source ? (surtout que sachant que ce programme "open-source" utilise un compilateur proprietaire que je n'ai pas, j'aurais personnellement bien du mal a le modifier...)

Hmm oui, faire un truc open-source c'est pas une protection universelle contre le "faites-le vous même" dès qu'il y a une critique. Et encore, ça pourrait, simplement comme la TIGCC team a l'air très fière de son systeme foireux, elle ne gardera surement pas ladite modification (~ correction) pour les prochaines version, donc à quoi bon...

Je me répete, mais c'est le comportement de base qu'on attend, et TIGCC fait quelque chose qu'ils ont codé *en plus*, donc rien de plus facile que de le retirer, si ils voulaient vraiment le faire c'est pas la quantité de travail qui les en a empeché.

Lionel Debroux :
Je me bornerai à vous faire remarquer calmement que vous pourriez très bien faire ça par vous-mêmes, puisque les sources sont disponibles, et même contribuer les modifications à la communauté.
Kevin aurait déjà transformé ce topic en flame en vous engueulant.

De toutes il est banni
(et à chaque fois qu'on a fait des remarques constructives à propos de tigcc ou de son ide on s'est fait crier dessus )

sauf qu'on a deja gueulé plein de fois sur cette *feature*

De toutes il est banni

Bon bah en fait c'est encore mieux que ce que je pensais : non seulement le fonctionnement "normal" n'est pas accepté par l'IDE (mettre des #include relatifs aux vrais chemins des fichiers), mais le systeme foireux qu'elle est supposée gérer non plus

http://databob.free.fr/Volatile/Image/Screenshot/Windows/TIGCC_bug.png

Voilà c'est très joli, même en utilisant les "dossiers virtuels", ça ne marche pas, il faut virer le "../" pour que ça trouve le .h. Le problème c'est que par rapport à "parser.h" (le fichier visible sur le shot), "common.h" et cie se trouvent bien dans un dossier au même niveau, donc le path correct est "../Types/fichier.h" et surement pas "Types/fichier.h".

Bref, dans un cas comme dans l'autre ça ne marche absolument pas. Chapeau la TIGCC team

Mouarf

Petite supposition : pour gérer aussi bien le systeme sans dossier virtuels qu'avec dossiers virtuels, ils copient les trucs en double, un exemplaire dans un repertoire racine, et un exemplaire dans le dossier virtuel approprié. Si oui alors il faut faire dans "Parser/Blabla.c" #include "Types/fichier.h" et non #include "../Types/fichier.h", mais si "Types/fichier.h" veut inclure "Common/common.h", alors c'est #include "../Common/common.h" et non #include "Common/common.h" qu'il faut faire (par contre si c'est "Types/Coucou.c" qui inclut "fichier.h", ca foirera et il faut en fait ecrire "Types/fichier.h" meme si c'est le meme repertoire )

Si mon hypothese est correcte alors ils se sont vraiment, mais vraiment bien démerdés Sinon je suis curieux d'avoir la vraie explication ^^ (qui je l'espere est moins grotesque que ca)

vertyos> Sympa comme projet.

hmm pas tellement comparable à GFA-Basic, t'inquietes pas le record du basic le plus rapide sur Ti ne va pas être brisé cette fois-ci

Ah, le plus compacte alors peut être.

Pour les dossiers virtuel j'ai vite abandonné.

Tiens, je ne connaissais pas du tout les dossiers virtuels tels que les montre le screenshot. Vu ce que vous en dites, ça n'a pas l'air d'être très bien...