Warning bizarre
Résolu
vecchio56
Messages postés
6535
Date d'inscription
lundi 16 décembre 2002
Statut
Membre
Dernière intervention
22 août 2010
-
20 janv. 2005 à 23:22
contax Messages postés 20 Date d'inscription lundi 17 janvier 2005 Statut Membre Dernière intervention 13 mars 2005 - 22 janv. 2005 à 20:30
contax Messages postés 20 Date d'inscription lundi 17 janvier 2005 Statut Membre Dernière intervention 13 mars 2005 - 22 janv. 2005 à 20:30
11 réponses
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
21 janv. 2005 à 13:56
21 janv. 2005 à 13:56
Il aurait du être initialisé mais j'ai vérifié le listing, il ne l'est effectivement pas.
Comme quoi c'est pas toujours bon de croire que le compilo fera exact ce qui est écrit, les messages d'alertes sont plus surs.
ciao...
BruNews, MVP VC++
Comme quoi c'est pas toujours bon de croire que le compilo fera exact ce qui est écrit, les messages d'alertes sont plus surs.
ciao...
BruNews, MVP VC++
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
21 janv. 2005 à 00:09
21 janv. 2005 à 00:09
p = *((int*)(((BYTE*)&d) + 1));
ne sort plus de warning mais est-ce bien ce que tu veux, lire un 32 bits a une adresse non alignee ???
ciao...
BruNews, MVP VC++
ne sort plus de warning mais est-ce bien ce que tu veux, lire un 32 bits a une adresse non alignee ???
ciao...
BruNews, MVP VC++
bayeto
Messages postés
224
Date d'inscription
mardi 12 août 2003
Statut
Membre
Dernière intervention
18 octobre 2010
21 janv. 2005 à 00:43
21 janv. 2005 à 00:43
Bizard car le warning disparait si d est globale.
Sinon ca serais pas plutot p = *((int*)(((BYTE*)&d) + 4)); ?
Sinon ca serais pas plutot p = *((int*)(((BYTE*)&d) + 4)); ?
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
21 janv. 2005 à 00:51
21 janv. 2005 à 00:51
depend justement de ce qu'il veut, +4 lira un int correctement aligne 4 octets plus haut en memoire.
ciao...
BruNews, MVP VC++
ciao...
BruNews, MVP VC++
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
vecchio56
Messages postés
6535
Date d'inscription
lundi 16 décembre 2002
Statut
Membre
Dernière intervention
22 août 2010
14
21 janv. 2005 à 10:30
21 janv. 2005 à 10:30
Même avec +4 on a un warning...
Mais il me semble que &d+1 donne un adresse alignée sur 4 octets
puisque d est int. C'est comme quand on incrémente un int*, en fait ca
l'incrémente de 4.
Mais il me semble que &d+1 donne un adresse alignée sur 4 octets
puisque d est int. C'est comme quand on incrémente un int*, en fait ca
l'incrémente de 4.
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
21 janv. 2005 à 10:45
21 janv. 2005 à 10:45
"il me semble" voila bien un des mots qui n'ont rien a faire en terme de dev. Il suffit de controler la sortie asm du compilo pour voir qu'il a obéi au doigt et à l'oeil:
mov ecx, dword ptr[esp+41]
t'es parti ici pour au moins 100 cycles au lieu de 1 normal avec le rattrapage logiciel que fera le systeme.
ciao...
BruNews, MVP VC++
mov ecx, dword ptr[esp+41]
t'es parti ici pour au moins 100 cycles au lieu de 1 normal avec le rattrapage logiciel que fera le systeme.
ciao...
BruNews, MVP VC++
vecchio56
Messages postés
6535
Date d'inscription
lundi 16 décembre 2002
Statut
Membre
Dernière intervention
22 août 2010
14
21 janv. 2005 à 11:22
21 janv. 2005 à 11:22
C'est vrai, j'y pense pas assez souvent.
Mais nous n'avons pas la même sortie, moi il ne donne rien de ce type, voila ce que j'ai (sans /Oy):
; 4 : int p = *((int*)(&d + 1));
mov eax, DWORD PTR _d$[ebp+4]
mov DWORD PTR _p$[ebp], eax
Mais nous n'avons pas la même sortie, moi il ne donne rien de ce type, voila ce que j'ai (sans /Oy):
; 4 : int p = *((int*)(&d + 1));
mov eax, DWORD PTR _d$[ebp+4]
mov DWORD PTR _p$[ebp], eax
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
21 janv. 2005 à 11:39
21 janv. 2005 à 11:39
Pour sur qu'on n'a pas la meme, j'ai pris la sortie sans warning:
p = *((int*)(((BYTE*)&d) + 1));
Fais gaffe avec ces conversions implicites en arithmetique pointeur, si tu veux le dword suivant je te conseille plutot:
p = *((int*)(((BYTE*)&d) + 4));
tu peux ainsi relire explicitement ce que tu voulais.
ciao...
BruNews, MVP VC++
p = *((int*)(((BYTE*)&d) + 1));
Fais gaffe avec ces conversions implicites en arithmetique pointeur, si tu veux le dword suivant je te conseille plutot:
p = *((int*)(((BYTE*)&d) + 4));
tu peux ainsi relire explicitement ce que tu voulais.
ciao...
BruNews, MVP VC++
vecchio56
Messages postés
6535
Date d'inscription
lundi 16 décembre 2002
Statut
Membre
Dernière intervention
22 août 2010
14
21 janv. 2005 à 13:33
21 janv. 2005 à 13:33
OK, mais pour revenir au problème de départ, d'où vient ce warning? Il n'a pas du tout de sens puisque d est initialisée...
contax
Messages postés
20
Date d'inscription
lundi 17 janvier 2005
Statut
Membre
Dernière intervention
13 mars 2005
22 janv. 2005 à 20:23
22 janv. 2005 à 20:23
Salut,
[***]$ cat > tmp.c
int main()
{
int d = 0, p;
p = *((int*)(&d + 1));
}
[***]$ gcc tmp.c
[***]$ gcc -Wall tmp.c
tmp.c: In function `main':
tmp.c:5: attention : contrôle a atteint la fin non void de la fonction
gcc m'a jamais vraiment pris la tête. Adopte.
[***]$ cat > tmp.c
int main()
{
int d = 0, p;
p = *((int*)(&d + 1));
}
[***]$ gcc tmp.c
[***]$ gcc -Wall tmp.c
tmp.c: In function `main':
tmp.c:5: attention : contrôle a atteint la fin non void de la fonction
gcc m'a jamais vraiment pris la tête. Adopte.
contax
Messages postés
20
Date d'inscription
lundi 17 janvier 2005
Statut
Membre
Dernière intervention
13 mars 2005
22 janv. 2005 à 20:30
22 janv. 2005 à 20:30
Et j'oubliais :
[***]$ gcc -O3 tmp.c
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
subl $16, %esp
leave
ret
[***]$ gcc -O3 tmp.c
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
subl $16, %esp
leave
ret
