DevCpp capricieux ? bug étrange...

Résolu
nollyflip Messages postés 9 Date d'inscription lundi 10 octobre 2005 Statut Membre Dernière intervention 2 juin 2007 - 2 juin 2007 à 01:45
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 3 juin 2007 à 00:43
Bonjour,
J'ai un comportement étrange (et pour le moins énervant) de dev cpp, je me dis que ce bug est peut-être connu et résolu. J'ai la 4.9.9.2 (dernière en vie)

Je vais faire simple :
Voici mon code, et voici les symptomes :
   1 -  Je déclare la structure test *ptest; et  je metptest->valeur=10;, qui pointe dans la structure. Ca compile mais plante à l'exécution.(ca n'arrive pas au system(pause)).
   2 - Si ensuite j'enlève ptest->valeur=10; et que je ne conserve que test *ptest; même réaction, plante.
   3 - Si ensuite encore, après avoir enlevé les deux, je compile, ca marche jusqu'au system(pause).
   4 - Je me remet dans la même config que 2, ca marche. Si je repasse ensuite à la 1, ca replante...

#include <stdio.h>
#include <stdlib.h>

struct _test
       {
       int valeur;
       };
typedef struct _test test;      
      
int main(int argc, char *argv[])
{
    test *ptest;
    ptest->valeur=10;
    printf("Valeur : %d\n",ptest->valeur);
 
  system("PAUSE");   
  return 0;
}

En aucun cas la compil ne plante. Le code me parait parfaitement juste.

Autre symptomes étranges :

    Je suis actuellement sur une appli GTK temps réel (450 lignes), je fonctionne beaucoup avec des pointeurs sur des structures. Je déclare ces pointeurs en local à main ou en global selon que j'ai besoin de récupérer les adresses dans des threads ou pas.

Bref ca fonctionne parfaitement bien, jusqu'a ce que j'ai créé (rajouté !) une nouvelle structure (identique aux autres !) en global pour passer des paramètres, et que j'y affecte une valeur dans main.
Ce coup ci, une autre blague :
    compil OK, mais ne lance rien. Il me créee un fichier projet1.3 au lieu d'un projet1.3.exe, et si je renomme le projet1.3 en projet1.3.exe, ca marche (les valeurs dans les structures sont bien appliquées, ca plante pas ni rien).

J'ai bien essayé entre chaque compile de virer tous les fichiers sauf le *.dev et le *.c (vaut mieux !)

Bref,

26 réponses

BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
2 juin 2007 à 23:34
Un pointeur sur x64 fait bien entendu 8 octets (taille de registre CPU), pas spécifique à la version ultimate.

De là à dire qu'on alloue 4 octets de plus qui ne seront pas libérés, aucun rapport.
Faudrait voir le code en cause pour trouver la raison du plantage.

ciao...
BruNews, MVP VC++
0
alextm Messages postés 23 Date d'inscription samedi 2 juin 2007 Statut Membre Dernière intervention 11 mai 2009
3 juin 2007 à 00:25
non je n'ai pas parler de pointeur mais d'uid qui fait 4 octets sur une version 32 bits et pareil sur une version 64
0
alextm Messages postés 23 Date d'inscription samedi 2 juin 2007 Statut Membre Dernière intervention 11 mai 2009
3 juin 2007 à 00:27
type short
0
alextm Messages postés 23 Date d'inscription samedi 2 juin 2007 Statut Membre Dernière intervention 11 mai 2009
3 juin 2007 à 00:30
pardon 2 octets sur 32 et 4 sur x64 :/ c'est l'heure du dodo ...
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
3 juin 2007 à 00:31
Alors quel rapport avec malloc ou new.

ciao...
BruNews, MVP VC++
0
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
3 juin 2007 à 00:43
Les compilos MS sont assez bien faits pour qu'on puisse faire du code portable de 32 vers 64 à la condition qu'on emploie les types Windows (UINT_PTR, etc...), les types standards ne variient pas en taille de 32 à 64 (int 32 à tout coup, etc...).
Il faut donc employer les codes Win si on sait devoir compiler ensuite en x64 sinon on réécrit.

ciao...
BruNews, MVP VC++
0
Rejoignez-nous