%% intro.tex
%%
-%% Copyright (C) 2000-2002 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
-%% 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".
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
(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
+Una parte del kernel, lo \textit{scheduler}\itindex{scheduler}, si occupa di
stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle
-priorità, quale ``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.
+priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il
+cosiddetto \textit{prehemptive
+ multitasking}\itindex{prehemptive~multitasking}). 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
-\textsl{memoria virtuale}\index{memoria virtuale}, che consente di assegnare a
-ciascun processo uno spazio di indirizzi ``virtuale'' (vedi
-\secref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di
+\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
memoria disponibile, salvando su disco quando necessario (nella cosiddetta
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
-\capref{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
-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
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
-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
chiamate, che sono riportate nella seconda sezione del \textsl{Manuale di
programmazione di Unix} (quella cui si accede con il comando \cmd{man 2
<nome>}) e Linux non fa eccezione. Queste sono poi state codificate da vari
-standard, che esamineremo brevemente in \secref{sec:intro_standard}. Uno
+standard, che esamineremo brevemente in sez.~\ref{sec:intro_standard}. Uno
schema elementare della struttura del sistema è riportato in
-\figref{fig:intro_sys_struct}.
+fig.~\ref{fig:intro_sys_struct}.
\begin{figure}[htb]
\centering
dal progetto GNU. Le \textit{libc5} oggi sono, tranne casi particolari,
completamente soppiantate dalle \acr{glibc}, le \textit{uClib} pur non
essendo complete come le \acr{glibc}, restano invece molto diffuse nel mondo
- embedded per le loro di dimensioni ridotte (e soprattutto la possibilità di
- togliere le parti non necessearie), e pertanto costituiscono un valido
+ embedded per le loro dimensioni ridotte (e soprattutto la possibilità di
+ togliere le parti non necessarie), e pertanto costituiscono un valido
rimpiazzo delle \acr{glibc} in tutti quei sistemi specializzati che
richiedono una minima occupazione di memoria.} si dovrebbe usare il nome
GNU/Linux (piuttosto che soltanto Linux) in quanto una parte essenziale del
Ogni utente è identificato da un nome (l'\textit{username}), che è quello che
viene richiesto all'ingresso nel sistema dalla procedura di \textit{login}
-(descritta in dettaglio in \secref{sec:sess_login}). Questa procedura si
+(descritta in dettaglio in sez.~\ref{sec:sess_login}). Questa procedura si
incarica di verificare l'identità dell'utente, in genere attraverso la
richiesta di una parola d'ordine (la \textit{password}), anche se sono
possibili meccanismi diversi.\footnote{Ad esempio usando la libreria PAM
\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
-\file{/etc/groups}). Questi numeri sono l'\textit{user identifier}, detto in
-breve \textsl{userid}, ed indicato dall'acronimo \acr{uid}, e il \textit{group
- identifier}, detto in breve \textsl{groupid}, 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.}
+\itindex{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 per ogni processo
-dell'utente a cui appartiene ed impedire ad altri utenti di interferire con
-esso. Inoltre con questo sistema viene anche garantita una forma base di
-sicurezza interna in quanto anche l'accesso ai file (vedi
-\secref{sec:file_access_control}) è regolato da questo meccanismo di
+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
+quest'ultimo. Inoltre con questo sistema viene anche garantita una forma base
+di sicurezza interna in quanto anche l'accesso ai file (vedi
+sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo di
identificazione.
Infine in ogni Unix è presente un utente speciale privilegiato, il cosiddetto
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}
funzioni occorre includere con la direttiva \code{\#include} questi file nei
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 \tabref{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.
+provvisti dalla \acr{glibc}), In tab.~\ref{tab:intro_posix_header} si sono
+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.}
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}.\\
Per questo motivo tutte le funzioni di libreria di solito non fanno
riferimento ai tipi elementari dello standard del linguaggio C, ma ad una
serie di \textsl{tipi primitivi}\index{tipo!primitivo} del sistema, riportati
-in \tabref{tab:intro_primitive_types}, e definiti nell'header file
+in tab.~\ref{tab:intro_primitive_types}, e definiti nell'header file
\file{sys/types.h}, in modo da mantenere completamente indipendenti i tipi
utilizzati dalle funzioni di sistema dai tipi elementari supportati dal
compilatore C.
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 \tabref{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 si può parlare
-di POSIX.4 come di POSIX.1b).
+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
+si può parlare di POSIX.4 come di POSIX.1b).
Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
-talvolta poi i riferimenti cambiamo nome, per cui anche solo seguire le
+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}
-{http://www.pasc.org/standing/sd11.html}.
+{\textsf{http://www.pasc.org/standing/sd11.html}}.
\begin{table}[htb]
\footnotesize
POSIX.2 & 1003.2 & 9945-2& Comandi \\
POSIX.3 & 2003 &TR13210& Metodi di test \\
POSIX.4 & 1003.1b & --- & Estensioni real-time \\
- POSIX.4a& 1003.1c & --- & Threads \\
+ POSIX.4a& 1003.1c & --- & Thread \\
POSIX.4b& 1003.1d &9945-1& Ulteriori estensioni real-time \\
POSIX.5 & 1003.5 & 14519& Interfaccia per il linguaggio ADA \\
POSIX.6 & 1003.2c,1e& 9945-2& Sicurezza \\
POSIX.8 & 1003.1f& 9945-1& Accesso ai file via rete \\
- POSIX.9 & 1003.9 & --- & Intercaccia per il Fortran-77 \\
- POSIX.12& 1003.1g& 9945-1& Sockets \\
+ POSIX.9 & 1003.9 & --- & Interfaccia per il Fortran-77 \\
+ POSIX.12& 1003.1g& 9945-1& Socket \\
\hline
\end{tabular}
\caption{Elenco dei vari standard POSIX e relative denominazioni.}
\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
-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
Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
-\textit{thread} (vedi \capref{cha:threads}), e dallo standard POSIX.1b per
+\textit{thread} (vedi cap.~\ref{cha:threads}), e dallo standard POSIX.1b per
quanto riguarda i segnali e lo scheduling real-time
-(\secref{sec:sig_real_time} e \secref{sec:proc_real_time}), la misura del
-tempo, i meccanismi di intercomunicazione (\secref{sec:ipc_posix}) e l'I/O
-asincrono (\secref{sec:file_asyncronous_io}).
+(sez.~\ref{sec:sig_real_time} e sez.~\ref{sec:proc_real_time}), la misura del
+tempo, i meccanismi di intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O
+asincrono (sez.~\ref{sec:file_asyncronous_io}).
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
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
del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard.
-\subsection{Lo ``standard'' BSD}
+\subsection{Lo ``\textsl{standard}'' BSD}
\label{sec:intro_bsd}
Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
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
-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
-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}
Le funzionalità implementate sono principalmente il meccanismo di
intercomunicazione fra i processi e la memoria condivisa (il cosiddetto System
-V IPC, che vedremo in \secref{sec:ipc_sysv}) le funzioni della famiglia
+V IPC, che vedremo in sez.~\ref{sec:ipc_sysv}) le funzioni della famiglia
\func{hsearch} e \func{drand48}, \func{fmtmsg} e svariate funzioni
matematiche.
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
\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
compatibilità prima di quelle normali.
\item[\macro{\_SVID\_SOURCE}] definendo questa macro si attivano le
funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
- standard ISO C, POSIX.1, POSIX.2, and X/Open.
+ standard ISO C, POSIX.1, POSIX.2, e X/Open.
\item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si attivano le
funzionalità descritte nella \textit{X/Open Portability Guide}. Anche queste
- sono un soprainsieme di quelle definite in POSIX.1 e POSIX.2 ed in effetti
+ 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}.
includere i vari header file.
-\subsection{Gli standard di GNU/Linux}
-\label{sec:intro_linux_std}
+%% \subsection{Gli standard di GNU/Linux}
+%% \label{sec:intro_linux_std}
-Da fare (o cassare, a seconda del tempo e della voglia).
+% TODO Da fare (o cassare, a seconda del tempo e della voglia).
projects / gapil.git / blobdiff