%% intro.tex
%%
-%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2007 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".
%%
+
\chapter{L'architettura del sistema}
\label{cha:intro_unix}
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 \itindex{scheduler} \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{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.
+cosiddetto \itindex{prehemptive~multitasking} \textit{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 ``\textsl{virtuale}'' (vedi
-\secref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di
+\index{memoria~virtuale} \textsl{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 perché in
+ realtà c'è un programma iniziale, che è 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
Questo è importante da capire perché programmare in Linux significa anzitutto
essere in grado di usare le varie interfacce contenute nella Libreria Standard
-del C, in quanto né il kernel, né il linguaggio C, implementano direttamente
+del C, in quanto né il kernel, né il linguaggio C implementano direttamente
operazioni comuni come l'allocazione dinamica della memoria, l'input/output
bufferizzato o la manipolazione delle stringhe, presenti in qualunque
programma.
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
+ 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
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.
-
-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{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.
+definendo gruppi di lavoro, di accesso a determinate risorse, ecc.
+
+L'utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad
+un nome espresso in caratteri è inserita nei due file \conffile{/etc/passwd} e
+\conffile{/etc/group}.\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 \itindex{Name~Service~Switch} \textit{Name Service
+ Switch}, su varie tipologie di supporti, compresi server centralizzati
+ come LDAP.} 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
+\index{tipo!elementare} \textit{tipi elementari}del linguaggio C (come
\ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati
\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}.\\
+ \type{ino\_t} & Numero di \index{inode} \textit{inode}.\\
\type{key\_t} & Chiave per il System V IPC.\\
\type{loff\_t} & Posizione corrente in un file.\\
\type{mode\_t} & Attributi di un file.\\
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
+serie di \index{tipo!primitivo} \textsl{tipi primitivi} del sistema, riportati
+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
\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
-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}).
+\textit{thread} (vedi cap.~\ref{cha:threads}), e dallo standard POSIX.1b per
+quanto riguarda i segnali e lo \itindex{scheduler} scheduling real-time
+(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}).
-\subsection{Lo standard X/Open -- XPG3}
+\subsection{Lo standard X/Open}
\label{sec:intro_xopen}
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
-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
Specification}, SUSv1, più comunemente nota come \textit{Unix 95}.
-\subsection{Gli standard Unix -- Open Group}
+\subsection{Gli standard Unix}
\label{sec:intro_opengroup}
Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata
da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
-alla costituzione dell'Open Group, un consorzio internazionale che raccoglie
-produttori, utenti industriali, entità accademiche e governative.
+alla costituzione dell'\textit{Open Group}, un consorzio internazionale che
+raccoglie produttori, utenti industriali, entità accademiche e governative.
Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
il lavoro di standardizzazione delle varie implementazioni, rilasciando
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
\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
+di Berkeley 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
+dell'Università di Berkeley, ha provveduto nel tempo una serie di estensioni e
+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 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}.
\end{basedescript}
In particolare è da sottolineare che le \acr{glibc} supportano alcune
-estensioni specifiche GNU, che non sono comprese in nessuno degli
-standard citati. Per poterle utilizzare esse devono essere attivate
-esplicitamente definendo la macro \macro{\_GNU\_SOURCE} prima di
-includere i vari header file.
-
-
-\subsection{Gli standard di GNU/Linux}
-\label{sec:intro_linux_std}
-
-Da fare (o cassare, a seconda del tempo e della voglia).
-
+estensioni specifiche GNU, che non sono comprese in nessuno degli standard
+citati. Per poterle utilizzare esse devono essere attivate esplicitamente
+definendo la macro \macro{\_GNU\_SOURCE} prima di includere i vari header
+file.
+
+
+%% \subsection{Gli standard di GNU/Linux}
+%% \label{sec:intro_linux_std}
+
+% TODO Da fare (o cassare, a seconda del tempo e della voglia).
+
+
+
+% LocalWords: like kernel multitasking scheduler prehemptive sez swap is cap
+% LocalWords: everything bootstrap init shell Windows Foundation system call
+% LocalWords: fig libc uClib glibc embedded Library POSIX username PAM Methods
+% LocalWords: Pluggable Autentication group supplementary Name Service Switch
+% LocalWords: LDAP identifier uid gid superuser root if BSD SVr dall' American
+% LocalWords: National Institute International Organisation IEC header tab gcc
+% LocalWords: assert ctype dirent errno fcntl limits malloc setjmp signal utmp
+% LocalWords: stdarg stdio stdlib string times unistd library int short caddr
+% LocalWords: address clock dev ino inode key IPC loff nlink off pid rlim size
+% LocalWords: sigset ssize ptrdiff sys nell'header IEEE Richard Portable of TR
+% LocalWords: Operating Interface dell'IEEE Electrical and Electronics thread
+% LocalWords: Engeneers Socket NT matching regular expression scheduling l'I
+% LocalWords: XPG Portability Issue Application Programmable XTI Transport AT
+% LocalWords: socket Spec Novell Specification SUSv CDE Motif Berkley select
+% LocalWords: SunOS l'AT Sun HP Xenix Description SVID Laboratories MP hsearch
+% LocalWords: drand fmtmsg define SOURCE lbsd compat XOPEN version ISOC Large
+% LocalWords: LARGEFILE Support LFS dell'
%%% Local Variables:
projects / gapil.git / blobdiff