Transizione \macro{} -> \const{}, \errcode{}, \val{}
[gapil.git] / process.tex
index e5e4b50ab66464dd828c8eead3a339c6d7a263ee..a90c4ed44afeb67b00ef9a8b5f6403f60bc30e30 100644 (file)
@@ -1,3 +1,13 @@
+%% process.tex
+%%
+%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% copy, distribute and/or modify this document under the terms of the GNU Free
+%% Documentation License, Version 1.1 or any later version published by the
+%% Free Software Foundation; with the Invariant Sections being "Prefazione",
+%% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
+%% license is included in the section entitled "GNU Free Documentation
+%% License".
+%%
 \chapter{L'interfaccia base con i processi}
 \label{cha:process_interface}
 
 \chapter{L'interfaccia base con i processi}
 \label{cha:process_interface}
 
@@ -222,7 +232,7 @@ volontariamente la sua esecuzione 
 \func{exit} o il ritorno di \func{main}.
 
 Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
 \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 \nfig.
+normalmente un programma è riportato in \figref{fig:proc_prog_start_stop}.
 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering
@@ -233,7 +243,8 @@ normalmente un programma 
 
 Si ricordi infine che un programma può anche essere interrotto dall'esterno
 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
 
 Si ricordi infine che un programma può anche essere interrotto dall'esterno
 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
-\curfig); torneremo su questo aspetto in \capref{cha:signals}.
+\figref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
+\capref{cha:signals}.
 
 
 
 
 
 
@@ -364,7 +375,7 @@ seguenti segmenti:
   \end{lstlisting}
   questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
   allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed i
   \end{lstlisting}
   questo vettore sarà immagazzinato in questo segmento. Anch'esso viene
   allocato all'avvio, e tutte le variabili vengono inizializzate a zero (ed i
-  puntatori a \macro{NULL}).\footnote{si ricordi che questo vale solo per le
+  puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
     variabili che vanno nel segmento dati, e non è affatto vero in generale.}
    
   Storicamente questo segmento viene chiamato BBS (da \textit{block started by
     variabili che vanno nel segmento dati, e non è affatto vero in generale.}
    
   Storicamente questo segmento viene chiamato BBS (da \textit{block started by
@@ -455,20 +466,20 @@ prototipi sono i seguenti:
   Alloca \var{size} byte nello heap. La memoria viene inizializzata a 0.
   
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
   Alloca \var{size} byte nello heap. La memoria viene inizializzata a 0.
   
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
-  di successo e \macro{NULL} in caso di fallimento, nel qual caso
+  di successo e \val{NULL} in caso di fallimento, nel qual caso
   \var{errno} assumerà il valore \macro{ENOMEM}.
 \funcdecl{void *malloc(size\_t size)}
   Alloca \var{size} byte nello heap. La memoria non viene inizializzata.
 
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
   \var{errno} assumerà il valore \macro{ENOMEM}.
 \funcdecl{void *malloc(size\_t size)}
   Alloca \var{size} byte nello heap. La memoria non viene inizializzata.
 
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
-  di successo e \macro{NULL} in caso di fallimento, nel qual caso
+  di successo e \val{NULL} in caso di fallimento, nel qual caso
   \var{errno} assumerà il valore \macro{ENOMEM}.
 \funcdecl{void *realloc(void *ptr, size\_t size)}
   Cambia la dimensione del blocco allocato all'indirizzo \var{ptr}
   portandola a \var{size}.
 
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
   \var{errno} assumerà il valore \macro{ENOMEM}.
 \funcdecl{void *realloc(void *ptr, size\_t size)}
   Cambia la dimensione del blocco allocato all'indirizzo \var{ptr}
   portandola a \var{size}.
 
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
-  di successo e \macro{NULL} in caso di fallimento, nel qual caso
+  di successo e \val{NULL} in caso di fallimento, nel qual caso
   \var{errno} assumerà il valore \macro{ENOMEM}.
 \funcdecl{void free(void *ptr)}
   Disalloca lo spazio di memoria puntato da \var{ptr}.
   \var{errno} assumerà il valore \macro{ENOMEM}.
 \funcdecl{void free(void *ptr)}
   Disalloca lo spazio di memoria puntato da \var{ptr}.
@@ -480,11 +491,16 @@ allineato correttamente per tutti i tipi di dati; ad esempio sulle macchine a
 32 bit in genere è allineato a multipli di 4 byte e sulle macchine a 64 bit a
 multipli di 8 byte.
 
 32 bit in genere è allineato a multipli di 4 byte e sulle macchine a 64 bit a
 multipli di 8 byte.
 
-In genere su usano le funzioni \func{malloc} e \func{calloc} per allocare
-dinamicamente la memoria necessaria al programma, e siccome i puntatori
-ritornati sono di tipo generico non è necessario effettuare un cast per
-assegnarli a puntatori al tipo di variabile per la quale si effettua
-l'allocazione.
+In genere si usano le funzioni \func{malloc} e \func{calloc} per allocare
+dinamicamente la quantità di memoria necessaria al programma indicata da
+\param{size},\footnote{queste funzioni presentano un comportamento diverso fra
+  le \acr{glibc} e le \acr{uClib} quando il valore di \param{size} è nullo.
+  Nel primo caso viene comunque restituito un puntatore valido, anche se non è
+  chiaro a cosa esso possa fare riferimento, nel secondo caso viene restituito
+  \val{NULL}. Il comportamento è analogo con \code{realloc(NULL, 0)}.} e
+siccome i puntatori ritornati sono di tipo generico non è necessario
+effettuare un cast per assegnarli a puntatori al tipo di variabile per la
+quale si effettua l'allocazione.
 
 La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando
 \func{free}\footnote{le glibc provvedono anche una funzione \func{cfree}
 
 La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando
 \func{free}\footnote{le glibc provvedono anche una funzione \func{cfree}
@@ -497,7 +513,7 @@ in caso contrario il comportamento della funzione 
 La funzione \func{realloc} si usa invece per cambiare (in genere aumentare) la
 dimensione di un'area di memoria precedentemente allocata, la funzione vuole
 in ingresso il puntatore restituito dalla precedente chiamata ad una
 La funzione \func{realloc} si usa invece per cambiare (in genere aumentare) la
 dimensione di un'area di memoria precedentemente allocata, la funzione vuole
 in ingresso il puntatore restituito dalla precedente chiamata ad una
-\func{malloc} (se è passato un valore \macro{NULL} allora la funzione si
+\func{malloc} (se è passato un valore \val{NULL} allora la funzione si
 comporta come \func{malloc})\footnote{questo è vero per Linux e
   l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
   vecchie implementazioni, inoltre alcune versioni delle librerie del C
 comporta come \func{malloc})\footnote{questo è vero per Linux e
   l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
   vecchie implementazioni, inoltre alcune versioni delle librerie del C
@@ -520,7 +536,7 @@ blocco di dati ridimensionato.
 Un errore abbastanza frequente (specie se si ha a che fare con array di
 puntatori) è quello di chiamare \func{free} più di una volta sullo stesso
 puntatore; per evitare questo problema una soluzione di ripiego è quella di
 Un errore abbastanza frequente (specie se si ha a che fare con array di
 puntatori) è quello di chiamare \func{free} più di una volta sullo stesso
 puntatore; per evitare questo problema una soluzione di ripiego è quella di
-assegnare sempre a \macro{NULL} ogni puntatore liberato con \func{free}, dato
+assegnare sempre a \val{NULL} ogni puntatore liberato con \func{free}, dato
 che, quando il parametro è un puntatore nullo, \func{free} non esegue nessuna
 operazione.
 
 che, quando il parametro è un puntatore nullo, \func{free} non esegue nessuna
 operazione.
 
@@ -531,18 +547,18 @@ variabile \macro{MALLOC\_CHECK\_} che quando viene definita mette in uso una
 versione meno efficiente delle funzioni suddette, che però è più tollerante
 nei confronti di piccoli errori come quello di chiamate doppie a \func{free}.
 In particolare:
 versione meno efficiente delle funzioni suddette, che però è più tollerante
 nei confronti di piccoli errori come quello di chiamate doppie a \func{free}.
 In particolare:
-\begin{itemize*}
+\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}).
 \item se è posta a 2 viene chiamata \func{abort}, che in genere causa
   l'immediata conclusione del programma.
 \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}).
 \item se è posta a 2 viene chiamata \func{abort}, che in genere causa
   l'immediata conclusione del programma.
-\end{itemize*}
+\end{itemize}
 
 Il problema più comune e più difficile da risolvere che si incontra con le
 routine di allocazione è quando non viene opportunamente liberata la memoria
 non più utilizzata, quello che in inglese viene chiamato \textit{memory-leak},
 
 Il problema più comune e più difficile da risolvere che si incontra con le
 routine di allocazione è quando non viene opportunamente liberata la memoria
 non più utilizzata, quello che in inglese viene chiamato \textit{memory-leak},
-cioè \textsl{perdita di memoria}.
+cioè una \textsl{perdita di memoria}.
 
 Un caso tipico che illustra il problema è quello in cui in una subroutine si
 alloca della memoria per uso locale senza liberarla prima di uscire. La
 
 Un caso tipico che illustra il problema è quello in cui in una subroutine si
 alloca della memoria per uso locale senza liberarla prima di uscire. La
@@ -557,28 +573,60 @@ essere in una sezione del codice che non ha alcuna relazione con la subroutine
 che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
 \textit{memory leak}.
 
 che contiene l'errore. Per questo motivo è sempre molto difficile trovare un
 \textit{memory leak}.
 
-Per ovviare a questi problemi l'implementazione delle routine di allocazione
-delle \acr{glibc} mette a disposizione una serie di funzionalità che
-permettono di tracciare le allocazioni e le disallocazione, e definisce anche
-una serie di possibili \textit{hook} (\textsl{ganci}) che permettono di
-sostituire alle funzioni di libreria una propria versione (che può essere più
-o meno specializzata per il debugging).
+In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
+programmazione ad oggetti, il problema dei \textit{memory leak} è notevolmente
+ridimensionato attraverso l'uso accurato di appositi oggetti come gli
+\textit{smartpointers}.  Questo però va a scapito delle performance
+dell'applicazione in esecuzione.
+
+In altri linguaggi come il java e recentemente il C\# il problema non si pone
+nemmeno perché la gestione della memoria viene fatta totalmente in maniera
+automatica, ovvero il programmatore non deve minimamente preoccuparsi di
+liberare la memoria allocata precedentemente quando non serve più, poiché il
+framework gestisce automaticamente la cosiddetta \textit{garbage collection}.
+In tal caso, attraverso meccanismi simili a quelli del \textit{reference
+  counting}, quando una zona di memoria precedentemente allocata non è più
+riferita da nessuna parte del codice in esecuzione, può essere deallocata
+automaticamente in qualunque momento dall'infrastruttura.
+
+Anche questo va a scapito delle performance dell'applicazione in esecuzione
+(inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
+eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
+la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
+di per sé delle performance più scadenti rispetto alle stesse applicazioni
+compilate direttamente).  Questo comporta però il problema della non
+predicibilità del momento in cui viene deallocata la memoria precedentemente
+allocata da un oggetto.
+
+Per limitare l'impatto di questi problemi, e semplificare la ricerca di
+eventuali errori, l'implementazione delle routine di allocazione delle
+\acr{glibc} mette a disposizione una serie di funzionalità che permettono di
+tracciare le allocazioni e le disallocazione, e definisce anche una serie di
+possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle
+funzioni di libreria una propria versione (che può essere più o meno
+specializzata per il debugging). Esistono varie librerie che forniscono dei
+sostituti opportuni delle routine di allocazione in grado, senza neanche
+ricompilare il programma,\footnote{esempi sono \textit{Dmalloc}
+  \href{http://dmalloc.com/}{http://dmalloc.com/} di Gray Watson ed
+  \textit{Electric Fence} di Bruce Perens.} di eseguire diagnostiche anche
+molto complesse riguardo l'allocazione della memoria.
+
 
 
 \subsection{La funzione \func{alloca}}  
 \label{sec:proc_mem_alloca}
 
 Una possibile alternativa all'uso di \func{malloc}, che non soffre dei
 
 
 \subsection{La funzione \func{alloca}}  
 \label{sec:proc_mem_alloca}
 
 Una possibile alternativa all'uso di \func{malloc}, che non soffre dei
-problemi di memory leak descritti in precedenza, è la funzione \func{alloca},
-che invece di allocare la memoria nello heap usa il segmento di stack della
-funzione corrente. La sintassi è identica a quella di \func{malloc}, il suo
-prototipo è:
+problemi di \textit{memory leak} descritti in precedenza, è la funzione
+\func{alloca}, che invece di allocare la memoria nello heap usa il segmento di
+stack della funzione corrente. La sintassi è identica a quella di
+\func{malloc}, il suo prototipo è:
 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
   Alloca \var{size} byte nel segmento di stack della funzione chiamante.
   La memoria non viene inizializzata.
 
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
   Alloca \var{size} byte nel segmento di stack della funzione chiamante.
   La memoria non viene inizializzata.
 
   La funzione restituisce il puntatore alla zona di memoria allocata in caso
-  di successo e \macro{NULL} in caso di fallimento, nel qual caso
+  di successo e \val{NULL} in caso di fallimento, nel qual caso
   \var{errno} assumerà il valore \macro{ENOMEM}.
 \end{prototype}
 \noindent ma in questo caso non è più necessario liberare la memoria (e quindi
   \var{errno} assumerà il valore \macro{ENOMEM}.
 \end{prototype}
 \noindent ma in questo caso non è più necessario liberare la memoria (e quindi
@@ -638,7 +686,7 @@ analoghe system call a cui fanno da interfaccia. I loro prototipi sono:
   della fine del segmento dati.
   
   La funzione restituisce il puntatore all'inizio della nuova zona di memoria
   della fine del segmento dati.
   
   La funzione restituisce il puntatore all'inizio della nuova zona di memoria
-  allocata in caso di successo e \macro{NULL} in caso di fallimento, nel qual
+  allocata in caso di successo e \val{NULL} in caso di fallimento, nel qual
   caso \macro{errno} assumerà il valore \macro{ENOMEM}.
 \end{functions}
 \noindent in genere si usa \func{sbrk} con un valore zero per ottenere
   caso \macro{errno} assumerà il valore \macro{ENOMEM}.
 \end{functions}
 \noindent in genere si usa \func{sbrk} con un valore zero per ottenere
@@ -647,7 +695,7 @@ l'attuale posizione della fine del segmento dati.
 Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
 per i programmi normali è sempre opportuno usare le funzioni di allocazione
 standard descritte in precedenza, che sono costruite su di esse.  L'uso di
 Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
 per i programmi normali è sempre opportuno usare le funzioni di allocazione
 standard descritte in precedenza, che sono costruite su di esse.  L'uso di
-queste funzione è ristretto alle specifiche necessità di chi debba
+queste funzioni è ristretto alle specifiche necessità di chi debba
 implementare una sua versione delle routine di allocazione.  
 
 
 implementare una sua versione delle routine di allocazione.  
 
 
@@ -842,7 +890,7 @@ Nella scansione viene costruito il vettore di puntatori \var{argv} inserendo
 in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
 variabile \var{argc} viene inizializzata al numero di parametri trovati, in
 questo modo il primo parametro è sempre il nome del programma; un esempio di
 in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
 variabile \var{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 \curfig.
+questo meccanismo è mostrato in \figref{fig:proc_argv_argc}.
 
 
 \subsection{La gestione delle opzioni}
 
 
 \subsection{La gestione delle opzioni}
@@ -993,7 +1041,7 @@ nella chiamata alla funzione \func{exec} quando questo viene lanciato.
 
 Come per la lista dei parametri anche questa lista è un array di puntatori a
 caratteri, ciascuno dei quali punta ad una stringa, terminata da un
 
 Come per la lista dei parametri anche questa lista è un array di puntatori a
 caratteri, ciascuno dei quali punta ad una stringa, terminata da un
-\macro{NULL}. A differenza di \var{argv[]} in questo caso non si ha una
+\val{NULL}. A differenza di \var{argv[]} in questo caso non si ha una
 lunghezza dell'array data da un equivalente di \var{argc}, ma la lista è
 terminata da un puntatore nullo.
 
 lunghezza dell'array data da un equivalente di \var{argc}, ma la lista è
 terminata da un puntatore nullo.
 
@@ -1015,9 +1063,9 @@ pi
 
 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
 \textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate
 
 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
 \textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate
-in \curfig, 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.
+in \figref{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.
 
 Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
 
 Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
@@ -1027,18 +1075,21 @@ configurazione.
 
 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
 
 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. 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à).
+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
+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ù
 
 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
-comuni), come riportato in \ntab. GNU/Linux le supporta tutte e ne definisce
-anche altre: per una lista più completa si può controllare \cmd{man environ}.
+comuni), come riportato in \tabref{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}.
 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering
+  \footnotesize
   \begin{tabular}[c]{|l|c|c|c|p{7cm}|}
     \hline
     \textbf{Variabile} & \textbf{POSIX} & \textbf{XPG3} 
   \begin{tabular}[c]{|l|c|c|c|p{7cm}|}
     \hline
     \textbf{Variabile} & \textbf{POSIX} & \textbf{XPG3} 
@@ -1073,7 +1124,7 @@ il cui prototipo 
   Esamina l'ambiente del processo cercando una stringa che corrisponda a
   quella specificata da \param{name}. 
   
   Esamina l'ambiente del processo cercando una stringa che corrisponda a
   quella specificata da \param{name}. 
   
-  \bodydesc{La funzione ritorna \macro{NULL} se non trova nulla, o il
+  \bodydesc{La funzione ritorna \val{NULL} se non trova nulla, o il
     puntatore alla stringa che corrisponde (di solito nella forma
     \cmd{NOME=valore}).}
 \end{prototype}
     puntatore alla stringa che corrisponde (di solito nella forma
     \cmd{NOME=valore}).}
 \end{prototype}
@@ -1082,10 +1133,11 @@ Oltre a questa funzione di lettura, che 
 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
 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 \ntab.
+in \tabref{tab:proc_env_func}.
 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering
+  \footnotesize
   \begin{tabular}[c]{|l|c|c|c|c|c|c|}
     \hline
     \textbf{Funzione} & \textbf{ANSI C} & \textbf{POSIX.1} & \textbf{XPG3} & 
   \begin{tabular}[c]{|l|c|c|c|c|c|c|}
     \hline
     \textbf{Funzione} & \textbf{ANSI C} & \textbf{POSIX.1} & \textbf{XPG3} & 
@@ -1108,9 +1160,9 @@ in \ntab.
   \label{tab:proc_env_func}
 \end{table}
 
   \label{tab:proc_env_func}
 \end{table}
 
-In Linux solo le prime quattro funzioni di \curtab\ sono definite,
-\func{getenv} l'abbiamo già esaminata; delle tre restanti le prime due,
-\func{putenv} e \func{setenv}, servono per assegnare nuove variabili di
+In Linux solo le prime quattro funzioni di \tabref{tab:proc_env_func} sono
+definite, \func{getenv} l'abbiamo già esaminata; delle tre restanti le prime
+due, \func{putenv} e \func{setenv}, servono per assegnare nuove variabili di
 ambiente, i loro prototipi sono i seguenti:
 \begin{functions}
   \headdecl{stdlib.h} 
 ambiente, i loro prototipi sono i seguenti:
 \begin{functions}
   \headdecl{stdlib.h} 
@@ -1378,7 +1430,7 @@ per \func{printf}).
 Una modalità diversa, che può essere applicata solo quando il tipo dei
 parametri lo rende possibile, è quella che prevede di usare un valore speciale
 come ultimo argomento (come fa ad esempio \func{execl} che usa un puntatore
 Una modalità diversa, che può essere applicata solo quando il tipo dei
 parametri lo rende possibile, è quella che prevede di usare un valore speciale
 come ultimo argomento (come fa ad esempio \func{execl} che usa un puntatore
-\macro{NULL} per indicare la fine della lista degli argomenti).
+\val{NULL} per indicare la fine della lista degli argomenti).
 
 
 \subsection{Potenziali problemi con le variabili automatiche}
 
 
 \subsection{Potenziali problemi con le variabili automatiche}