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
essere in grado di fare qualunque operazione; per l'utente \textit{root}
infatti i meccanismi di controllo descritti in precedenza sono
disattivati.\footnote{i controlli infatti vengono sempre eseguiti da un codice
- del tipo \code{if (uid) \{ ... \}}}
+ del tipo: ``\code{if (uid) \{ \textellipsis\ \}}''.}
\section{Gli standard}
Uno dei problemi di portabilità del codice più comune è quello dei tipi di
dati utilizzati nei programmi, che spesso variano da sistema a sistema, o
-anche da una architettura ad un altra (ad esempio passando da macchine con
+anche da una architettura ad un'altra (ad esempio passando da macchine con
processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
\textit{tipi elementari}\index{tipo!elementare} del linguaggio C (come
\ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
\textbf{Tipo} & \textbf{Contenuto} \\
\hline
\hline
- \type{caddr\_t} & core address.\\
- \type{clock\_t} & contatore del tempo di sistema.\\
+ \type{caddr\_t} & Core address.\\
+ \type{clock\_t} & Contatore del tempo di sistema.\\
\type{dev\_t} & Numero di dispositivo.\\
\type{gid\_t} & Identificatore di un gruppo.\\
\type{ino\_t} & Numero di \textit{inode}\index{inode}.\\
Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
libreria, e in seguito sono stati prodotti anche altri standard per la shell e
-i comandi di sistema (1003.2), per le estensioni realtime e per i thread
-(1003.1d e 1003.1c) e vari altri. In tab.~\ref{tab:intro_posix_std} è
+i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
+thread (1003.1d e 1003.1c) e vari altri. In tab.~\ref{tab:intro_posix_std} è
riportata una classificazione sommaria dei principali documenti prodotti, e di
come sono identificati fra IEEE ed ISO; si tenga conto inoltre che molto
spesso si usa l'estensione IEEE anche come aggiunta al nome POSIX (ad esempio
alle stesse.
Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
- Specification}, nota con la sigla SUSv2, in queste versione le interfacce
+ Specification}, nota con la sigla SUSv2, in questa versione le interfacce
specificate salgono a 1434 (e 3030 se si considerano le stazioni di lavoro
grafiche, per le quali sono inserite pure le interfacce usate da CDE che
richiede sia X11 che Motif). La conformità a questa versione permette l'uso
definendo opportune costanti prima dell'inclusione dei file degli header.
Se si vuole che i programmi seguano una stretta attinenza allo standard ANSI C
-si può usare l'opzione \cmd{-ansi} del compilatore, e non sarà riconosciuta
-nessuna funzione non riconosciuta dalle specifiche standard ISO per il C.
+si può usare l'opzione \cmd{-ansi} del compilatore, e non potrà essere
+utilizzata nessuna funzione non riconosciuta dalle specifiche standard ISO per
+il C.
Per attivare le varie opzioni è possibile definire le macro di preprocessore,
che controllano le funzionalità che le \acr{glibc} possono mettere a