Reindicizzate alcune macro, messa sezione sulle opzioni di IP, risistemata

[gapil.git] / intro.tex

diff --git a/intro.tex b/intro.tex
index 34ad4e34b673a2f0df5643b496b8981dd869a6e9..8cd72a891b94e6cc2e10b16adf4157d6e5da1ad9 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -1,9 +1,9 @@
 %% intro.tex
 %%
 %% intro.tex
 %%

-%% Copyright (C) 2000-2004 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2005 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
 %% 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",
+%% Free Software Foundation; with the Invariant Sections being "Un preambolo",

 %% 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".
 %% 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".


@@ -37,7 +37,7 @@ Il concetto base di un sistema unix-like 
 cosiddetto \textit{kernel}, nel nostro caso Linux) a cui si demanda la
 gestione delle risorse essenziali (la CPU, la memoria, le periferiche) mentre
 tutto il resto, quindi anche la parte che prevede l'interazione con l'utente,
 cosiddetto \textit{kernel}, nel nostro caso Linux) a cui si demanda la
 gestione delle risorse essenziali (la CPU, la memoria, le periferiche) mentre
 tutto il resto, quindi anche la parte che prevede l'interazione con l'utente,

-deve venire realizzato tramite programmi eseguiti dal kernel e che accedano
+dev'essere realizzato tramite programmi eseguiti dal kernel, che accedano

 alle risorse hardware tramite delle richieste a quest'ultimo.
 
 Fin dall'inizio uno Unix si presenta come un sistema operativo
 alle risorse hardware tramite delle richieste a quest'ultimo.
 
 Fin dall'inizio uno Unix si presenta come un sistema operativo


@@ -62,16 +62,17 @@ all'hardware, mentre i programmi normali vengono eseguiti in modalit
 (e non possono accedere direttamente alle zone di memoria riservate o alle
 porte di input/output).
 
 (e non possono accedere direttamente alle zone di memoria riservate o alle
 porte di input/output).
 

-Una parte del kernel, lo \textit{scheduler}\index{scheduler}, si occupa di
-stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle
-priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il
-cosiddetto \textit{preemptive scheduling}\index{preemptive scheduling}).
-Questo verrà comunque eseguito in modalità protetta; quando necessario il
-processo potrà accedere alle risorse hardware soltanto attraverso delle
-opportune chiamate al sistema che restituiranno il controllo al kernel.
+Una parte del kernel, lo \textit{scheduler}\index{\textit{scheduler}}, si
+occupa di stabilire, ad intervalli fissi e sulla base di un opportuno calcolo
+delle priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione
+(il cosiddetto \textit{preemptive
+  scheduling}\index{\textit{preemptive~scheduling}}).  Questo verrà comunque
+eseguito in modalità protetta; quando necessario il processo potrà accedere
+alle risorse hardware soltanto attraverso delle opportune chiamate al sistema
+che restituiranno il controllo al kernel.

 
 La memoria viene sempre gestita dal kernel attraverso il meccanismo della
 
 La memoria viene sempre gestita dal kernel attraverso il meccanismo della

-\textsl{memoria virtuale}\index{memoria virtuale}, che consente di assegnare a
+\textsl{memoria virtuale}\index{memoria~virtuale}, che consente di assegnare a

 ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi
 sez.~\ref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di
 gestione della memoria, si incaricherà di rimappare automaticamente sulla
 ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi
 sez.~\ref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di
 gestione della memoria, si incaricherà di rimappare automaticamente sulla


@@ -81,13 +82,13 @@ area di \textit{swap}) le pagine di memoria in eccedenza.
 Le periferiche infine vengono viste in genere attraverso un'interfaccia
 astratta che permette di trattarle come fossero file, secondo il concetto per
 cui \textit{everything is a file}, su cui torneremo in dettaglio in
 Le periferiche infine vengono viste in genere attraverso un'interfaccia
 astratta che permette di trattarle come fossero file, secondo il concetto per
 cui \textit{everything is a file}, su cui torneremo in dettaglio in

