Provided by: manpages-fr_1.67.0-1_all bug

NOM

       getnameinfo  -  Traduction  d’adresse  en  nom de façon indépendante du
       protocole

SYNOPSIS

       #include <sys/socket.h>
       #include <netdb.h>

       int getnameinfo(const struct sockaddr *sa, socklen_t salen,
                       char *host, size_t hostlen,
                       char *serv, size_t servlen, int flags);

DESCRIPTION

       La fonction getnameinfo(3) est définie afin de traduire des adresses en
       noms  de  noeuds  de  façon indépendante du protocole. Elle combine les
       fonctionnalités de gethostbyaddr(3) et getservbyport(3) et constitue la
       réciproque  de  getaddrinfo(3).   Le  paramètre sa est un pointeur vers
       l’adresse d’une structure de socket générique (de type  sockaddr_in  ou
       sockaddr_in6)  de taille salen qui contient l’adresse IP d’entrée et le
       numéro de port.  Les parmètres host et serv sont des pointeurs vers des
       tampons  (de  tailles  respectives  hostlen  et  servlen  )  destinés à
       recevoir les valeurs renvoyées.

       L’appelant peut préciser  qu’aucun  nom  d’hôte  (ou  qu’aucun  nom  de
       service)  n’est nécessaire en fournissant NULL comme paramètre host (ou
       serv) ou bien en passant un argument hostlen (ou servlen) valant  zéro.
       Quoi  qu’il  en  soit, au moins un nom d’hôte ou un nom de service doit
       être demandé.

       Le paramètre flags modifie  le  comportement  de  getnameinfo(3)  comme
       indiqué ci dessous :

       NI_NOFQDN
              renvoie  seulement  la  partie  nom  de  l’hôte  du FQDN (Fully-
              Qualified Domain Name) pour les hôtes locaux.

       NI_NUMERICHOST
              La forme numérique du nom de l’hôte est renvoyée.  (Même  si  ce
              drapeau  n’est  pas levé, cela arrivera également lorsque le nom
              du noeud ne pourra pas être résolu.)

       NI_NAMEREQD
              renvoie une erreur si le nom de l’hôte ne peut être résolu.

       NI_NUMERICSERV
              L’adresse du service est  renvoyée  sous  forme  numérique,  par
              exemple sous la forme de son numéro de port.

       NI_DGRAM
              Indique que le service est plutôt basé sur des datagrammes (UDP)
              que sur un flux connecté (TCP). Ce drapeau est  nécessaire  pour
              les  quelques  ports  (512-514)  qui ont des services différents
              selon le protocole utilisé : UDP ou TCP.

VALEUR RENVOYÉE

       En cas de succès, 0 est renvoyé, et, les noms du noeud et  du  service,
       s’ils  sont  demandés,  sont  renseignés  sous  forme de chaînes à zéro
       terminal, éventuellement tronquées afin de s’adapter  aux  tailles  des
       tampons spécifiés.  En cas d’erreur, une valeur non nulle est renvoyée,
       et errno est affectée de façon adéquate.

ERREURS

       EAI_AGAIN
              Le nom ne peut être résolu en ce moment. Réessayer plus tard.

       EAI_BADFLAGS
              Le paramètre flags n’est pas valide.

       EAI_FAIL
              Une erreur irrécupérable est survenue.

       EAI_FAMILY
              La famille d’adresse n’a pas été reconnue, ou bien la taille  de
              l’adresse était invalide pour la famille spécifiée.

       EAI_MEMORY
              Pas assez de mémoire.

       EAI_NONAME
              Le  nom  ne  peut  être  résolu  avec  les  paramètres  fournis.
              NI_NAMEREQD est spécifié et  le  nom  de  l’hôte  ne  peut  être
              localisé,  ou bien, on n’a demandé ni un nom d’hôte ni un nom de
              service.

       EAI_SYSTEM
              Une erreur système a eu lieu. Le code d’erreur peut être lu dans
              errno.

FICHIERS

       /etc/hosts
       /etc/nsswitch.conf
       /etc/resolv.conf

NOTE

       Afin  d’aider  les programmeurs à choisir des tailles raisonnables pour
       les tampons fournis, <netdb.h> définit les constantes
              # define NI_MAXHOST      1025
              # define NI_MAXSERV      32
       La première est  la  constante  MAXDNAME  présente  dans  les  versions
       récentes  du  fichier header <arpa/nameser.h> de BIND.  La deuxième est
       déterminée en se basant  sur  les  services  répertoriés  dans  la  RFC
       "Assigned numbers" (Numéros affectés) actuelle.

EXEMPLES

       Le  code  suivant essaie d’obtenir le nom de l’hôte ainsi que le nom du
       service sous forme numérique, et ce, pour une adresse de socket donnée.
       Remarquez qu’il
        n’y  a  aucune  référence  à une quelconque famille d’adresse codée en
       dur.

                struct sockaddr *sa;    /* input */
                char hbuf[NI_MAXHOST], sbuf[NI_MAXSERV];

                if (getnameinfo(sa, sa->sa_len, hbuf, sizeof(hbuf), sbuf,
                    sizeof(sbuf), NI_NUMERICHOST | NI_NUMERICSERV) == 0)
                        printf("host=%s, serv=%s\n", hbuf, sbuf);

       La version suivante vérifie si l’adresse de  la  socket  peut  se  voir
       associer un nom.

                struct sockaddr *sa;    /* input */
                char hbuf[NI_MAXHOST];

                if (getnameinfo(sa, sa->sa_len, hbuf, sizeof(hbuf),
                    NULL, 0, NI_NAMEREQD))
                       printf("could not resolve hostname");
                else
                       printf("host=%s\n", hbuf);

CONFORMITÉ

       RFC 2553. (Voir aussi XNS, révision 5.2.)

VOIR AUSSI

       getaddrinfo(3),  gethostbyaddr(3),  getservbyname(3), getservbyport(3),
       inet_ntop(3), socket(3), hosts(5), services(5), hostname(7), named(8)

       R. Gilligan, S. Thomson, J. Bound et W. Stevens, Basic Socket Interface
       Extensions for IPv6, RFC 2553, Mars 1999.

       Tatsuya  Jinmei et Atsushi Onoe, An Extension of Format for IPv6 Scoped
       Addresses,      internet      draft,      travail       en       cours.
       ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-scopedaddr-
       format-02.txt

       Craig Metz, Protocol Independence Using the Sockets API,  compte  rendu
       du  sujet  freenix :  conférence  technique  annuelle USENIX 2000, juin
       2000.
       http://www.usenix.org/publications/library/proceedings/usenix2000/freenix/metzprotocol.html

TRADUCTION

       Stéphan Rafin, 2002.