In realtà nei sistemi Unix esiste un'altro modo per definire la funzione
\func{main}, che prevede la presenza di un terzo parametro, \code{char
- *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{sec:proc_environ})
+ *envp[]}, che fornisce l'\textsl{ambiente} (vedi sez.~\ref{sec:proc_environ})
del programma; questa forma però non è prevista dallo standard POSIX.1 per cui
se si vogliono scrivere programmi portabili è meglio evitarla.
Oltre alla conclusione ``\textsl{normale}'' esiste anche la possibilità di una
conclusione ``\textsl{anomala}'' del programma a causa della ricezione di un
segnale (si veda \capref{cha:signals}) o della chiamata alla funzione
-\func{abort}; torneremo su questo in \secref{sec:proc_termination}.
+\func{abort}; torneremo su questo in sez.~\ref{sec:proc_termination}.
Il valore di ritorno della funzione \func{main}, o quello usato nelle chiamate
ad \func{exit} e \func{\_exit}, viene chiamato \textsl{stato di uscita} (o
Si tenga presente inoltre che non è una buona idea usare il codice di errore
restituito dalla variabile \var{errno} (per i dettagli si veda
-\secref{sec:sys_errors}) come stato di uscita. In generale infatti una shell
+sez.~\ref{sec:sys_errors}) come stato di uscita. In generale infatti una shell
non si cura del valore se non per vedere se è diverso da zero; inoltre il
valore dello stato di uscita è sempre troncato ad 8 bit, per cui si potrebbe
incorrere nel caso in cui restituendo un codice di errore 256, si otterrebbe
La funzione \func{exit} è pensata per eseguire una conclusione pulita di un
programma che usi le librerie standard del C; essa esegue tutte le funzioni
che sono state registrate con \func{atexit} e \func{on\_exit} (vedi
-\secref{sec:proc_atexit}), e chiude tutti gli stream effettuando il
+sez.~\ref{sec:proc_atexit}), e chiude tutti gli stream effettuando il
salvataggio dei dati sospesi (chiamando \func{fclose}, vedi
-\secref{sec:file_fopen}), infine passa il controllo al kernel chiamando
+sez.~\ref{sec:file_fopen}), infine passa il controllo al kernel chiamando
\func{\_exit} e restituendo il valore di \param{status} come stato di uscita.
La system call \funcd{\_exit} restituisce direttamente il controllo al kernel,
La funzione chiude tutti i file descriptor appartenenti al processo (si tenga
presente che questo non comporta il salvataggio dei dati bufferizzati degli
stream), fa sì che ogni figlio del processo sia ereditato da \cmd{init} (vedi
-\secref{cha:process_handling}), manda un segnale \const{SIGCHLD} al processo
-padre (vedi \secref{sec:sig_job_control}) ed infine ritorna lo stato di uscita
+sez.~\ref{cha:process_handling}), manda un segnale \const{SIGCHLD} al processo
+padre (vedi sez.~\ref{sec:sig_job_control}) ed infine ritorna lo stato di uscita
specificato in \param{status} che può essere raccolto usando la funzione
-\func{wait} (vedi \secref{sec:proc_wait}).
+\func{wait} (vedi sez.~\ref{sec:proc_wait}).
\subsection{Le funzioni \func{atexit} e \func{on\_exit}}
in un sistema Unix l'unico modo in cui un programma può essere eseguito dal
kernel è attraverso la chiamata alla system call \func{execve} (o attraverso
una delle funzioni della famiglia \func{exec} che vedremo in
-\secref{sec:proc_exec}).
+sez.~\ref{sec:proc_exec}).
Allo stesso modo l'unico modo in cui un programma può concludere
volontariamente la sua esecuzione è attraverso una chiamata alla system call
\func{exit} o il ritorno di \func{main}.
Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
-normalmente un programma è riportato in \figref{fig:proc_prog_start_stop}.
+normalmente un programma è riportato in fig.~\ref{fig:proc_prog_start_stop}.
\begin{figure}[htb]
\centering
- \includegraphics[width=12cm]{img/proc_beginend}
+ \includegraphics[width=14cm]{img/proc_beginend}
\caption{Schema dell'avvio e della conclusione di un programma.}
\label{fig:proc_prog_start_stop}
\end{figure}
Si ricordi infine che un programma può anche essere interrotto dall'esterno
attraverso l'uso di un segnale (modalità di conclusione non mostrata in
-\figref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
+fig.~\ref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
\capref{cha:signals}.
segmento dati, a cui di solito è posto giusto di seguito. È qui che avviene
l'allocazione dinamica della memoria; può essere ridimensionato allocando e
disallocando la memoria dinamica con le apposite funzioni (vedi
- \secref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente
+ sez.~\ref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente
al segmento dati) ha una posizione fissa.
\item Il segmento di \textit{stack}, che contiene lo \textit{stack} del
\begin{figure}[htb]
\centering
- \includegraphics[width=5cm]{img/memory_layout}
+ \includegraphics[height=12cm]{img/memory_layout}
\caption{Disposizione tipica dei segmenti di memoria di un processo.}
\label{fig:proc_mem_layout}
\end{figure}
Una disposizione tipica di questi segmenti è riportata in
-\figref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma se
+fig.~\ref{fig:proc_mem_layout}. Usando il comando \cmd{size} su un programma se
ne può stampare le dimensioni dei segmenti di testo e di dati (inizializzati e
BSS); si tenga presente però che il BSS non è mai salvato sul file che
contiene l'eseguibile, dato che viene sempre inizializzato a zero al
\begin{itemize}
\item se la variabile è posta a zero gli errori vengono ignorati.
\item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
- (vedi \secref{sec:file_std_stream}).
+ (vedi sez.~\ref{sec:file_std_stream}).
\item se è posta a 2 viene chiamata \func{abort}, che in genere causa
l'immediata conclusione del programma.
\end{itemize}
evitare alla radice i problemi di memory leak\index{memory leak}, dato che non
serve più la deallocazione esplicita; inoltre la deallocazione automatica
funziona anche quando si usa \func{longjmp} per uscire da una subroutine con
-un salto non locale da una funzione (vedi \secref{sec:proc_longjmp}).
+un salto non locale da una funzione (vedi sez.~\ref{sec:proc_longjmp}).
Un altro vantaggio è che in Linux la funzione è molto più veloce di
\func{malloc} e non viene sprecato spazio, infatti non è necessario gestire un
chiamata, dato che all'uscita dalla funzione lo spazio allocato diventerebbe
libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni.
Questo è lo stesso problema che si può avere con le variabili automatiche, su
-cui torneremo in \secref{sec:proc_auto_var}.
+cui torneremo in sez.~\ref{sec:proc_auto_var}.
\subsection{Le funzioni \func{brk} e \func{sbrk}}
Queste due funzioni vengono utilizzate soltanto quando è necessario effettuare
direttamente la gestione della memoria associata allo spazio dati di un
processo, ad esempio qualora si debba implementare la propria versione delle
-routine di allocazione della memoria viste in \secref{sec:proc_mem_malloc}. La
-prima funzione è \funcd{brk}, ed il suo prototipo è:
+routine di allocazione della memoria viste in sez.~\ref{sec:proc_mem_malloc}.
+La prima funzione è \funcd{brk}, ed il suo prototipo è:
\begin{prototype}{unistd.h}{int brk(void *end\_data\_segment)}
Sposta la fine del segmento dei dati.
l'indirizzo finale del segmento dati di un processo all'indirizzo specificato
da \param{end\_data\_segment}. Quest'ultimo deve essere un valore ragionevole,
ed inoltre la dimensione totale del segmento non deve comunque eccedere un
-eventuale limite (si veda \secref{sec:sys_resource_limit}) imposto sulle
+eventuale limite (si veda sez.~\ref{sec:sys_resource_limit}) imposto sulle
dimensioni massime dello spazio dati del processo.
La seconda funzione per la manipolazione delle dimensioni del segmento
\subsection{Il controllo della memoria virtuale\index{memoria virtuale}}
\label{sec:proc_mem_lock}
-Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria
+Come spiegato in sez.~\ref{sec:proc_mem_gen} il kernel gestisce la memoria
virtuale in maniera trasparente ai processi, decidendo quando rimuovere pagine
dalla memoria per metterle nello swap, sulla base dell'utilizzo corrente da
parte dei vari processi.
quali pagine di memoria è opportuno che restino in memoria per un aumento
delle prestazioni. In genere queste sono esigenze particolari e richiedono
anche un aumento delle priorità in esecuzione del processo (vedi
- \secref{sec:proc_real_time}).
+ sez.~\ref{sec:proc_real_time}).
\item \textsl{La sicurezza}. Se si hanno password o chiavi segrete in chiaro
in memoria queste possono essere portate su disco dal meccanismo della
comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
tutti i suoi \textit{memory lock}. Infine \textit{memory lock} non sono
ereditati dai processi figli.\footnote{ma siccome Linux usa il \textit{copy on
- write}\index{copy on write} (vedi \secref{sec:proc_fork}) gli indirizzi
+ write}\index{copy on write} (vedi sez.~\ref{sec:proc_fork}) gli indirizzi
virtuali del figlio sono mantenuti sullo stesso segmento di RAM del padre,
quindi fintanto che un figlio non scrive su un segmento, può usufruire del
memory lock del padre.}
Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
la memoria fisica disponibile nel sistema, questo ha un evidente impatto su
tutti gli altri processi, per cui solo un processo con i privilegi di
-amministratore (vedremo in \secref{sec:proc_perms} cosa significa) ha la
+amministratore (vedremo in sez.~\ref{sec:proc_perms} cosa significa) ha la
capacità di bloccare una pagina. Ogni processo può però sbloccare le pagine
relative alla propria memoria.
vengono lanciati. Il passaggio dei parametri è effettuato attraverso gli
argomenti \param{argc} e \param{argv} della funzione \func{main}, che vengono
passati al programma dalla shell (o dal processo che esegue la \func{exec},
-secondo le modalità che vedremo in \secref{sec:proc_exec}) quando questo viene
-messo in esecuzione.
+secondo le modalità che vedremo in sez.~\ref{sec:proc_exec}) quando questo
+viene messo in esecuzione.
Oltre al passaggio dei parametri, un'altra modalità che permette di passare
delle informazioni che modifichino il comportamento di un programma è quello
in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
variabile \param{argc} viene inizializzata al numero di parametri trovati, in
questo modo il primo parametro è sempre il nome del programma; un esempio di
-questo meccanismo è mostrato in \figref{fig:proc_argv_argc}.
+questo meccanismo è mostrato in fig.~\ref{fig:proc_argv_argc}.
\subsection{La gestione delle opzioni}
un'opzione. In genere le opzioni sono costituite da una lettera singola
(preceduta dal carattere \cmd{'-'}) e possono avere o no un parametro
associato; un comando tipico può essere quello mostrato in
-\figref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m}
+fig.~\ref{fig:proc_argv_argc}. In quel caso le opzioni sono \cmd{-r} e \cmd{-m}
e la prima vuole un parametro mentre la seconda no (\cmd{questofile.txt} è un
argomento del programma, non un parametro di \cmd{-m}).
La stringa \param{optstring} indica quali sono le opzioni riconosciute ed è
costituita da tutti i caratteri usati per identificare le singole opzioni, se
l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
-due punti \texttt{':'}; nel caso di \figref{fig:proc_argv_argc} ad esempio la
+due punti \texttt{':'}; nel caso di fig.~\ref{fig:proc_argv_argc} ad esempio la
stringa di opzioni avrebbe dovuto contenere \texttt{"r:m"}.
La modalità di uso di \func{getopt} è pertanto quella di chiamare più volte la
\item \var{int optopt} contiene il carattere dell'opzione non riconosciuta.
\end{itemize*}
-In \figref{fig:proc_options_code} è mostrata la sezione del programma
+In fig.~\ref{fig:proc_options_code} è mostrata la sezione del programma
\file{ForkTest.c} (che useremo nel prossimo capitolo per effettuare dei test
sulla creazione dei processi) deputata alla decodifica delle opzioni a riga di
comando.
\includecodesnip{listati/env_ptr.c}
un esempio della struttura di questa lista, contenente alcune delle variabili
più comuni che normalmente sono definite dal sistema, è riportato in
-\figref{fig:proc_envirno_list}.
+fig.~\ref{fig:proc_envirno_list}.
\begin{figure}[htb]
\centering
\includegraphics[width=11cm]{img/environ_var}
Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
\textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate
-in \figref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
+in fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
usare nomi espressi in caratteri maiuscoli.\footnote{la convenzione vuole che
si usino dei nomi maiuscoli per le variabili di ambiente di uso generico, i
dover ricorrere all'uso di opzioni a linea di comando o di file di
configurazione. É di norma cura della shell, quando esegue un comando, passare
queste variabili al programma messo in esecuzione attraverso un uso opportuno
-delle relative chiamate (si veda \secref{sec:proc_exec}).
+delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
La shell ad esempio ne usa molte per il suo funzionamento (come \var{PATH} per
la ricerca dei comandi, o \cmd{IFS} per la scansione degli argomenti), e
alcune di esse (come \var{HOME}, \var{USER}, etc.) sono definite al login (per
-i dettagli si veda \secref{sec:sess_login}). In genere è cura
+i dettagli si veda sez.~\ref{sec:sess_login}). In genere è cura
dell'amministratore definire le opportune variabili di ambiente in uno script
di avvio. Alcune servono poi come riferimento generico per molti programmi
(come \var{EDITOR} che indica l'editor preferito da invocare in caso di
necessità).
Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
-comuni), come riportato in \tabref{tab:proc_env_var}. GNU/Linux le supporta
+comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
tutte e ne definisce anche altre: per una lista più completa si può
controllare \cmd{man environ}.
C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema
delle funzioni previste nei vari standard e disponibili in Linux è riportato
-in \tabref{tab:proc_env_func}.
+in tab.~\ref{tab:proc_env_func}.
\begin{table}[htb]
\centering
In Linux\footnote{in realtà nelle libc4 e libc5 sono definite solo le prime
quattro, \func{clearenv} è stata introdotta con le \acr{glibc} 2.0.} sono
-definite tutte le funzioni elencate in \tabref{tab:proc_env_func}. La prima,
+definite tutte le funzioni elencate in tab.~\ref{tab:proc_env_func}. La prima,
\func{getenv}, l'abbiamo appena esaminata; delle restanti le prime due,
\funcd{putenv} e \funcd{setenv}, servono per assegnare nuove variabili di
ambiente, i loro prototipi sono i seguenti:
variabili di ambiente; pertanto ogni cambiamento alla stringa in questione si
riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
questa funzione una variabile automatica (per evitare i problemi esposti in
-\secref{sec:proc_auto_var}).
+sez.~\ref{sec:proc_auto_var}).
Si tenga infine presente che se si passa a \func{putenv} solo il nome di una
variabile (cioè \param{string} è nella forma \texttt{NAME} e non contiene un
corrente sarà deallocata solo se anch'essa è risultante da un'allocazione
fatta in precedenza da un'altra \func{putenv}. Questo perché il vettore delle
variabili di ambiente iniziale, creato dalla chiamata ad \func{exec} (vedi
-\secref{sec:proc_exec}) è piazzato al di sopra dello stack, (vedi
-\figref{fig:proc_mem_layout}) e non nello heap e non può essere deallocato.
+sez.~\ref{sec:proc_exec}) è piazzato al di sopra dello stack, (vedi
+fig.~\ref{fig:proc_mem_layout}) e non nello heap e non può essere deallocato.
Inoltre la memoria associata alle variabili di ambiente eliminate non viene
liberata.
questo si usa il cosiddetto \textit{value result argument}, si passa cioè,
invece di una normale variabile, un puntatore alla stessa; vedremo alcuni
esempi di questa modalità nelle funzioni che gestiscono i socket (in
-\secref{sec:TCP_functions}), in cui, per permettere al kernel di restituire
+sez.~\ref{sec:TCP_functions}), in cui, per permettere al kernel di restituire
informazioni sulle dimensioni delle strutture degli indirizzi utilizzate,
viene usato questo meccanismo.
abbia sempre almeno un argomento fisso; prima di effettuare la dichiarazione
deve essere incluso l'apposito header file \file{stdarg.h}; un esempio di
dichiarazione è il prototipo della funzione \func{execl} che vedremo in
-\secref{sec:proc_exec}:
+sez.~\ref{sec:proc_exec}:
\includecodesnip{listati/exec_sample.c}
in questo caso la funzione prende due parametri fissi ed un numero variabile
di altri parametri (che verranno a costituire gli elementi successivi al primo
le relative informazioni sono raggiungibili, scritti nell'ordine in cui si
vuole siano interrogati.
-Ciascun servizio è specificato a sua volta da un nome, come \texttt{file},
+Ogni servizio è specificato a sua volta da un nome, come \texttt{file},
\texttt{dns}, \texttt{db}, ecc. che identifica la libreria dinamica che
-realizza l'interfaccia con esso, che per ciascuno di essi sarà realizzata in
-un file \texttt{libnss\_NAME} dove \texttt{NAME} è appunto il nome
-
-
-
+realizza l'interfaccia con esso. Per ciascun servizio se \texttt{NAME} è il
+nome utilizzato dentro \file{/etc/nsswitch.conf}, dovrà essere presente
+(usualmente in \file{/lib}) una libreria \texttt{libnss\_NAME} che ne
+implementa le funzioni.
In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto
su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive
quelle che tratteremo nelle sezioni successive.
+\subsection{Le funzioni di interrogazione del \textit{resolver}}
+\label{sec:sock_resolver_functions}
+
+Prima di trattare le funzioni usate normalmente nella risoluzione dei nomi a
+dominio conviene trattare in maniera più dettagliata il meccanismo principale
+da esse utilizzato e cioè quello del servizio DNS. Come accennato questo,
+benché in teoria sia solo uno dei possibili supporti su cui mantenere le
+relative informazioni, in pratica costituisce il meccanismo principale
+
+
+Per questo motivo il \textit{resolver} prevede delle funzioni che permettono
+sia di eseguire direttamente delle interrogazione ad un server DNS, che di
+controllare le modalità con cui queste vengono eseguite; diventa così
+possibile modificare da programma buona parte dei parametri controllati da
+\file{/etc/resolv.conf}.
+
+
+
+Per capire meglio il contenuto della struttura \struct{hostent} conviene
+spendere alcune parole sul funzionamento del DNS. Questo in sostanza è un
+database distribuito organizzato in maniera gerarchica, interrogando il quale
+si possono avere una serie di informazioni, la principale delle quali è la
+corrispondenza fra un nome (a dominio) ed indirizzo IP. Un server DNS
+contiene comunque una serie di altre informazioni; ciascuna voce nel database
+viene chiamata \textit{resource record} e vi è associato un certo
+\textsl{tipo}, identificato da una sigla. Per quanto ci interessa i tipi di
+\textit{resource record} che vengono utilizzati dal \textit{resolver} sono
+sostanzialmente i seguenti:
+\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
+\item[\texttt{A}] indica la corripondenza fra un nome a dominio ed un
+ indirizzo IPv4, ad esempio la corrispondenza fra \texttt{dodds.truelite.it}
+ e l'indirizzo IP \texttt{62.48.34.25}.
+\item[\texttt{AAAA}] chiamato in questo modo dato che la dimensione è quattro
+ volte quella di un indirizzo IPv4, questo record contiene la corrispondenza
+ fra un nome a dominio ed un indirizzo IPv6.
+\item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed
+ un nome a dominio si utilizza invece questo tipo di record (il cui nome sta
+ per \textit{pointer}).
+\item[\texttt{CNAME}] qualora si abbiamo più nomi con i quali si voglia
+ indicare lo stesso indirizzo (ad esempio \texttt{www.truelite.it}, o
+ \texttt{sources.truelite.it}, che comunque fanno sempre riferimento alla
+ macchina \texttt{dodds.truelite.it}) si può usare questo tipo di record per
+ creare degli \textit{alias} in modo da associare un qualunque altro nome al
+ \textsl{nome canonico} della macchina (quello associato al record
+ \texttt{A}).
+\end{basedescript}
+
+
\subsection{La risoluzione dei nomi a dominio}
\label{sec:sock_gethostbyname}
di un server DNS, si può ritentare l'interrogazione in un secondo tempo.
\end{basedescript}
-Per capire meglio il contenuto della struttura \struct{hostent} conviene
-spendere alcune parole sul funzionamento del DNS. Questo in sostanza è un
-database distribuito organizzato in maniera gerarchica, interrogando il quale
-si possono avere una serie di informazioni, la principale delle quali è la
-corrispondenza fra un nome (a dominio) ed indirizzo IP. Un server DNS
-contiene comunque una serie di altre informazioni; ciascuna voce nel database
-viene chiamata \textit{resource record} e vi è associato un certo
-\textsl{tipo}, identificato da una sigla. Per quanto ci interessa i tipi di
-\textit{resource record} che vengono utilizzati dal \textit{resolver} sono
-sostanzialmente i seguenti:
-\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\texttt{A}] indica la corripondenza fra un nome a dominio ed un
- indirizzo IPv4, ad esempio la corrispondenza fra \texttt{dodds.truelite.it}
- e l'indirizzo IP \texttt{62.48.34.25}.
-\item[\texttt{AAAA}] chiamato in questo modo dato che la dimensione è quattro
- volte quella di un indirizzo IPv4, questo record contiene la corrispondenza
- fra un nome a dominio ed un indirizzo IPv6.
-\item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed
- un nome a dominio si utilizza invece questo tipo di record (il cui nome sta
- per \textit{pointer}).
-\item[\texttt{CNAME}] qualora si abbiamo più nomi con i quali si voglia
- indicare lo stesso indirizzo (ad esempio \texttt{www.truelite.it}, o
- \texttt{sources.truelite.it}, che comunque fanno sempre riferimento alla
- macchina \texttt{dodds.truelite.it}) si può usare questo tipo di record per
- creare degli \textit{alias} in modo da associare un qualunque altro nome al
- \textsl{nome canonico} della macchina (quello associato al record
- \texttt{A}).
-\end{basedescript}
-
Quando un programma chiama \func{gethostbyname} e questa usa il DNS per
effettuare la risoluzione del nome, è con i valori di questi record che
vengono riempite le varie parti della struttura \struct{hostent}. Il primo
Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo
che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o
\const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la
-lunghezza dell'indirizzo stesso in byte. Infine il campo \var{h\_addr\_list} è
-il puntatore ad un vettore di puntatori ai singoli indirizzi; il vettore è
-terminato da un puntatore nullo. Inoltre, come illustrato in
-fig.~\ref{fig:sock_hostent_struct}, viene definito il campo \var{h\_addr} come
-sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento diretto al primo
-indirizzo della lista.
-
-
+lunghezza dell'indirizzo stesso in byte. La funzione ritorna sempre una
+struttura
+
+Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori
+ai singoli indirizzi; il vettore è terminato da un puntatore nullo. Inoltre,
+come illustrato in fig.~\ref{fig:sock_hostent_struct}, viene definito il campo
+\var{h\_addr} come sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento
+diretto al primo indirizzo della lista.
Oltre ai normali nomi a dominio la funzione accetta come argomento
\param{name} anche indirizzi numerici, in formato dotted decimal per IPv4 o
projects / gapil.git / commitdiff