sprintf() problème avec XP seulement

Bonsoir à tous,

Je fais face à un petit problème assez embêtant avec une fonction de base du C: sprintf().

J'ai essayé le code sous Windows Vista et Windows XP. Je viens de me rendre compte aujourd'hui que sous XP, la même ligne de code ne produisait pas le même résultat.

Pour une petite idée voilà le code. Pour info nom_fichier correspond à un wxString (je suis sous wxWidgets).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

wxFileName fname(chemin_fichier); //Pour pouvoir récupérer nom du fichier + extension wxString nom_fichier = fname.GetFullName(); //Ici je peux afficher le nom+extension sans aucun problème size_t t_tempo = nom_fichier.Len(); // Taille chaine nom_fichier // Controle dela taille retournée = nb caractères = OK   // Ces 3 lignes sont là juste pour tester char test[34]; sprintf(test,"%s",nom_fichier.c_str()); wxMessageBox(wxT(test),"chemin depuis tableau",wxOK); // Ici j'affiche bien le nom du fichier sans problème   char trame_init[(int)t_tempo+34]; // Tableau pour recevoir les données avant insertion dans le tableau (+34 inclu 13 caractères pour chaque long long int et les spérateurs (|) ) sprintf(&trame_init[4],"%lli|%lli|%i|%s",this->taille_fichier,this->start,demande_retour,nom_fichier.c_str()); // Insertion dans tableau temporaire wxMessageBox(wxT(&trame_init[4]),"tableau envoi",wxOK); // Ici en affichant la trame "composée" la dernière partie qui devrait correspondre à ma chaine (nom du fichier) est remplacée par (null). Et ce problème ne se produit que sous XP!

---

Comme je viens de le noter juste au dessus, le problème intervient au niveau du sprintf() qui si je met avant des %lli etc... me met une chaine vide dans le tableau (les vérifs sont faites avant donc le problème vient bien de cette instruction précise). Théoriquement pas de débordement de mémoire, il y a même plus que nécessaire. De plus le problème se pose que sous XP. La même application exécutée sous Vista ne pose pas le problème et ne l'a jamais posé.

Merci à ceux qui auraient une idée :)

Bonne soirée à tous

Un problème de runtime C différent entre XP et vista probablement. Tout le monde ne semble pas d'accord sur la manière de décrire un format pour un nombre 64 bits. Certains utilisent %lld et d'autres %I64d, cela doit être ton problème.

Code:

---

1 2 3 4 5 6

printf("value using I64d: %I64d\n", value); /* for Borland BCC or Microsoft VC++ */ printf("value using Ld: %Ld\n", value); /* for Borland BCC */ printf("value using lld: %lld\n", value); /* for gcc */ printf("value using I64x: %016I64x(hex)\n", value);/* for Borland BCC or Microsoft VC++ */ printf("value using Lx: %016Lx(hex)\n", value);/* for Borland BCC */ printf("value using llx: %016llx(hex)\n", value); /* for gcc */

---

Bonsoir et merci d'avoir pris le temps de répondre.

Mais le problème c'est que lorsque j'affiche pas par pas, la trame composée qui se trouve dans le tableau de caractères est 34567|0|0|(null)

Donc je récupère bien mes long long int (qui ici correspondent à des integer on est d'accord, mais il peuvent contenir des valeurs qui tiennent sur 64 bits). C'est uniquement la chaine ( nom_fichier.c_str() ) qui est remplacée par (null) sous XP. Si le problème venait des long long int il n'apparaitraient pas dans le tableau avec XP non?

Merci :)

Salut,

peut etre plutot un probleme avec wxWidget au niveau de l'objet wxString et sa methode c_str()?

Admettons que cela soit un problème d'interprétation %lld/%I64d

lorsque tu empiles tes parametres pour le sprintf, tu empiles 2 nombres 64 bits + 1 nombre 32 bits + 1 pointeur

le sprintf se trompe avec le format et prend %lld (ou %lli, c'est pareil) pour un format 32 bits. Avec "%lli|%lli|%i|%s", il dépile 2 nombres 32 bits + 1 nombres 32 bits + 1 pointeur. Le pointeur dépilé se trouve être le poid faible ou fort de ton 2eme nombre 64 bits et peut être que ce résidus de nombre 64 bits vaut 0 interprété comme NULL

Une explication qui vaut ce qu'elle vaut

Bonsoir,
EDIT: Ce qui suit concerne la remarque sur wxString

Et bien justement je ne pense pas parce que j'ai utilisé des messageBox pour vérifier celà (je les ai peut être enlevé dans le code ci-dessus).

Et dans le premier sprintf() j'utilise bien nom_fichier.c_str() pour placer ma chaine dans le tableau et lorsque je l'affiche il contient bien la chaine.
Donc je ne pense pas que le problème vienne de là.

Assez spécial ce bug. Surtout que malgré tous les tests on ne s'en est rendu compte qu'aujourd'hui (on avait déjà eu le bug mais on avait pas pensé que ca venait de XP parce qu'on était encore en plein développement).

Merci à vous

EDIT: Réponse à ram-0000
Peut être pour l'interpretation des %lld en 32 bits mais dans mon cas les valeurs sont "codables" sur 32 bits donc si sprintf() les met sur 32 bits pas de soucis de ce côté là. De plus le (null) se trouve après un pipe (|) donc je ne vois pas comment cela pourrait être la suite du long long int vu que le pipe est un caractère et se trouve avant, non?
Je me trompe peut être, je ne sais pas.

Mais du coup je ne sais pas trop comment résoudre cela.

Merci

Quel compilo utilises-tu?
C'est important, car ils n'utilisent pas la même version du runtime C, et les versions les plus vieilles ne comprennent pas le spécificateur de tailile ll (ne comprenant que I64).

Bonjour,

J'utilise MinGw 3.4.5. En remplaçant par I64d et après 2 tests cela à l'air de fonctionner sur XP, mais à voir avec des tests plus poussés (je n'ai pas moi même XP sur mon PC portable).

Une autre question. Ce problème de compatibilité doit aussi se poser avec d'autres fonctions? Je pense notamment à sscanf(). Dois je remplacer dans celle-ci aussi mes %lli par %I64d?
Et pour la déclaration de mes entiers sur 64 bits je peux toujours utiliser long long int? Ou cela aussi pose problème (sous XP j'entends).

Merci à vous. :)

Effectivement, je pense que tu risques d'avoir exactement le même problème avec toute les fonction *printf() et toutes les fonction *scanf(). Pas cool hein :P