-cap.~\ref{cha:file_intro}, (questo non è vero per le interfacce di rete, che
+cap.~\ref{cha:file_intro}. Questo non è vero per le interfacce di rete, che

 hanno un'interfaccia diversa, ma resta valido il concetto generale che tutto
 hanno un'interfaccia diversa, ma resta valido il concetto generale che tutto

-il lavoro di accesso e gestione a basso livello è effettuato dal kernel).
+il lavoro di accesso e gestione a basso livello è effettuato dal kernel.

 
 
 
 

-\subsection{User space e kernel space}
-\label{sec:intro_user_kernel_space}
+\subsection{Il kernel e il sistema}
+\label{sec:intro_kern_and_sys}

 
 Uno dei concetti fondamentali su cui si basa l'architettura dei sistemi Unix è
 quello della distinzione fra il cosiddetto \textit{user space}, che
 
 Uno dei concetti fondamentali su cui si basa l'architettura dei sistemi Unix è
 quello della distinzione fra il cosiddetto \textit{user space}, che


@@ -109,20 +110,22 @@ all'hardware non pu
 kernel il programmatore deve usare le opportune interfacce che quest'ultimo
 fornisce allo user space. 
 
 kernel il programmatore deve usare le opportune interfacce che quest'ultimo
 fornisce allo user space. 
 

-
-\subsection{Il kernel e il sistema}
-\label{sec:intro_kern_and_sys}
-

 Per capire meglio la distinzione fra kernel space e user space si può prendere
 in esame la procedura di avvio di un sistema unix-like; all'avvio il BIOS (o
 in generale il software di avvio posto nelle EPROM) eseguirà la procedura di
 Per capire meglio la distinzione fra kernel space e user space si può prendere
 in esame la procedura di avvio di un sistema unix-like; all'avvio il BIOS (o
 in generale il software di avvio posto nelle EPROM) eseguirà la procedura di

-avvio del sistema (il cosiddetto \textit{boot}), incaricandosi di caricare il
-kernel in memoria e di farne partire l'esecuzione; quest'ultimo, dopo aver
-inizializzato le periferiche, farà partire il primo processo, \cmd{init}, che
-è quello che a sua volta farà partire tutti i processi successivi. Fra questi
-ci sarà pure quello che si occupa di dialogare con la tastiera e lo schermo
-della console, e quello che mette a disposizione dell'utente che si vuole
-collegare, un terminale e la \textit{shell} da cui inviare i comandi.
+avvio del sistema (il cosiddetto \textit{bootstrap}\footnote{il nome deriva da
+  un espressione gergale che significa ``sollevarsi da terra tirandosi per le
+  stringhe delle scarpe'', per indicare il compito, almeno apparentemente
+  impossibile, di far eseguire un programma a partire da un computer appena
+  acceso che appunto non ne contiene nessuno; non è impossibile appunto perché
+  in realtà c'è un programma iniziale, che è appunto il BIOS.}), incaricandosi
+di caricare il kernel in memoria e di farne partire l'esecuzione;
+quest'ultimo, dopo aver inizializzato le periferiche, farà partire il primo
+processo, \cmd{init}, che è quello che a sua volta farà partire tutti i
+processi successivi. Fra questi ci sarà pure quello che si occupa di dialogare
+con la tastiera e lo schermo della console, e quello che mette a disposizione
+dell'utente che si vuole collegare, un terminale e la \textit{shell} da cui
+inviare i comandi.

 
 E' da rimarcare come tutto ciò, che usualmente viene visto come parte del
 sistema, non abbia in realtà niente a che fare con il kernel, ma sia
 
 E' da rimarcare come tutto ciò, che usualmente viene visto come parte del
 sistema, non abbia in realtà niente a che fare con il kernel, ma sia


@@ -247,15 +250,19 @@ Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto
 \textit{default group}), ma può essere associato ad altri gruppi (i
 \textit{supplementary group}), questo permette di gestire i permessi di
 accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
 \textit{default group}), ma può essere associato ad altri gruppi (i
 \textit{supplementary group}), questo permette di gestire i permessi di
 accesso ai file e quindi anche alle periferiche, in maniera più flessibile,

