header file POSIX e ANSI C.
risorsa avrebbe causato un \textit{deadlock}\index{\textit{deadlock}}. Non
sempre il sistema è in grado di riconoscere queste situazioni, nel qual caso
si avrebbe il blocco.
-\item \errcode{EFAULT} \textit{Bad address}. Una stringa passata come parametro
+\item \errcode{EFAULT} \textit{Bad address}. Una stringa passata come argomento
è fuori dello spazio di indirizzi del processo, in genere questa situazione
provoca l'emissione di un segnale di \textit{segment violation}
(\const{SIGSEGV}).
abilitato l'opportuno supporto nel kernel; nel caso di Linux questo può
voler dire anche che un modulo necessario non è stato caricato nel sistema.
\item \errcode{ENOTSUP} \textit{Not supported}. Una funzione ritorna questo
- errore quando i parametri sono validi ma l'operazione richiesta non è
+ errore quando gli argomenti sono validi ma l'operazione richiesta non è
supportata. Questo significa che la funzione non implementa quel particolare
comando o opzione o che, in caso di oggetti specifici (file descriptor o
altro) non è in grado di supportare i parametri richiesti.
lock (bloccante o meno), a seconda dell'opzione \cmd{-b}.
Il programma inizia col controllare (\texttt{\small 11--14}) che venga passato
-un parametro (il file da bloccare), che sia stato scelto (\texttt{\small
+un argomento (il file da bloccare), che sia stato scelto (\texttt{\small
15--18}) il tipo di lock, dopo di che apre (\texttt{\small 19}) il file,
uscendo (\texttt{\small 20--23}) in caso di errore. A questo punto il
comportamento dipende dalla semantica scelta; nel caso sia BSD occorre
trovato coi sorgenti allegati nel file \file{myls.c}.
In sostanza tutto quello che fa il programma, dopo aver controllato
-(\texttt{\small 10--13}) di avere almeno un parametro (che indicherà la
+(\texttt{\small 10--13}) di avere almeno un argomento (che indicherà la
directory da esaminare) è chiamare (\texttt{\small 14}) la funzione
\func{DirScan} per eseguire la scansione, usando la funzione \code{do\_ls}
(\texttt{\small 20--26}) per fare tutto il lavoro.
prefisso la directory specificata da \const{P\_tmpdir}.
Di questa funzione esiste una versione rientrante, \func{tmpnam\_r}, che non
-fa nulla quando si passa \val{NULL} come parametro. Una funzione simile,
+fa nulla quando si passa \val{NULL} come argomento. Una funzione simile,
\funcd{tempnam}, permette di specificare un prefisso per il file
esplicitamente, il suo prototipo è:
\begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}
nessuna forma di bufferizzazione per ottimizzare le operazioni di I/O.
In \cite{APUE} Stevens descrive una serie di test sull'influenza delle
-dimensioni del blocco di dati (il parametro \param{buf} di \func{read} e
+dimensioni del blocco di dati (l'argomento \param{buf} di \func{read} e
\func{write}) nell'efficienza nelle operazioni di I/O con i file descriptor,
evidenziando come le prestazioni ottimali si ottengano a partire da dimensioni
del buffer dei dati pari a quelle dei blocchi del filesystem (il valore dato
usare sempre puntatori del tipo \ctyp{FILE *} ottenuti dalla libreria stessa
(tanto che in certi casi il termine di puntatore a file è diventato sinonimo
di stream). Tutte le funzioni della libreria che operano sui file accettano
-come parametri solo variabili di questo tipo, che diventa accessibile
+come argomenti solo variabili di questo tipo, che diventa accessibile
includendo l'header file \file{stdio.h}.
meccanismo visto in sez.~\ref{sec:proc_var_passing}; per questo motivo se
si passa un'espressione si possono avere effetti indesiderati.
-Invece \func{fgetc} è assicurata essere sempre una funzione, per questo
-motivo la sua esecuzione normalmente è più lenta per via dell'overhead
-della chiamata, ma è altresì possibile ricavarne l'indirizzo, che può
-essere passato come parametro ad un altra funzione (e non si hanno i
-problemi accennati in precedenza nel tipo di argomento).
+Invece \func{fgetc} è assicurata essere sempre una funzione, per questo motivo
+la sua esecuzione normalmente è più lenta per via dell'overhead della
+chiamata, ma è altresì possibile ricavarne l'indirizzo, che può essere passato
+come argomento ad un altra funzione (e non si hanno i problemi accennati in
+precedenza nel tipo di argomento).
Le tre funzioni restituiscono tutte un \ctyp{unsigned char} convertito
ad \ctyp{int} (si usa \ctyp{unsigned char} in modo da evitare
fine del file il valore di ritorno è \val{EOF}.}
\end{functions}
-Tutte queste funzioni scrivono sempre un byte alla volta, anche se
-prendono come parametro un \ctyp{int} (che pertanto deve essere ottenuto
-con un cast da un \ctyp{unsigned char}). Anche il valore di ritorno è
-sempre un intero; in caso di errore o fine del file il valore di ritorno
-è \val{EOF}.
+Tutte queste funzioni scrivono sempre un byte alla volta, anche se prendono
+come argomento un \ctyp{int} (che pertanto deve essere ottenuto con un cast da
+un \ctyp{unsigned char}). Anche il valore di ritorno è sempre un intero; in
+caso di errore o fine del file il valore di ritorno è \val{EOF}.
Come nel caso dell'I/O binario con \func{fread} e \func{fwrite} le \acr{glibc}
provvedono come estensione, per ciascuna delle funzioni precedenti,
La funzione permette di eseguire una lettura senza doversi preoccupare della
eventuale lunghezza eccessiva della stringa da leggere. Essa prende come primo
-parametro l'indirizzo del puntatore al buffer su cui si vuole copiare la
+argomento l'indirizzo del puntatore al buffer su cui si vuole copiare la
linea. Quest'ultimo \emph{deve} essere stato allocato in precedenza con una
\func{malloc} (non si può passare l'indirizzo di un puntatore ad una variabile
-locale); come secondo parametro la funzione vuole l'indirizzo della variabile
+locale); come secondo argomento la funzione vuole l'indirizzo della variabile
contenente le dimensioni del buffer suddetto.
Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta
subito, altrimenti il buffer viene allargato usando \func{realloc} e la nuova
dimensione ed il nuovo puntatore vengono passata indietro (si noti infatti
-come per entrambi i parametri si siano usati dei
+come per entrambi gli argomenti si siano usati dei
\index{\textit{value~result~argument}}\textit{value result argument}, passando
dei puntatori anziché i valori delle variabili, secondo la tecnica spiegata in
sez.~\ref{sec:proc_var_passing}).
La parte più complessa delle funzioni di scrittura formattata è il formato
della stringa \param{format} che indica le conversioni da fare, e da cui
-deriva anche il numero dei parametri che dovranno essere passati a seguire (si
-noti come tutte queste funzioni siano \textit{variadic}\index{variadic},
+deriva anche il numero degli argomenti che dovranno essere passati a seguire
+(si noti come tutte queste funzioni siano \textit{variadic}\index{variadic},
prendendo un numero di argomenti variabile che dipende appunto da quello che
si è specificato in \param{format}).
\end{functions}
\noindent con queste funzioni diventa possibile selezionare gli argomenti che
si vogliono passare ad una routine di stampa, passando direttamente la lista
-tramite il parametro \param{ap}. Per poter far questo ovviamente la lista dei
-parametri dovrà essere opportunamente trattata (l'argomento è esaminato in
+tramite l'argomento \param{ap}. Per poter far questo ovviamente la lista degli
+argomenti dovrà essere opportunamente trattata (l'argomento è esaminato in
sez.~\ref{sec:proc_variadic}), e dopo l'esecuzione della funzione l'argomento
\param{ap} non sarà più utilizzabile (in generale dovrebbe essere eseguito un
\code{va\_end(ap)} ma in Linux questo non è necessario).
\bodydesc{Le funzioni ritornano il numero di caratteri stampati.}
\end{functions}
-Entrambe le funzioni prendono come parametro \param{strptr} che deve essere
+Entrambe le funzioni prendono come argomento \param{strptr} che deve essere
l'indirizzo di un puntatore ad una stringa di caratteri, in cui verrà
restituito (si ricordi quanto detto in sez.~\ref{sec:proc_var_passing} a
proposito dei \index{\textit{value~result~argument}}\textit{value result
\headdecl{stdio.h} \funcdecl{int scanf(const char *format, ...)} Esegue una
scansione di \file{stdin} cercando una corrispondenza di quanto letto con il
formato dei dati specificato da \param{format}, ed effettua le relative
- conversione memorizzando il risultato nei parametri seguenti.
+ conversione memorizzando il risultato negli argomenti seguenti.
\funcdecl{int fscanf(FILE *stream, const char *format, ...)} Analoga alla
precedente, ma effettua la scansione su \param{stream}.
Le funzioni leggono i caratteri dallo stream (o dalla stringa) di input ed
eseguono un confronto con quanto indicato in \param{format}, la sintassi di
-questo parametro è simile a quella usata per l'analogo di \func{printf}, ma ci
+questo argomento è simile a quella usata per l'analogo di \func{printf}, ma ci
sono varie differenze. Le funzioni di input infatti sono più orientate verso
la lettura di testo libero che verso un input formattato in campi fissi. Uno
spazio in \param{format} corrisponde con un numero qualunque di caratteri di
rispetto al record corrente).
Tutto questo comporta la presenza di diverse funzioni che eseguono
-sostanzialmente le stesse operazioni, ma usano parametri di tipo diverso. Le
+sostanzialmente le stesse operazioni, ma usano argomenti di tipo diverso. Le
funzioni tradizionali usate per il riposizionamento della posizione in uno
stream sono \funcd{fseek} e \funcd{rewind} i cui prototipi sono:
\begin{functions}
\end{functions}
L'uso di \func{fseek} è del tutto analogo a quello di \func{lseek} per i file
-descriptor, ed i parametri, a parte il tipo, hanno lo stesso significato; in
+descriptor, e gli argomenti, a parte il tipo, hanno lo stesso significato; in
particolare \param{whence} assume gli stessi valori già visti in
sez.~\ref{sec:file_lseek}. La funzione restituisce 0 in caso di successo e -1
in caso di errore. La funzione \func{rewind} riporta semplicemente la
\const{\_IOFBF} & \textit{fully buffered}\\
\hline
\end{tabular}
- \caption{Valori del parametro \param{mode} di \func{setvbuf}
- per l'impostazione delle modalità di bufferizzazione.}
+ \caption{Valori dell'argomento \param{mode} di \func{setvbuf}
+ per l'impostazione delle modalità di bufferizzazione.}
\label{tab:file_stream_buf_mode}
\end{table}
Per evitare che \func{setvbuf} imposti il buffer basta passare un valore
-\val{NULL} per \param{buf} e la funzione ignorerà il parametro \param{size}
+\val{NULL} per \param{buf} e la funzione ignorerà l'argomento \param{size}
usando il buffer allocato automaticamente dal sistema. Si potrà comunque
modificare la modalità di bufferizzazione, passando in \param{mode} uno degli
opportuni valori elencati in tab.~\ref{tab:file_stream_buf_mode}. Qualora si
specifiche di ogni dispositivo particolare, usando come riferimento il solito
file descriptor. Il prototipo di questa funzione è:
\begin{prototype}{sys/ioctl.h}{int ioctl(int fd, int request, ...)}
- Manipola il dispositivo sottostante, usando il parametro \param{request} per
- specificare l'operazione richiesta ed il terzo parametro (usualmente di tipo
+ Manipola il dispositivo sottostante, usando l'argomento \param{request} per
+ specificare l'operazione richiesta ed il terzo argomento (usualmente di tipo
\param{char * argp} o \param{int argp}) per il trasferimento
dell'informazione necessaria.
propri programmi; per ciascuna funzione che tratteremo in seguito
indicheremo anche gli \textit{header file} necessari ad usarla.} (anch'essi
provvisti dalla \acr{glibc}), In tab.~\ref{tab:intro_posix_header} si sono
-riportati i principali \textit{header file} definiti nello standard POSIX,
-insieme a quelli definiti negli altri standard descritti nelle sezioni
-successive.
+riportati i principali \textit{header file} definiti nello standard POSIX ed
+ANSI C, che sono anche quelli definiti negli altri standard descritti nelle
+sezioni successive.
\begin{table}[htb]
\footnotesize
& ANSI C& POSIX& \\
\hline
\hline
- \file{assert.h}&$\bullet$&$\bullet$& Verifica le asserzioni fatte in un
- programma.\\
- \file{errno.h} &$\bullet$&$\bullet$& Errori di sistema.\\
- \file{fcntl.h} &$\bullet$&$\bullet$& Controllo sulle opzioni dei file.\\
- \file{limits.h}&$\bullet$&$\bullet$& Limiti e parametri del sistema.\\
- \file{} &$\bullet$&$\bullet$& .\\
- \file{} &$\bullet$&$\bullet$& .\\
- \file{} &$\bullet$&$\bullet$& .\\
- \file{} &$\bullet$&$\bullet$& .\\
- \file{} &$\bullet$&$\bullet$& .\\
- \file{stdio.h} &$\bullet$&$\bullet$& I/O bufferizzato in standard ANSI C.\\
- \file{stdlib.h}&$\bullet$&$\bullet$& definizioni della libreria standard.\\
+ \file{assert.h}&$\bullet$& & Verifica le asserzioni fatte in un
+ programma.\\
+ \file{ctype.h} &$\bullet$& & Tipi standard.\\
+ \file{dirent.h}& &$\bullet$& Manipolazione delle directory.\\
+ \file{errno.h} & &$\bullet$& Errori di sistema.\\
+ \file{fcntl.h} & &$\bullet$& Controllo sulle opzioni dei file.\\
+ \file{limits.h}& &$\bullet$& Limiti e parametri del sistema.\\
+ \file{malloc.h}&$\bullet$& & Allocazione della memoria.\\
+ \file{setjmp.h}&$\bullet$& & Salti non locali.\\
+ \file{signal.h}& &$\bullet$& Gestione dei segnali.\\
+ \file{stdarg.h}&$\bullet$& & .\\
+ \file{stdio.h} &$\bullet$& & I/O bufferizzato in standard ANSI C.\\
+ \file{stdlib.h}&$\bullet$& & definizioni della libreria standard.\\
+ \file{string.h}&$\bullet$& & Manipolazione delle stringhe.\\
+ \file{time.h} & &$\bullet$& Gestione dei tempi.\\
+ \file{times.h} &$\bullet$& & Gestione dei tempi.\\
+ \file{unistd.h}& &$\bullet$& Unix standard library.\\
+ \file{utmp.h} & &$\bullet$& Registro connessioni utenti.\\
\hline
\end{tabular}
\caption{Elenco dei vari header file definiti dallo standard POSIX.}
\textit{CGI}\footnote{Un CGI (\textit{Common Gateway Interface}) è un
programma che permette la creazione dinamica di un oggetto da inserire
all'interno di una pagina HTML.} per Apache, che genera una immagine JPEG
-di un codice a barre, specificato come parametro di input.
+di un codice a barre, specificato come argomento in ingresso.
Un programma che deve essere eseguito come \textit{CGI} deve rispondere a
delle caratteristiche specifiche, esso infatti non viene lanciato da una
shell, ma dallo stesso web server, alla richiesta di una specifica URL, che di
solito ha la forma:
\begin{verbatim}
- http://www.sito.it/cgi-bin/programma?parametro
+ http://www.sito.it/cgi-bin/programma?argomento
\end{verbatim}
ed il risultato dell'elaborazione deve essere presentato (con una intestazione
che ne descrive il mime-type) sullo standard output, in modo che il web-server
La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di
loro: quello che si scrive su uno di essi sarà ripresentato in input
-sull'altro e viceversa. I parametri \param{domain}, \param{type} e
-\param{protocol} derivano dall'interfaccia dei socket\index{socket} (che è
-quella che fornisce il substrato per connettere i due descrittori), ma in
-questo caso i soli valori validi che possono essere specificati sono
-rispettivamente \const{AF\_UNIX}, \const{SOCK\_STREAM} e \val{0}.
+sull'altro e viceversa. Gli argomenti \param{domain}, \param{type} e
+\param{protocol} derivano dall'interfaccia dei socket\index{socket} (vedi
+sez.~\ref{sec:sock_creation}) che è quella che fornisce il substrato per
+connettere i due descrittori, ma in questo caso i soli valori validi che
+possono essere specificati sono rispettivamente \const{AF\_UNIX},
+\const{SOCK\_STREAM} e \val{0}.
L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei
Usando la stessa chiave due processi diversi possono ricavare l'identificatore
associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
-sono \textsl{parenti} la soluzione è relativamente semplice, in tal caso
+sono \textsl{imparentati} la soluzione è relativamente semplice, in tal caso
infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
-disponibile in tutti i figli, e potrà essere passato come parametro attraverso
+disponibile in tutti i figli, e potrà essere passato come argomento attraverso
una \func{exec}.
-Però quando i processi non sono \textsl{parenti} (come capita tutte le volte
-che si ha a che fare con un sistema client-server) tutto questo non è
+Però quando i processi non sono \textsl{imparentati} (come capita tutte le
+volte che si ha a che fare con un sistema client-server) tutto questo non è
possibile; si potrebbe comunque salvare l'identificatore su un file noto, ma
questo ovviamente comporta lo svantaggio di doverselo andare a rileggere. Una
alternativa più efficace è quella che i programmi usino un valore comune per
}
\end{functions}
-La funzione può avere tre o quattro parametri, a seconda dell'operazione
+La funzione può avere tre o quattro argomenti, a seconda dell'operazione
specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
\param{semid} o sul singolo semaforo di un insieme, specificato da
\param{semnum}.
fig.~\ref{fig:ipc_semun}.
Come già accennato sia il comportamento della funzione che il numero di
-parametri con cui deve essere invocata, dipendono dal valore dell'argomento
+argomenti con cui deve essere invocata dipendono dal valore dell'argomento
\param{cmd}, che specifica l'azione da intraprendere; i valori validi (che
cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i
seguenti:
riga di comando (che si limitano alla eventuale stampa di un messaggio di
aiuto a video ed all'impostazione della durata dell'intervallo con cui viene
ripetuto il calcolo delle proprietà della directory) controlla (\texttt{\small
- 20--23}) che sia stato specificato il parametro necessario contenente il
-nome della directory da tenere sotto controllo, senza il quale esce
-immediatamente con un messaggio di errore.
+ 20--23}) che sia stato specificato l'argoemnto necessario contenente il nome
+della directory da tenere sotto controllo, senza il quale esce immediatamente
+con un messaggio di errore.
-Poi, per verificare che il parametro specifichi effettivamente una directory,
+Poi, per verificare che l'argomento specifichi effettivamente una directory,
si esegue (\texttt{\small 24--26}) su di esso una \func{chdir}, uscendo
immediatamente in caso di errore. Questa funzione serve anche per impostare
la directory di lavoro del programma nella directory da tenere sotto
struttura degli indirizzi; prima (\texttt{\small 14}) si cancella
completamente la stessa con \func{memset}, (\texttt{\small 15}) poi si imposta
la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine
-(\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare dal
-parametro passato a riga di comando, convertendolo con \func{inet\_pton}. Si
-noti come questa sezione sia identica a quella del client TCP di
+(\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare
+dall'argomento passato a riga di comando, convertendolo con \func{inet\_pton}.
+Si noti come questa sezione sia identica a quella del client TCP di
fig.~\ref{fig:TCP_daytime_client_code}, in quanto la determinazione dell'uso
di UDP al posto di TCP è stata effettuata quando si è creato il socket.
Ed in questo caso rispetto alla precedente versione, il solo cambiamento è
l'utilizzo (\texttt{\small 17}) della funzione \func{connect} prima della
chiamata alla funzione di gestione del protocollo, che a sua volta è stata
-modificata eliminando l'indirizzo passato come parametro e sostituendo le
+modificata eliminando l'indirizzo passato come argomento e sostituendo le
chiamata a \func{sendto} e \func{recvfrom} con chiamate a \func{read} e
\func{write} come illustrato dal nuovo codice riportato in
fig.~\ref{fig:UDP_echo_conn_echo_client}.
automaticamente un avviso (un carattere di BELL, che provoca un beep)
sull'output quando si eccedono le dimensioni della coda. Se è abilitato il
modo canonico i caratteri in ingresso restano nella coda fintanto che non
-viene ricevuto un a capo; un'altra parametro del sistema, \const{MAX\_CANON},
+viene ricevuto un a capo; un'altro parametro del sistema, \const{MAX\_CANON},
specifica la dimensione massima di una riga in modo canonico.
La coda di uscita è analoga a quella di ingresso e contiene i caratteri
\label{sec:sig_signal}
L'interfaccia più semplice per la gestione dei segnali è costituita dalla
-funzione \funcd{signal} che è definita fin dallo standard ANSI C. Quest'ultimo
-però non considera sistemi multitasking, per cui la definizione è tanto vaga
-da essere del tutto inutile in un sistema Unix; è questo il motivo per cui
-ogni implementazione successiva ne ha modificato e ridefinito il
+funzione \funcd{signal} che è definita fin dallo standard ANSI C.
+Quest'ultimo però non considera sistemi multitasking, per cui la definizione è
+tanto vaga da essere del tutto inutile in un sistema Unix; è questo il motivo
+per cui ogni implementazione successiva ne ha modificato e ridefinito il
comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in
alcune vecchie implementazioni (SVr4 e 4.3+BSD in particolare) vengono usati
- alcuni parametri aggiuntivi per definire il comportamento della funzione,
+ alcuni argomenti aggiuntivi per definire il comportamento della funzione,
vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la
funzione \func{sigaction}.} che è:
\begin{prototype}{signal.h}
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore e restituisce gli stessi errori di \func{getitimer}}
\end{prototype}
-\noindent i cui parametri hanno lo stesso significato e formato di quelli di
+\noindent i cui argomenti hanno lo stesso significato e formato di quelli di
\func{setitimer}.
Lo standard richiede che la funzione sia implementata in maniera del tutto
indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
-interferenze con l'uso di \const{SIGALRM}. La funzione prende come parametri
+interferenze con l'uso di \const{SIGALRM}. La funzione prende come argomenti
delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
fig.~\ref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
una precisione (teorica) fino al nanosecondo.
\label{tab:sig_sa_flag}
\end{table}
-Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction}
-permette\footnote{La possibilità è prevista dallo standard POSIX.1b, ed è
- stata aggiunta nei kernel della serie 2.1.x con l'introduzione dei segnali
- real-time (vedi sez.~\ref{sec:sig_real_time}). In precedenza era possibile
- ottenere alcune informazioni addizionali usando \var{sa\_handler} con un
- secondo parametro addizionale di tipo \var{sigcontext}, che adesso è
- deprecato.} di utilizzare due forme diverse di gestore, da specificare, a
-seconda dell'uso o meno del flag \const{SA\_SIGINFO}, rispettivamente
-attraverso i campi \var{sa\_sigaction} o \var{sa\_handler},\footnote{i due
- tipi devono essere usati in maniera alternativa, in certe implementazioni
- questi campi vengono addirittura definiti come \ctyp{union}.} Quest'ultima
-è quella classica usata anche con \func{signal}, mentre la prima permette di
-usare un gestore più complesso, in grado di ricevere informazioni più
-dettagliate dal sistema, attraverso la struttura \struct{siginfo\_t},
-riportata in fig.~\ref{fig:sig_siginfo_t}.
+Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
+di utilizzare due forme diverse di gestore,\footnote{La possibilità è prevista
+ dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x
+ con l'introduzione dei segnali real-time (vedi
+ sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune
+ informazioni addizionali usando \var{sa\_handler} con un secondo parametro
+ addizionale di tipo \var{sigcontext}, che adesso è deprecato.} da
+specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
+rispettivamente attraverso i campi \var{sa\_sigaction} o
+\var{sa\_handler},\footnote{i due tipi devono essere usati in maniera
+ alternativa, in certe implementazioni questi campi vengono addirittura
+ definiti come \ctyp{union}.} Quest'ultima è quella classica usata anche con
+\func{signal}, mentre la prima permette di usare un gestore più complesso, in
+grado di ricevere informazioni più dettagliate dal sistema, attraverso la
+struttura \struct{siginfo\_t}, riportata in fig.~\ref{fig:sig_siginfo_t}.
\begin{figure}[!htb]
\footnotesize \centering
(vale a dire che c'è posto\footnote{la profondità della coda è indicata dalla
costante \const{SIGQUEUE\_MAX}, una della tante costanti di sistema definite
dallo standard POSIX che non abbiamo riportato esplicitamente in
- sez.~\ref{sec:sys_limits}. Il suo valore minimo secondo lo standard,
+ sez.~\ref{sec:sys_limits}; il suo valore minimo secondo lo standard,
\const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux questo è uno
dei parametri del kernel impostabili sia con \func{sysctl}, che scrivendolo
direttamente in \file{/proc/sys/kernel/rtsig-max}, il valore predefinito è
In generale ogni limite o caratteristica del sistema per cui è definita una
macro, sia dagli standard ANSI C e ISO C90, che da POSIX.1 e POSIX.2, può
essere ottenuto attraverso una chiamata a \func{sysconf}. Il valore si otterrà
-specificando come valore del parametro \param{name} il nome ottenuto
+specificando come valore dell'argomento \param{name} il nome ottenuto
aggiungendo \code{\_SC\_} ai nomi delle macro definite dai primi due, o
sostituendolo a \code{\_POSIX\_} per le macro definite dagli gli altri due.
degli errori possibili relativi all'accesso a \param{path}).}
\end{prototype}
-E si noti come la funzione in questo caso richieda un parametro che specifichi
+E si noti come la funzione in questo caso richieda un argomento che specifichi
a quale file si fa riferimento, dato che il valore del limite cercato può
variare a seconda del filesystem. Una seconda versione della funzione,
\funcd{fpathconf}, opera su un file descriptor invece che su un
quindi anche per quelle che tratteremo in seguito) può essere utilizzata solo
da un processo coi privilegi di amministratore.
-Il secondo parametro di entrambe le funzioni è una struttura
+Il secondo argomento di entrambe le funzioni è una struttura
\struct{timezone}, che storicamente veniva utilizzata per specificare appunto
la \textit{time zone}, cioè l'insieme del fuso orario e delle convenzioni per
l'ora legale che permettevano il passaggio dal tempo universale all'ora
-locale. Questo parametro oggi è obsoleto ed in Linux non è mai stato
+locale. Questo argomento oggi è obsoleto ed in Linux non è mai stato
utilizzato; esso non è supportato né dalle vecchie \textsl{libc5}, né dalle
\textsl{glibc}: pertanto quando si chiama questa funzione deve essere sempre
impostato a \val{NULL}.
sistema in modo che esso sia sempre crescente in maniera monotona. Il valore
di \param{delta} esprime il valore di cui si vuole spostare l'orologio; se è
positivo l'orologio sarà accelerato per un certo tempo in modo da guadagnare
-il tempo richiesto, altrimenti sarà rallentato. Il secondo parametro viene
+il tempo richiesto, altrimenti sarà rallentato. Il secondo argomento viene
usato, se non nullo, per ricevere il valore dell'ultimo aggiustamento
effettuato.
\func{asctime} come \code{asctime(localtime(t)}. Dato che l'uso di una stringa
statica rende le funzioni non rientranti POSIX.1c e SUSv2 prevedono due
sostitute rientranti, il cui nome è al solito ottenuto appendendo un
-\code{\_r}, che prendono un secondo parametro \code{char *buf}, in cui
+\code{\_r}, che prendono un secondo argomento \code{char *buf}, in cui
l'utente deve specificare il buffer su cui la stringa deve essere copiata
(deve essere di almeno 26 caratteri).
Anche in questo caso le prime due funzioni restituiscono l'indirizzo di una
struttura allocata staticamente, per questo sono state definite anche altre
due versioni rientranti (con la solita estensione \code{\_r}), che prevedono
-un secondo parametro \code{struct tm *result}, fornito dal chiamante, che deve
+un secondo argomento \code{struct tm *result}, fornito dal chiamante, che deve
preallocare la struttura su cui sarà restituita la conversione.
Come mostrato in fig.~\ref{fig:sys_tm_struct} il \textit{broken-down time}
che dice che l'errore è sconosciuto, e \var{errno} verrà modificata assumendo
il valore \errval{EINVAL}.
-In generale \func{strerror} viene usata passando \var{errno} come parametro,
+In generale \func{strerror} viene usata passando \var{errno} come argomento,
ed il valore di quest'ultima non verrà modificato. La funzione inoltre tiene
conto del valore della variabile di ambiente \val{LC\_MESSAGES} per usare le
appropriate traduzioni dei messaggi d'errore nella localizzazione presente.
completo del programma è allegato nel file \file{ErrCode.c} e contiene pure la
gestione delle opzioni e tutte le definizioni necessarie ad associare il
valore numerico alla costante simbolica. In particolare si è riportata la
-sezione che converte la stringa passata come parametro in un intero
+sezione che converte la stringa passata come argomento in un intero
(\texttt{\small 1--2}), controllando con i valori di ritorno di \func{strtol}
che la conversione sia avvenuta correttamente (\texttt{\small 4--10}), e poi
stampa, a seconda dell'opzione scelta il messaggio di errore (\texttt{\small
La funzione fa parte delle estensioni GNU per la gestione degli errori,
l'argomento \param{format} prende la stessa sintassi di \func{printf}, ed i
-relativi parametri devono essere forniti allo stesso modo, mentre
+relativi argomenti devono essere forniti allo stesso modo, mentre
\param{errnum} indica l'errore che si vuole segnalare (non viene quindi usato
il valore corrente di \var{errno}); la funzione stampa sullo standard error il
nome del programma, come indicato dalla variabile globale \var{program\_name},
\label{fig:TCP_listen_backlog}
\end{figure}
-Storicamente il valore del parametro \param{backlog} era corrispondente al
+Storicamente il valore dell'argomento \param{backlog} era corrispondente al
massimo valore della somma del numero di voci possibili per ciascuna delle due
code. Stevens in \cite{UNP1} riporta che BSD ha sempre applicato un fattore di
1.5 a detto valore, e fornisce una tabella con i risultati ottenuti con vari
per determinare l'indirizzo remoto del client.
Infine è da chiarire (si legga la pagina di manuale) che, come per
-\func{accept}, il terzo parametro, che è specificato dallo standard POSIX.1g
+\func{accept}, il terzo argomento, che è specificato dallo standard POSIX.1g
come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
\ctyp{int *} come prima dello standard perché tutte le implementazioni dei
socket BSD fanno questa assunzione.
Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``in
ascolto'' il socket; questo viene fatto (\texttt{\small 36}) con la funzione
\func{listen} che dice al kernel di accettare connessioni per il socket che
-abbiamo creato; la funzione indica inoltre, con il secondo parametro, il
+abbiamo creato; la funzione indica inoltre, con il secondo argomento, il
numero massimo di connessioni che il kernel accetterà di mettere in coda per
il suddetto socket. Di nuovo in caso di errore si stampa (\texttt{\small 37})
un messaggio, e si esce (\texttt{\small 38}) immediatamente.
definitiva della connessione anche nel client, dove non comparirà più
nell'output di \cmd{netstat}.
-Come abbiamo accennato in sez.~\ref{sec:TCP_conn_term} e come vedremo più avanti
-in sez.~\ref{sec:TCP_shutdown} la chiusura di un solo capo di un socket è
-una operazione lecita, per cui la nostra scrittura avrà comunque successo
+Come abbiamo accennato in sez.~\ref{sec:TCP_conn_term} e come vedremo più
+avanti in sez.~\ref{sec:TCP_shutdown} la chiusura di un solo capo di un socket
+è una operazione lecita, per cui la nostra scrittura avrà comunque successo
(come si può constatare lanciando usando \cmd{strace}\footnote{il comando
- \cmd{strace} è un comando di debug molto utile che prende come parametro un
+ \cmd{strace} è un comando di debug molto utile che prende come argomento un
altro comando e ne stampa a video tutte le invocazioni di una system call,
- coi relativi parametri e valori di ritorno, per cui usandolo in questo
+ coi relativi argomenti e valori di ritorno, per cui usandolo in questo
contesto potremo verificare che effettivamente la \func{write} ha scritto la
riga, che in effetti è stata pure trasmessa via rete.}), in quanto il nostro
programma non ha a questo punto alcun modo di sapere che dall'altra parte non
projects / gapil.git / commitdiff