Bug inet_ntoa () en linux 64

Résolu/Fermé
djodj31 - 23 oct. 2008 à 19:47
 djodj31 - 25 oct. 2008 à 08:28
Bonjour,
quelle fut ma surprise qd je compila un programme qui tournait sous Linux FC7 32 pour un version fc7 64 j'avais une erreur de segmentation. apers moult recherche j'a pu voir que la fonction inet_ntoa () sencé retrouner char* (donc 4 octets en linux 32 et 8 octets en linux 64) me retournais 4 octets et non 8
m'etonne que je devais aller dans les choux avec une adrese a demi fournie..
j'ai donc ecrit à la main une fonction inet_ntoa_AMD64 fonctionnat presque come la vraie mais pour les architectures AMD64
voici le code si ça interesse des gens. cependant je voudrais savoir si, en passant sous la FC9 voire la FC10 ce bug est persistant?
merci d'avance

#include <stdio.h>

#include <stdlib.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

char * inet_ntoa_AMD64(struct in_addr in, char * bufferRetour);
char * hexAscii10(char *ptrtmp,unsigned int val);


char * inet_ntoa_AMD64(struct in_addr in, char * bufferRetour)
{
char* ptrbuf=bufferRetour;
int i;
unsigned int buf_in;
buf_in=(unsigned int)in.s_addr;
ptrbuf=hexAscii10(ptrbuf,buf_in&0x000000ff);
for(i=0;i<3;i++){
*ptrbuf='.';
ptrbuf++;
buf_in=buf_in>>8;
ptrbuf=hexAscii10(ptrbuf,buf_in&0x000000ff);
}
*ptrbuf=0x00;
return bufferRetour;
}

char * hexAscii10(char *ptrtmp,unsigned int val)
{
int mod100=0,mod10;
if((mod100=val/100)>0){
*ptrtmp='0'+(char)mod100;
ptrtmp++;
}
val=val%100;
if(((mod10=val/10)>0)||(mod100>0)){
*ptrtmp='0'+(char)mod10;
ptrtmp++;
}
val=val%10;
*ptrtmp='0'+(char)val;
ptrtmp++;
return ptrtmp;
}
A voir également:

9 réponses

Réponse 1 / 9
Manu
23 oct. 2008 à 21:20
Bonjour,