-definendo gruppi di lavoro, di accesso a determinate risorse, etc.
+definendo gruppi di lavoro, di accesso a determinate risorse, ecc.

 
 

-L'utente e il gruppo sono identificati da due numeri (la cui corrispondenza ad
+L'utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad

 un nome espresso in caratteri è inserita nei due file \file{/etc/passwd} e
 un nome espresso in caratteri è inserita nei due file \file{/etc/passwd} e

-\file{/etc/groups}). Questi numeri sono l'\textit{user identifier}, detto in
-breve \textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il
-\textit{group identifier}, detto in breve \textsl{group-ID}, ed identificato
-dall'acronimo \acr{gid}, e sono quelli che vengono usati dal kernel per
-identificare l'utente.
+\file{/etc/groups}.\footnote{in realtà negli sistemi più moderni, come vedremo
+  in sez.~\ref{sec:sys_user_group} queste informazioni possono essere
+  mantenute, con l'uso del \textit{Name Service Switch}, su varie tipologie di
+  supporti, compresi server centralizzati come LDAP.}
+\index{\textit{Name~Service~Switch}} Questi numeri sono l'\textit{user
+  identifier}, detto in breve \textsl{user-ID}, ed indicato dall'acronimo
+\acr{uid}, e il \textit{group identifier}, detto in breve \textsl{group-ID},
+ed identificato dall'acronimo \acr{gid}, e sono quelli che vengono usati dal
+kernel per identificare l'utente.

  
 In questo modo il sistema è in grado di tenere traccia dell'utente a cui
 appartiene ciascun processo ed impedire ad altri utenti di interferire con
  
 In questo modo il sistema è in grado di tenere traccia dell'utente a cui
 appartiene ciascun processo ed impedire ad altri utenti di interferire con


@@ -315,9 +322,9 @@ di libreria da esso previste. Queste sono dichiarate in una serie di
   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
   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
 
 \begin{table}[htb]
   \footnotesize


@@ -331,18 +338,24 @@ successive.
     & ANSI C& POSIX& \\
     \hline
     \hline
     & 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.}
     \hline
   \end{tabular}
   \caption{Elenco dei vari header file definiti dallo standard POSIX.}


@@ -449,9 +462,9 @@ Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
 si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
 talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le
 denominazioni usate diventa particolarmente faticoso; una pagina dove si
 si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
 talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le
 denominazioni usate diventa particolarmente faticoso; una pagina dove si

