Salut à tous !
 
Alors là je dois dire que c'est trés trés fort ... J'ai un programme qui fonctionne trés bien sur la machine ou je l'ai implémenté, mais qui n'était pas du tout portable à cause de son interface graphique GTK (enfin il à juste fallu que j'insere le runtime windows dans l'install). Soit. Mais alors une fois GTK installé sur la machine recevante, l'erreur la plus improbable de tous les temps est arrivée (il a deja fallu lutter pour voir d'ou ca venait tellemment c'était imprévisible 8O )
 Je m'explique : Au debut de mon programme, je fais une saisie de 'selection gtk' (selection du chemin du fichier à exploiter). Et je stock ce chemin dans un gchar* chemin, qui est mis dans ma structure principale (en GTK pour ceux qui ne connaissent pas, on met tous les elements à passer dans les fonctions dans une même structure car les fonctions callbacks ne supportent qu'un argument). Enfin bref tout ca me paraissait parfait. SAUF QUE sur la machine recevante, le chemin est erroné (il devait me filer l'adresse du pointeur un truc du genre enfin c'était illisible) et alors LA je dois dire que ca m'a vraiment stupefai ! Sincerement je ne comprends pas POURQUOI ca fait ca c'est hallucinant !  
 Si quelqu'un à la moindre idée, qu'il reponde parce que en plsu ca intervient alors que je dois rendre le tout donc ca la fout vraiment mal !!!
 
Merci, Skip

C'est parce qu'il manque un point-virgule à la ligne 42.

Non mais t'es pas drole la mdr
Je suis vraiment dans la merde moi ! Un logiciel non portable c'est pas trés interessant quoi

Et tu crois vraiment qu'on peut t'aider avec ce que tu racontes, là?

 
 Et bien oui ... Peut être que le même problème est arrivé à quelqu'un ?
On me dit sur un autre forum que c'est relativement courant. J'attends donc des reponses

euh...non.
Sans aucune ligne de code à part sortir la boule de crystal on peut pas faire grand chose, hein...

mais si !
mais moi au lieu de taper gtk, c'est DTC , et ca marchait pas ...
au final j'ai abandonné..
 
vous faites pas d'efforts le vendredi

 Bah disons que le code je peut te le sortir mais le problème est plus profond je pense ... Enfin voici toujour les bouts de codes qui nous interesse :

 
A mon avis va falloir que tu regardes la premiere ligne

 
 Euh ??? Merci d'être un peu plus explicite car il n'y à aucune erreur de code là  

ça fait des années que j'ai pas fait de C...m'enfin const initialisé à NULL puis modifié ça me parait louche aussi...

 
Bon, en tout cas félicitation pour ta superbe structure DEDE, gage d'un code de Qualité.  
DEDE c'est un peu trop commun. tu devrais plutot la renommer en TOTO ou TATA

la zone memoire sur laquelle pointe 'chemin' .... qui c'est qui l'alloue d'une part, et quelle est sa taille d'autre part ?

non, chemin est un pointeur sur un gchar constant ! il peut modifier le pointeur, mais pas la chaine sur laquelle pointe ledit gchar.
de plus, à partir du moment ou la propriété de constance est conservée ou augmentée, alors tu peux parfaitement faire un truc du genre :

 
Bon ok, heureusement que ça fait longtemps que j'ai pas touché à du C, quoi...

 
Non je voulais dire dans la fonction recuperer_chemin. Parce que les strcat semblent douteux.

Voilà ce qui est dit dans la doc GTK sur la fonction gtk_file_selection_get_filename

Quand tu fais ensuite un  gtk_widget_destroy(file_selection); ton chemin doit pointer sur une zone mémoire non valide.
De toute façon, il est bien indiqué que tu dois recopier le chemin si tu veux le conserver et le manipuler, enfin je suppose car l'anglais et moi...

En effet on m'à souligné le même point sur un autre forum et j'ai essayé en vain de copier mon chemin sur une chaine de caractere dynamique.
Cela étant dit je vais essayer de repenser le truc avec cette indication on va bien voir ce que ca donne
 
 En tout cas je suis toujours dans la même merde ...    
 
P.S. Caddie pourquoi tant de haine ?    

 
Non aucune haine ! juste un moment d'égarement sans intêret.  
De plus ma contribution ayant été complétement fausse je préfére m'écraser

ok pas de problèmes.
 