printf("taille de l'adresse retour : %d octets \n",sizeof(inet_ntoa (...));

il m'écrit
taille de l'adresse retour : 4 octets

Ca ressemble plutôt à l'oubli d'inclusion de l'un ou l'autre des headers déclarant inet_ntoa(), cette fonction se retrouvant interprétée comme renvoyant un entier (4 octets).

Selon le man, il faut :

#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

Manu
3
djodj31
24 oct. 2008 à 16:02
si c'etait un oublie d'unclusion le probleme serait à la compilation.
mais le probleme est a l'execussion
ca devrait retourner 8 car je suis sous Linux 64 bits et non 4 comme ça le fait
0
Réponse 2 / 9
Manu
25 oct. 2008 à 08:20
Bonjour,

comment ce fait il que ce même source fonctionnait en version 32 bits sans l'inclusion arpa/inet?

Je rappelle (3ème fois) qu'une fonction non déclarée est considérée comme renvoyant un int (un entier à quatre octets dans votre cas). Comme en 32 bits, les pointeurs ont la même taille qu'un entier, ça ne se voit pas.

Mettez l'option -Wall (si gcc) pour avoir des avertissements à la compilation.

Manu
2
djodj31
25 oct. 2008 à 08:28
merci beaucoup
ça fonctionne parfaitement maintenant
0
Réponse 3 / 9
Manu
24 oct. 2008 à 18:49
Bonjour,

Désolé d'insister, mais dans votre exemple,

printf("taille de l'adresse retour : %d octets \n",sizeof(inet_ntoa (...));

faites un include de <arpa/inet.h> c'est là qu'est déclaré le inet_ntoa(), et à mon avis ça ira mieux.

Manu
1
Réponse 4 / 9
Manu
24 oct. 2008 à 18:55
Rebonjour,

si c'etait un oublie d'unclusion le probleme serait à la compilation.

Non, désolé, les déclarations externes ne sont pas obligatoires en C (pour cause de compatibilité avec l'ancêtre K&R). Par défaut les fonctions renvoient un int.

Pour que les compilateurs signalent le danger, il faut mettre une option de warning appropriée.

Manu.
1
djodj31
25 oct. 2008 à 06:38
reboujour,

En effet en incluant arpa/inet je n'ai plus le bug, mais alors comment ce fait il que je n'ai pas eu d'ereur lors de la compilation? y a t'il plusieurs definitions de cette fonction? (sinon j'aurais dû avoir des probleme d'entête à la compilation ou carement à l"édition des liens)
et comment ce fait il que ce même source fonctionnait en version 32 bits sans l'inclusion arpa/inet?

je suis un peu perplexe, des choses m'échappent.
0

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

Posez votre question
Réponse 5 / 9
djodj31
23 oct. 2008 à 20:45
merci pour la réponse
cedont je suis sûr c'est que si je fais
printf("taille de l'adresse retour : %d octets \n",sizeof(inet_ntoa (...));

il m'écrit
taille de l'adresse retour : 4 octets

donc forcement le code suivant

char * prfBuf;

ptrBuf= inet_ntoa (...);

ne peut focntionner car sur un 64bits sizeof(ptrBuf) retourne forcement 8 donc s'il y a affectation le pointeur va taper n'importe ou d'ou l'erreur de segmentation
0
Réponse 6 / 9
mamiemando Messages postés 33664 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 14 mai 2025 7 850
23 oct. 2008 à 20:20
Ce sera plutôt la version de libc et ou de noyau qui aura un impact (là où est implémentée inet_ntoa()) . Si tu es sûr de ton coup je t'invite à faire une remontée de bug auprès des développeurs concernés.

Bonne chance
-1
Réponse 7 / 9
mamiemando Messages postés 33664 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 14 mai 2025 7 850
24 oct. 2008 à 13:10
C'est bizarre effectivement si on regarde ici http://www.linux-france.org/article/man-fr/man3/inet_addr-3.html cette fonction retourne effectivement un char * (soit la taille d'un pointeur) et je ne vois pas pourquoi tu rencontres un problème...
-1
djodj31
24 oct. 2008 à 16:03
le probleme est que un poiteur sur un SE 64 bits c'est 8 octets et non 4 octets
0
Réponse 8 / 9
mamiemando Messages postés 33664 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 14 mai 2025 7 850
24 oct. 2008 à 16:57
Oui mais si le binaire dans lequel est implémenté la fonction (libc/noyau) est compilé en 64 bits également, ça devrait retourner une adresse 64 bits.
-1
djodj31
24 oct. 2008 à 17:09
oui, ça devrait.. mais ça ne retourne qu'une adresse 32 bits (ou plutot une partie de l'adresse 64 bits) . Il est possible que dans le source de la fonction l'adresse se retrouve a être sotckée dans un buffer de 4 octets (normal pour un 32bits) et n'ai pas ete mis à jour en version 64bits, puis que ce soit le contenu de ce buffer qui soit retournée sous le type char* ; je sais c'est un peut tiré par les cheveux mais les bug (si s'en est un) sont souvent issues de choses surprenantes.

je ne sais pas comment faire pour faire remonter ça .
0
Réponse 9 / 9
mamiemando Messages postés 33664 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 14 mai 2025 7 850
25 oct. 2008 à 00:14
Ceci dit tu peux tester ce qu'il te dit, ça ne mange pas de pain. Car un #include fait parfois d'autres choses que définir des variables et fonctions. Étant donné que dans le man signale qu'il faut inclure ces headers et de faire une éventuelle remontée de bug il me paraît souhaitable de se mettre dans les conditions d'utilisation spécifiées par le man.

Bonne chance
-1

Discussions similaires

Voxbone ? qui est-ce ?
fanfan54 -
djakool4 -

Bonjour,

J'ai reçu plusieurs appels aujourd'hui d'un n° de téléphone qui m'était inconnu (des numéros commençant par 09 48 ou 01 62 en général), après avoir recherché sur le net j'ai su qu'il s'agissait de VoxBone à Brussels. Je ne comprend pas comment ils peuvent me téléphoner alors que je suis à France télécom et orange et que je paie pour le stop secret, donc la personne devait se présenter.

Je me demande qui ils sont car, je n'ai rien compris. Y a T-il quelqu'un qui connait ? car j'étais absente et comment ils arrivent à passer outre "stop secret"

Merci pour l'explication

A vous lire Configuration: Windows 7 / Internet Explorer 9.0

158 réponses
Iptv beug
leogauthier15 -
bazfile -

Bonjour  jai un problème avec mon Iptv sur la télé je n’arrive pas a regarder mon match de foot en entier sans qu’il beug pareil pour les films j’ai une connexion haut débit mon abonnement terminé le 17 Novembre et depuis ce matin je n’arrive pas à faire la mise à jour des applications je ne comprend pas il est connecté à l’Internet 

1 réponse
Bug de chaîne IPTV
GeraltDeRiv13 -
bazfile -

Bonjour, j'ai récemment acquis une box tv avec une application iptv bref tout va bien ça marche parfaitement sauf que depuis hier la chaîne rmc sport 1 n'a plus de son ,l'image est parfaite mais le son a disparu je vais donc dans les paramètres pour voir si c'est pas moi qui ai désactivé la piste audio et je vois que l'audio est désactivé je l'active et ça bascule automatiquement sur désactivé, je précise que ça n'arrive que sur rmc sport 1 les autres chaîne du groupe rmc sport ou les chaîne en général n'ont pas ce problème . C'est un problème venant de la chaîne ou de l'application iptv ? Je n'ai vu personne se plaindre de bug sur les réseaux sociaux donc j'imagine que ça vient de l'iptv i...

1 réponse