-possono recuperare varie (e di norma piuttosto intricate) informazioni è:
+possono recuperare varie (e di norma piuttosto intricate) informazioni è

 \href{http://www.pasc.org/standing/sd11.html}
 \href{http://www.pasc.org/standing/sd11.html}

-{http://www.pasc.org/standing/sd11.html}.
+{\textsf{http://www.pasc.org/standing/sd11.html}}.

 
 \begin{table}[htb]
   \footnotesize
 
 \begin{table}[htb]
   \footnotesize


@@ -479,14 +492,14 @@ possono recuperare varie (e di norma piuttosto intricate) informazioni 
   \label{tab:intro_posix_std}
 \end{table}
 
   \label{tab:intro_posix_std}
 \end{table}
 

-Benché l'insieme degli standard POSIX siano basati sui sistemi Unix essi
+Benché l'insieme degli standard POSIX siano basati sui sistemi Unix, essi

 definiscono comunque un'interfaccia di programmazione generica e non fanno
 riferimento ad una implementazione specifica (ad esempio esiste
 un'implementazione di POSIX.1 anche sotto Windows NT).  Lo standard principale
 resta comunque POSIX.1, che continua ad evolversi; la versione più nota, cui
 gran parte delle implementazioni fanno riferimento, e che costituisce una base
 per molti altri tentativi di standardizzazione, è stata rilasciata anche come
 definiscono comunque un'interfaccia di programmazione generica e non fanno
 riferimento ad una implementazione specifica (ad esempio esiste
 un'implementazione di POSIX.1 anche sotto Windows NT).  Lo standard principale
 resta comunque POSIX.1, che continua ad evolversi; la versione più nota, cui
 gran parte delle implementazioni fanno riferimento, e che costituisce una base
 per molti altri tentativi di standardizzazione, è stata rilasciata anche come

-standard internazionale con la sigla ISO/IEC 9945-1:1996. 
+standard internazionale con la sigla ISO/IEC 9945-1:1996.

 
 Linux e le \acr{glibc} implementano tutte le funzioni definite nello standard
 POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per
 
 Linux e le \acr{glibc} implementano tutte le funzioni definite nello standard
 POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per


@@ -511,12 +524,12 @@ Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi
 Unix per giungere ad un'armonizzazione delle varie implementazioni.  Per far
 questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il
 nome di \textit{X/Open Portability Guide} (a cui di norma si fa riferimento
 Unix per giungere ad un'armonizzazione delle varie implementazioni.  Per far
 questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il
 nome di \textit{X/Open Portability Guide} (a cui di norma si fa riferimento

-con l'abbreviazione XPGn).
+con l'abbreviazione XPG$n$ con $n$ che indica la versione).

 
 

-Nel 1989 produsse una terza versione di questa guida particolarmente
-voluminosa (la \textit{X/Open Portability Guide, Issue 3}), contenente
-un'ulteriore standardizzazione dell'interfaccia di sistema di Unix, che venne
-presa come riferimento da vari produttori.
+Nel 1989 il consorzio produsse una terza versione di questa guida
+particolarmente voluminosa (la \textit{X/Open Portability Guide, Issue 3}),
+contenente un'ulteriore standardizzazione dell'interfaccia di sistema di Unix,
+che venne presa come riferimento da vari produttori.

 
 Questo standard, detto anche XPG3 dal nome della suddetta guida, è sempre
 basato sullo standard POSIX.1, ma prevede una serie di funzionalità aggiuntive
 
 Questo standard, detto anche XPG3 dal nome della suddetta guida, è sempre
 basato sullo standard POSIX.1, ma prevede una serie di funzionalità aggiuntive


@@ -565,19 +578,20 @@ Lo sviluppo di BSD inizi
 di Berkley e la AT\&T generò una delle prime e più importanti fratture del
 mondo Unix.  L'Università di Berkley proseguì nello sviluppo della base di
 codice di cui disponeva, e che presentava parecchie migliorie rispetto alle
 di Berkley e la AT\&T generò una delle prime e più importanti fratture del
 mondo Unix.  L'Università di Berkley proseguì nello sviluppo della base di
 codice di cui disponeva, e che presentava parecchie migliorie rispetto alle

-allora versioni disponibili, fino ad arrivare al rilascio di una versione
+versioni allora disponibili, fino ad arrivare al rilascio di una versione

 completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice
 della AT\&T.
 
 Benché BSD non sia uno standard formalizzato, l'implementazione di Unix
 dell'Università di Berkley, ha provveduto nel tempo una serie di estensioni e
 completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice
 della AT\&T.
 
 Benché BSD non sia uno standard formalizzato, l'implementazione di Unix
 dell'Università di Berkley, ha provveduto nel tempo una serie di estensioni e

-API di grande rilievo, come il link simbolici, la funzione \code{select}, i
+API di grande rilievo, come i link simbolici, la funzione \code{select} ed i

 socket.
 
 Queste estensioni sono state via via aggiunte al sistema nelle varie versioni
 del sistema (BSD 4.2, BSD 4.3 e BSD 4.4) come pure in alcuni derivati
 socket.
 
 Queste estensioni sono state via via aggiunte al sistema nelle varie versioni
 del sistema (BSD 4.2, BSD 4.3 e BSD 4.4) come pure in alcuni derivati

-commerciali come SunOS. Il kernel e le \acr{glibc} provvedono tutte queste
-estensioni che sono state in gran parte incorporate negli standard successivi.
+commerciali come SunOS. Il kernel Linux e le \acr{glibc} provvedono tutte
+queste estensioni che sono state in gran parte incorporate negli standard
+successivi.

 
 
 \subsection{Lo standard System V}
 
 
 \subsection{Lo standard System V}


@@ -643,14 +657,15 @@ Le macro disponibili per i vari standard sono le seguenti:
 \item[\macro{\_POSIX\_C\_SOURCE}] definendo questa macro ad un valore intero
   positivo si controlla quale livello delle funzionalità specificate da POSIX
   viene messa a disposizione; più alto è il valore maggiori sono le
 \item[\macro{\_POSIX\_C\_SOURCE}] definendo questa macro ad un valore intero
   positivo si controlla quale livello delle funzionalità specificate da POSIX
   viene messa a disposizione; più alto è il valore maggiori sono le

-  funzionalità. Se è uguale a '1' vengono attivate le funzionalità specificate
-  nella edizione del 1990 (IEEE Standard 1003.1-1990), valori maggiori o
-  uguali a '2' attivano le funzionalità POSIX.2 specificate nell'edizione del
-  1992 (IEEE Standard 1003.2-1992). Un valore maggiore o uguale a `199309L'
-  attiva le funzionalità POSIX.1b specificate nell'edizione del 1993 (IEEE
-  Standard 1003.1b-1993).  Un valore maggiore o uguale a `199506L' attiva le
-  funzionalità POSIX.1 specificate nell'edizione del 1996 (ISO/IEC 9945-1:
-  1996). Valori superiori abiliteranno ulteriori estensioni.
+  funzionalità. Se è uguale a ``\texttt{1}'' vengono attivate le funzionalità
+  specificate nella edizione del 1990 (IEEE Standard 1003.1-1990), valori
+  maggiori o uguali a ``\texttt{2}'' attivano le funzionalità POSIX.2
+  specificate nell'edizione del 1992 (IEEE Standard 1003.2-1992). Un valore
+  maggiore o uguale a ``\texttt{199309L}'' attiva le funzionalità POSIX.1b
+  specificate nell'edizione del 1993 (IEEE Standard 1003.1b-1993).  Un valore
+  maggiore o uguale a ``\texttt{199506L}'' attiva le funzionalità POSIX.1
+  specificate nell'edizione del 1996 (ISO/IEC 9945-1: 1996). Valori superiori
+  abiliteranno ulteriori estensioni.

 \item[\macro{\_BSD\_SOURCE}] definendo questa macro si attivano le
   funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard
   ISO C, POSIX.1 e POSIX.2. Alcune delle funzionalità previste da BSD sono
 \item[\macro{\_BSD\_SOURCE}] definendo questa macro si attivano le
   funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard
   ISO C, POSIX.1 e POSIX.2. Alcune delle funzionalità previste da BSD sono


@@ -670,9 +685,9 @@ Le macro disponibili per i vari standard sono le seguenti:
   sono un sovrainsieme di quelle definite in POSIX.1 e POSIX.2 ed in effetti
   sia \macro{\_POSIX\_SOURCE} che \macro{\_POSIX\_C\_SOURCE} vengono
   automaticamente definite. Sono incluse anche ulteriori funzionalità
   sono un sovrainsieme di quelle definite in POSIX.1 e POSIX.2 ed in effetti
   sia \macro{\_POSIX\_SOURCE} che \macro{\_POSIX\_C\_SOURCE} vengono
   automaticamente definite. Sono incluse anche ulteriori funzionalità

-  disponibili in BSD e SVID. Se il valore della macro è posto a 500 questo
-  include anche le nuove definizioni introdotte con la \textit{Single UNIX
-    Specification, version 2}, cioè Unix98.
+  disponibili in BSD e SVID. Se il valore della macro è posto a
+  ``\texttt{500}'' questo include anche le nuove definizioni introdotte con la
+  \textit{Single UNIX Specification, version 2}, cioè Unix98.

 \item[\macro{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si attivano le
   ulteriori funzionalità necessarie ad essere conformi al rilascio del marchio
   \textit{X/Open Unix}.
 \item[\macro{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si attivano le
   ulteriori funzionalità necessarie ad essere conformi al rilascio del marchio
   \textit{X/Open Unix}.