Bon sinon mon programme marche sur certaines machines, que je fasse une copie de mon chemin en dynamique ou pas. J'en conclus donc que c'est un problème de depassement de memoire si quelqu'un se sent de m'expliquer comment on se sert de valgrind (deja comment l'installer mdr)

mué bon apparement Valgrind c'est sous Linux uniquement

 
je vois pas pourquoi la constance de prout changerai
ce qui fait le boum c'est que l'écriture via caca pue du cul pour le compilo.
 
de toutes manières son problème c'est qu'il a tellement de trous dans le zizi, qu'il arrose partout quand il va aux toilettes.

 
ben elle change pas, ce qui change c'est que la chaine (et pas le pointeur) passe du statut modifiable à non modifiable.
 
si mes souvenirs sont exacts, je peux écrire caca=prout, mais pas prout=caca (car la constance de la chaine pointée est augmentée)

moi je ferais déjà un truc genre:
 

 
en fait c'est relou les char *

 
ok on se comprends  

c'est le C qui est relou

c'est vrai que pour tout ce qui est administratif c'est daubique.
 
mais une fois que tu as accès a un framebuffer de carte vidéo ça deviens plus drôle tout de suite  

Je ne sais pas comment fonctionne gtk_file_selection_get_filename mais il n'y a que 2 possibilités
1) cette fonction alloue de la mémoire, la remplit avec ton chemin et te renvoie un pointeur sur la zone allouée et t'as rien à faire qu'à penser à la libérer plus tard
2) cette fonction remplit une zone statique avec ton chemin et te renvoie un pointeur sur cette zone (comme le fait "getenv() par exemple). Là, t'es sèrieusement embêté parce que 2 appels successifs à ta fonction écrasent l'ancienne valeur par la nouvelle (la zone statique étant la même). Donc t'es obligé, après chaque appel, de recopier les infos dans une variable à toi déjà allouée comme il faut (et là, la solution de Bjone est parfaite)
 

Dommage de faire un memset écrasé par le strncpy car si la limite de "n" octets n'est pas atteinte, strncpy rajoute le 0 final.
Dommage aussi de ne pas réutiliser la macro du départ (mais ça, ça dépend des préférences de chacun)...

bin ouais mais si la limite est atteinte, le 0 final n'est pas rajouté.

et effetivement pour la macro, je préfère ne pas la réutiliser, car si je veux changer la taille du tampon en minimisant l'intrusion dans le code, je n'ai juste qu'a changer la déclaration de Path et tout le reste évolue en fonction de.

Oui mais si ça arrive, le 0 ne sera nécessaire qu'au dernier octet d'où le "Path[FILE_MAX_PATH]=0;" ou "Path[sizeof(Path) - 1]=0;"...

 Bah à vrai dire je n'apelle cette fonction qu'au départ pour avoir le chemin des fichiers à exploiter ; je ne laisse pas à l'utilisateur la possibilité de changer le chemin aprés coup car le traitement d'image peut durer plusieurs heures. Enfin bref je ne vais pas rentrer dans les details ...
 
 Toujours est il que ce problème ne devrait donc pas se poser. Maintenant il faut preciser que le programme fonctionne sur certaines machines mais présente le bug lorsque je suis sur certaines machines (plus petites à mon avis) donc il s'agirai bien d'un depassement memoire, et changer les char* en path je pense pas que ca change grand chose étant donné que le prog fonctionne trés bien à la base

Tout dépend du fonctionnement interne de cette fonction (voir la doc)
 

Il arrive très souvent qu'un défaut de programmation reste invisible parce que "le programme fonctionne bien". Puis on rajoute un truc totalement insignifiant, style 'printf("coucou" )' et là, plus rien ne va plus. C'est la notion de "comportement indéfini"
 
Ex :

Il est probable que cet exemple véreux fonctionnera dans 99% des cas parce que la zone mémoire située derrière "string" n'est pas utilisée. Mais si on rajoute un "int i" avant ou après string, on risque d'avoir des pb...

Iop. Mon problème principal, à savoir le pointeur non portable, je l'ai résolu en copiant chaque const char* dans un gchar, caractere par caractere, et en ajoutant le \0 à la fin (sans quoi ca marchait pas ...)
 
 Quant aux deux autres problèmes, à savoir que lors de la première utilisation du programme sur une machine le graph n'est pas forcement bon, et que souvent il ya un stop lors du passage entre allegro et gtk, je n'ai 'resolu' que le second, en affichant la console pour faire le lien ...
 
 J'éspère que le problème d'affichage ne se reproduira plus. En tout cas il est vraiment etonnant
 
 En fait il affiche les points 2 fois plus haut que prevu dans le repere c'est pathetique.

Ben t'as qu'à diviser toutes tes ordonnées par 2...  

lol non je peux pas puisque c'est uniquement lors de la première utilisation

Bonjour
Je pratique le GTK de temps à autre sur linux et j'ai pu constater que les valeurs stockées dans les widgets ne sont pas persistantes et donc disparaissent dès que l'on fait un gtk_widget_destroy y compris les widgets inclus.
Dans le cas présent, il est impératif de copier le contenu de la chaine dans  une zone mémoire qui sera persistante au moins jusqu'à son utilisation finale avant de faire le gtk_widget_destroy
Si cela plante sur certains systèmes et par sur d'autres, c'est que les dit systèmes ne gèrent pas le tas de la même façon et de plus la gestion des dit tas dépend de la mémoire vive disponible et utilisée et de la quantité à allouer; bref il est pratiquement impossible de prévoir cette gestion.
On peut donc dire que tu as de la chance quand ça ne plante pas et un comportement normal quand ça plante.
GTK gère convenablement sa mémoire (ce qui évite les fuites) et la rend disponible dès qu'il n'en a plus besoin (gtk_widget_destroy) et elle peut donc être immédiatement réutilisée.
La documentation GTK est pénible car uniquement en anglais, mais avant d'incriminer GTK, il faut la lire pour s'assurer de la bonne utilisation d'un widget.
Bon courage !