3 %% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
12 \chapter{L'architettura del sistema}
13 \label{cha:intro_unix}
15 In questo primo capitolo sarà fatta un'introduzione ai concetti generali su
16 cui è basato un sistema operativo di tipo Unix come GNU/Linux, in questo modo
17 potremo fornire una base di comprensione mirata a sottolineare le peculiarità
18 del sistema che sono più rilevanti per quello che riguarda la programmazione.
20 Dopo un'introduzione sulle caratteristiche principali di un sistema di tipo
21 Unix passeremo ad illustrare alcuni dei concetti base dell'architettura di
22 GNU/Linux (che sono comunque comuni a tutti i sistemi \textit{unix-like}) ed
23 introdurremo alcuni degli standard principali a cui viene fatto riferimento.
26 \section{Una panoramica}
27 \label{sec:intro_unix_struct}
29 In questa prima sezione faremo una breve panoramica sull'architettura del
30 sistema. Chi avesse già una conoscenza di questa materia può tranquillamente
31 saltare questa sezione.
34 \subsection{Concetti base}
35 \label{sec:intro_base_concept}
37 Il concetto base di un sistema unix-like è quello di un nucleo del sistema (il
38 cosiddetto \textit{kernel}, nel nostro caso Linux) a cui si demanda la
39 gestione delle risorse essenziali (la CPU, la memoria, le periferiche) mentre
40 tutto il resto, quindi anche la parte che prevede l'interazione con l'utente,
41 dev'essere realizzato tramite programmi eseguiti dal kernel, che accedano
42 alle risorse hardware tramite delle richieste a quest'ultimo.
44 Fin dall'inizio uno Unix si presenta come un sistema operativo
45 \textit{multitasking}, cioè in grado di eseguire contemporaneamente più
46 programmi, e multiutente, in cui è possibile che più utenti siano connessi ad
47 una macchina eseguendo più programmi ``\textsl{in contemporanea}''; in realtà,
48 almeno per macchine a processore singolo, i programmi vengono eseguiti
49 singolarmente a rotazione.
51 % Questa e` una distinzione essenziale da capire,
52 %specie nei confronti dei sistemi operativi successivi, nati per i personal
53 %computer (e quindi per un uso personale), sui quali l'hardware (allora
54 %limitato) non consentiva la realizzazione di un sistema evoluto come uno unix.
56 I kernel Unix più recenti, come Linux, sono realizzati sfruttando alcune
57 caratteristiche dei processori moderni come la gestione hardware della memoria
58 e la modalità protetta. In sostanza con i processori moderni si può
59 disabilitare temporaneamente l'uso di certe istruzioni e l'accesso a certe
60 zone di memoria fisica. Quello che succede è che il kernel è il solo
61 programma ad essere eseguito in modalità privilegiata, con il completo accesso
62 all'hardware, mentre i programmi normali vengono eseguiti in modalità protetta
63 e non possono accedere direttamente alle zone di memoria riservate o alle
64 porte di input/output.
66 Una parte del kernel, lo \itindex{scheduler} \textit{scheduler}, si occupa di
67 stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle
68 priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il
69 cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
70 multitasking}). Questo verrà comunque eseguito in modalità protetta; quando
71 necessario il processo potrà accedere alle risorse hardware soltanto
72 attraverso delle opportune chiamate al sistema che restituiranno il controllo
75 La memoria viene sempre gestita dal kernel attraverso il meccanismo della
76 \index{memoria~virtuale} \textsl{memoria virtuale}, che consente di assegnare
77 a ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi
78 sez.~\ref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di
79 gestione della memoria, si incaricherà di rimappare automaticamente sulla
80 memoria disponibile, salvando su disco quando necessario (nella cosiddetta
81 area di \textit{swap}) le pagine di memoria in eccedenza.
83 Le periferiche infine vengono viste in genere attraverso un'interfaccia
84 astratta che permette di trattarle come fossero file, secondo il concetto per
85 cui \textit{everything is a file}, su cui torneremo in dettaglio in
86 cap.~\ref{cha:file_intro}. Questo non è vero per le interfacce di rete, che
87 hanno un'interfaccia diversa, ma resta valido il concetto generale che tutto
88 il lavoro di accesso e gestione a basso livello è effettuato dal kernel.
91 \subsection{Il kernel e il sistema}
92 \label{sec:intro_kern_and_sys}
94 Uno dei concetti fondamentali su cui si basa l'architettura dei sistemi Unix è
95 quello della distinzione fra il cosiddetto \textit{user space}, che
96 contraddistingue l'ambiente in cui vengono eseguiti i programmi, e il
97 \textit{kernel space}, che è l'ambiente in cui viene eseguito il kernel. Ogni
98 programma vede sé stesso come se avesse la piena disponibilità della CPU e
99 della memoria ed è, salvo i meccanismi di comunicazione previsti
100 dall'architettura, completamente ignaro del fatto che altri programmi possono
101 essere messi in esecuzione dal kernel.
103 Per questa separazione non è possibile ad un singolo programma disturbare
104 l'azione di un altro programma o del sistema e questo è il principale motivo
105 della stabilità di un sistema unix-like nei confronti di altri sistemi in cui
106 i processi non hanno di questi limiti, o che vengono per vari motivi eseguiti
107 al livello del kernel. Pertanto deve essere chiaro a chi programma in Unix che
108 l'accesso diretto all'hardware non può avvenire se non all'interno del kernel;
109 al di fuori dal kernel il programmatore deve usare le opportune interfacce che
110 quest'ultimo fornisce allo user space.
112 Per capire meglio la distinzione fra kernel space e user space si può prendere
113 in esame la procedura di avvio di un sistema unix-like; all'avvio il BIOS (o
114 in generale il software di avvio posto nelle EPROM) eseguirà la procedura di
115 avvio del sistema (il cosiddetto \textit{bootstrap}\footnote{il nome deriva da
116 un'espressione gergale che significa ``sollevarsi da terra tirandosi per le
117 stringhe delle scarpe'', per indicare il compito, almeno apparentemente
118 impossibile, di far eseguire un programma a partire da un computer appena
119 acceso che appunto non ne contiene nessuno; non è impossibile perché in
120 realtà c'è un programma iniziale, che è il BIOS.}), incaricandosi di
121 caricare il kernel in memoria e di farne partire l'esecuzione; quest'ultimo,
122 dopo aver inizializzato le periferiche, farà partire il primo processo,
123 \cmd{init}, che è quello che a sua volta farà partire tutti i processi
124 successivi. Fra questi ci sarà pure quello che si occupa di dialogare con la
125 tastiera e lo schermo della console, e quello che mette a disposizione
126 dell'utente che si vuole collegare, un terminale e la \textit{shell} da cui
129 E' da rimarcare come tutto ciò, che usualmente viene visto come parte del
130 sistema, non abbia in realtà niente a che fare con il kernel, ma sia
131 effettuato da opportuni programmi che vengono eseguiti, allo stesso modo di un
132 qualunque programma di scrittura o di disegno, in user space.
134 Questo significa, ad esempio, che il sistema di per sé non dispone di
135 primitive per tutta una serie di operazioni (come la copia di un file) che
136 altri sistemi (come Windows) hanno invece al loro interno. Pertanto buona
137 parte delle operazioni di normale amministrazione di un sistema, come quella
138 in esempio, sono implementate come normali programmi.
140 %Una delle caratteristiche base di unix \`e perci\`o che \`e possibile
141 %realizzare un sistema di permessi e controlli che evitano che i programmi
142 %eseguano accessi non autorizzati.
144 Per questo motivo quando ci si riferisce al sistema nella sua interezza è
145 corretto parlare di un sistema GNU/Linux: da solo il kernel è assolutamente
146 inutile; quello che costruisce un sistema operativo utilizzabile è la presenza
147 di tutta una serie di librerie e programmi di utilità (che di norma sono
148 quelli realizzati dal progetto GNU della Free Software Foundation) che
149 permettono di eseguire le normali operazioni che ci si aspetta da un sistema
153 \subsection{Chiamate al sistema e librerie di funzioni}
154 \label{sec:intro_syscall}
156 Come accennato le interfacce con cui i programmi possono accedere all'hardware
157 vanno sotto il nome di chiamate al sistema (le cosiddette \textit{system
158 call}), si tratta di un insieme di funzioni che un programma può chiamare,
159 per le quali viene generata un'interruzione del processo passando il controllo
160 dal programma al kernel. Sarà poi quest'ultimo che (oltre a compiere una serie
161 di operazioni interne come la gestione del multitasking e l'allocazione della
162 memoria) eseguirà la funzione richiesta in \textit{kernel space} restituendo i
163 risultati al chiamante.
165 Ogni versione di Unix ha storicamente sempre avuto un certo numero di queste
166 chiamate, che sono riportate nella seconda sezione del \textsl{Manuale di
167 programmazione di Unix} (quella cui si accede con il comando \cmd{man 2
168 <nome>}) e Linux non fa eccezione. Queste sono poi state codificate da vari
169 standard, che esamineremo brevemente in sez.~\ref{sec:intro_standard}. Uno
170 schema elementare della struttura del sistema è riportato in
171 fig.~\ref{fig:intro_sys_struct}.
175 % \includegraphics[width=10cm]{img/struct_sys}
177 \filldraw[fill=black!20] (0,0) rectangle (7.5,1);
178 \draw (3.75,0.5) node {System Call Interface};
179 \filldraw[fill=black!35] (0,1) rectangle (7.5,4);
180 \draw (3.75,2.5) node {\huge{kernel}};
181 \filldraw[fill=black!20] (0,4) rectangle (2.5,5);
182 \draw (1.25,4.5) node {scheduler};
183 \filldraw[fill=black!20] (2.5,4) rectangle (5,5);
184 \draw (3.75,4.5) node {VM};
185 \filldraw[fill=black!20] (5,4) rectangle (7.5,5);
186 \draw (6.25,4.5) node {driver};
188 \draw (1.25,7) node(cpu) [ellipse,draw] {CPU};
189 \draw (3.75,7) node(mem) [ellipse,draw] {memoria};
190 \draw (6.25,7) node(disk) [ellipse,draw] {disco};
192 \draw[<->] (cpu) -- (1.25,5);
193 \draw[<->] (mem) -- (3.75,5);
194 \draw[<->] (disk) -- (6.25,5);
196 \draw (7.5,0) node [anchor=base west] {kernel space};
197 \draw (7.5,-1) node [anchor=west] {user space};
199 \draw (-1,-0.5) -- (8.5, -0.5);
201 \draw (0,-2) rectangle (7.5,-1);
202 \draw (3.75, -1.5) node {GNU C Library};
203 \draw[->] (1.25,-1) -- (1.25,0);
204 \draw[->] (3.75,-1) -- (3.75,0);
205 \draw[->] (6.25,-1) -- (6.25,0);
207 \draw (1.25,-3) node(proc1) [rectangle,draw] {processo};
208 \draw (3.75,-3) node(proc2) [rectangle,draw] {processo};
209 \draw (6.25,-3) node(proc3) [rectangle,draw] {processo};
211 \draw[->] (1.25,-2) -- (proc1);
212 \draw[->] (3.75,-2) -- (proc2);
213 \draw[->] (6.25,-2) -- (proc3);
215 \caption{Schema di massima della struttura di interazione fra processi,
216 kernel e dispositivi in Linux.}
217 \label{fig:intro_sys_struct}
220 Normalmente ciascuna di queste chiamate al sistema fornite dal kernel viene
221 rimappata in opportune funzioni con lo stesso nome definite dentro la Libreria
222 Standard del C, che, oltre alle interfacce alle \textit{system call}, contiene
223 anche tutta la serie delle ulteriori funzioni definite dai vari standard, che
224 sono comunemente usate nella programmazione.
226 Questo è importante da capire perché programmare in Linux significa anzitutto
227 essere in grado di usare le varie interfacce contenute nella Libreria Standard
228 del C, in quanto né il kernel, né il linguaggio C implementano direttamente
229 operazioni comuni come l'allocazione dinamica della memoria, l'input/output
230 bufferizzato sui file o la manipolazione delle stringhe, presenti in qualunque
233 Quanto appena illustrato mette in evidenza il fatto che nella stragrande
234 maggioranza dei casi,\footnote{esistono implementazioni diverse delle librerie
235 Standard del C, come le \textit{libc5} o le \textit{uClib}, che non derivano
236 dal progetto GNU. Le \textit{libc5} oggi sono, tranne casi particolari,
237 completamente soppiantate dalle \acr{glibc}, le \textit{uClib} pur non
238 essendo complete come le \acr{glibc}, restano invece molto diffuse nel mondo
239 embedded per le loro dimensioni ridotte (e soprattutto la possibilità di
240 togliere le parti non necessarie), e pertanto costituiscono un valido
241 rimpiazzo delle \acr{glibc} in tutti quei sistemi specializzati che
242 richiedono una minima occupazione di memoria.} si dovrebbe usare il nome
243 GNU/Linux (piuttosto che soltanto Linux) in quanto una parte essenziale del
244 sistema (senza la quale niente funzionerebbe) è la \textit{GNU Standard C
245 Library} (in breve \acr{glibc}), ovvero la libreria realizzata dalla Free
246 Software Foundation nella quale sono state implementate tutte le funzioni
247 essenziali definite negli standard POSIX e ANSI C, utilizzate da qualunque
250 Le funzioni di questa libreria sono quelle riportate dalla terza sezione del
251 \textsl{Manuale di Programmazione di Unix} (cioè accessibili con il comando
252 \cmd{man 3 <nome>}) e sono costruite sulla base delle chiamate al sistema del
253 kernel; è importante avere presente questa distinzione, fondamentale dal punto
254 di vista dell'implementazione, anche se poi, nella realizzazione di normali
255 programmi, non si hanno differenze pratiche fra l'uso di una funzione di
256 libreria e quello di una chiamata al sistema.
258 Le librerie standard del C consentono comunque, nel caso non sia presente una
259 specifica funzione di libreria corrispondente, di eseguire una \textit{system
260 call} generica tramite la funzione \funcd{syscall}, il cui prototipo,
261 accessibile se si è definita la macro \macro{\_GNU\_SOURCE}, (vedi
262 sez.~\ref{sec:intro_gcc_glibc_std}) è:
265 \headdecl{sys/syscall.h}
266 \funcdecl{int syscall(int number, ...)}
268 Esegue la \textit{system call} indicata da \param{number}.
271 La funzione richiede come primo argomento il numero della \textit{system call}
272 da invocare, seguita dagli argomenti da passare alla stessa (che ovviamente
273 dipendono da quest'ultima), e restituisce il codice di ritorno della
274 \textit{system call} invocata. In generale un valore nullo indica il successo
275 ed un valore negativo è un codice di errore che poi viene memorizzato nella
276 variabile \var{errno} (sulla gestione degli errori torneremo in dettaglio in
277 sez.~\ref{sec:sys_errors}).
279 Il valore di \param{number} dipende sia dalla versione di kernel che
280 dall'architettura,\footnote{in genere le vecchie \textit{system call} non
281 vengono eliminate e se ne aggiungono di nuove con nuovi numeri.} ma
282 ciascuna \textit{system call} viene in genere identificata da una costante
283 nella forma \texttt{SYS\_*} dove al prefisso viene aggiunto il nome che spesso
284 corrisponde anche alla omonima funzione di libreria; queste costanti sono
285 definite nel file \texttt{sys/syscall.h}, ma si possono anche usare
286 direttamente valori numerici.
289 \subsection{Un sistema multiutente}
290 \label{sec:intro_multiuser}
292 Linux, come gli altri kernel Unix, nasce fin dall'inizio come sistema
293 multiutente, cioè in grado di fare lavorare più persone in contemporanea. Per
294 questo esistono una serie di meccanismi di sicurezza, che non sono previsti in
295 sistemi operativi monoutente, e che occorre tenere presenti.
297 Il concetto base è quello di utente (\textit{user}) del sistema, le cui
298 capacità rispetto a quello che può fare sono sottoposte a ben precisi limiti.
299 Sono così previsti una serie di meccanismi per identificare i singoli utenti
300 ed una serie di permessi e protezioni per impedire che utenti diversi possano
301 danneggiarsi a vicenda o danneggiare il sistema. Questi meccanismi sono
302 realizzati dal kernel stesso ed attengono alle operazioni più varie, e
303 torneremo su di essi in dettaglio più avanti.
305 Ogni utente è identificato da un nome (l'\textit{username}), che è quello che
306 viene richiesto all'ingresso nel sistema dalla procedura di \textit{login}
307 (descritta in dettaglio in sez.~\ref{sec:sess_login}). Questa procedura si
308 incarica di verificare l'identità dell'utente, in genere attraverso la
309 richiesta di una parola d'ordine (la \textit{password}), anche se sono
310 possibili meccanismi diversi.\footnote{ad esempio usando la libreria PAM
311 (\textit{Pluggable Autentication Methods}) è possibile astrarre
312 completamente dai meccanismi di autenticazione e sostituire ad esempio l'uso
313 delle password con meccanismi di identificazione biometrica.} Eseguita la
314 procedura di riconoscimento in genere il sistema manda in esecuzione un
315 programma di interfaccia (che può essere la \textit{shell} su terminale o
316 un'interfaccia grafica) che mette a disposizione dell'utente un meccanismo con
317 cui questo può impartire comandi o eseguire altri programmi.
319 Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto
320 \textit{default group}), ma può essere associato ad altri gruppi (i
321 \textit{supplementary group}), questo permette di gestire i permessi di
322 accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
323 definendo gruppi di lavoro, di accesso a determinate risorse, ecc.
325 L'utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad
326 un nome espresso in caratteri è inserita nei due file \conffile{/etc/passwd} e
327 \conffile{/etc/group}.\footnote{in realtà negli sistemi più moderni, come
328 vedremo in sez.~\ref{sec:sys_user_group} queste informazioni possono essere
329 mantenute, con l'uso del \itindex{Name~Service~Switch} \textit{Name Service
330 Switch}, su varie tipologie di supporti, compresi server centralizzati
331 come LDAP.} Questi numeri sono l'\textit{user identifier}, detto in breve
332 \textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il \textit{group
333 identifier}, detto in breve \textsl{group-ID}, ed identificato dall'acronimo
334 \acr{gid}, e sono quelli che vengono usati dal kernel per identificare
335 l'utente; torneremo in dettaglio su questo argomento in
336 sez.~\ref{sec:proc_perms}.
338 In questo modo il sistema è in grado di tenere traccia dell'utente a cui
339 appartiene ciascun processo ed impedire ad altri utenti di interferire con
340 quest'ultimo. Inoltre con questo sistema viene anche garantita una forma base
341 di sicurezza interna in quanto anche l'accesso ai file (vedi
342 sez.~\ref{sec:file_access_control}) è regolato da questo meccanismo di
345 Infine in ogni Unix è presente un utente speciale privilegiato, il cosiddetto
346 \textit{superuser}, il cui username è di norma \textit{root}, ed il cui
347 \acr{uid} è zero. Esso identifica l'amministratore del sistema, che deve
348 essere in grado di fare qualunque operazione; per l'utente \textit{root}
349 infatti i meccanismi di controllo descritti in precedenza sono
350 disattivati.\footnote{i controlli infatti vengono sempre eseguiti da un codice
351 del tipo: ``\code{if (uid) \{ \textellipsis\ \}}''.}
354 \section{Gli standard}
355 \label{sec:intro_standard}
357 In questa sezione faremo una breve panoramica relativa ai vari standard che
358 nel tempo sono stati formalizzati da enti, associazioni, consorzi e
359 organizzazioni varie al riguardo del sistema o alle caratteristiche che si
360 sono stabilite come standard di fatto in quanto facenti parte di alcune
361 implementazioni molto diffuse come BSD o System V.
363 Ovviamente prenderemo in considerazione solo gli standard riguardanti
364 interfacce di programmazione e le altre caratteristiche di un sistema
365 unix-like (alcuni standardizzano pure i comandi base del sistema e la shell)
366 ed in particolare ci concentreremo sul come ed in che modo essi sono
367 supportati sia per quanto riguarda il kernel che le librerie del C (con una
368 particolare attenzione alle \acr{glibc}).
371 \subsection{Lo standard ANSI C}
372 \label{sec:intro_ansiC}
374 Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National
375 Standard Institute} come prima standardizzazione del linguaggio C e per
376 questo si fa riferimento ad esso anche come C89. L'anno successivo è stato
377 adottato dalla ISO (\textit{International Standard Organisation}) come
378 standard internazionale con la sigla ISO/IEC 9899:1990, e per questo è noto
379 anche sotto il nome di standard ISO C, o ISO C90.
381 Nel 1999 è stata pubblicata una revisione dello standard C89, che viene
382 usualmente indicata come C99, anche questa è stata ratificata dalla ISO con la
383 sigla ISO/IEC 9899:1990, per cui vi si fa riferimento anche come ISO C99.
385 Scopo dello standard è quello di garantire la portabilità dei programmi C fra
386 sistemi operativi diversi, ma oltre alla sintassi ed alla semantica del
387 linguaggio C (operatori, parole chiave, tipi di dati) lo standard prevede
388 anche una libreria di funzioni che devono poter essere implementate su
389 qualunque sistema operativo.
391 Per questo motivo, anche se lo standard non ha alcun riferimento ad un sistema
392 di tipo Unix, GNU/Linux (per essere precisi le \acr{glibc}), come molti Unix
393 moderni, provvede la compatibilità con questo standard, fornendo le funzioni
394 di libreria da esso previste. Queste sono dichiarate in una serie di
395 \textit{header file}\footnote{i file di dichiarazione di variabili, tipi e
396 funzioni, usati normalmente da un compilatore C. Per poter accedere alle
397 funzioni occorre includere con la direttiva \code{\#include} questi file nei
398 propri programmi; per ciascuna funzione che tratteremo in seguito
399 indicheremo anche gli \textit{header file} necessari ad usarla.} (anch'essi
400 provvisti dalla \acr{glibc}), In tab.~\ref{tab:intro_posix_header} si sono
401 riportati i principali \textit{header file} definiti nello standard POSIX ed
402 ANSI C, che sono anche quelli definiti negli altri standard descritti nelle
408 \begin{tabular}[c]{|l|c|c|l|}
410 \multirow{2}{*}{\textbf{Header}}&
411 \multicolumn{2}{|c|}{\textbf{Standard}}&
412 \multirow{2}{*}{\textbf{Contenuto}} \\
417 \file{assert.h}&$\bullet$& & Verifica le asserzioni fatte in un
419 \file{ctype.h} &$\bullet$& & Tipi standard.\\
420 \file{dirent.h}& &$\bullet$& Manipolazione delle directory.\\
421 \file{errno.h} & &$\bullet$& Errori di sistema.\\
422 \file{fcntl.h} & &$\bullet$& Controllo sulle opzioni dei file.\\
423 \file{limits.h}& &$\bullet$& Limiti e parametri del sistema.\\
424 \file{malloc.h}&$\bullet$& & Allocazione della memoria.\\
425 \file{setjmp.h}&$\bullet$& & Salti non locali.\\
426 \file{signal.h}& &$\bullet$& Gestione dei segnali.\\
427 \file{stdarg.h}&$\bullet$& & Gestione di funzioni a argomenti
429 \file{stdio.h} &$\bullet$& & I/O bufferizzato in standard ANSI C.\\
430 \file{stdlib.h}&$\bullet$& & Definizioni della libreria standard.\\
431 \file{string.h}&$\bullet$& & Manipolazione delle stringhe.\\
432 \file{time.h} & &$\bullet$& Gestione dei tempi.\\
433 \file{times.h} &$\bullet$& & Gestione dei tempi.\\
434 \file{unistd.h}& &$\bullet$& Unix standard library.\\
435 \file{utmp.h} & &$\bullet$& Registro connessioni utenti.\\
438 \caption{Elenco dei vari header file definiti dallo standard POSIX.}
439 \label{tab:intro_posix_header}
442 In realtà \acr{glibc} ed i relativi header file definiscono un insieme di
443 funzionalità in cui sono incluse come sottoinsieme anche quelle previste dallo
444 standard ANSI C. È possibile ottenere una conformità stretta allo standard
445 (scartando le funzionalità addizionali) usando il \cmd{gcc} con l'opzione
446 \cmd{-ansi}. Questa opzione istruisce il compilatore a definire nei vari
447 header file soltanto le funzionalità previste dallo standard ANSI C e a non
448 usare le varie estensioni al linguaggio e al preprocessore da esso supportate.
451 \subsection{I tipi di dati primitivi}
452 \label{sec:intro_data_types}
454 Uno dei problemi di portabilità del codice più comune è quello dei tipi di
455 dati utilizzati nei programmi, che spesso variano da sistema a sistema, o
456 anche da una architettura ad un'altra (ad esempio passando da macchine con
457 processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
458 \index{tipo!elementare} \textit{tipi elementari}del linguaggio C (come
459 \ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
461 Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati
462 associati ad alcune variabili nei sistemi Unix, dando per scontata la
463 dimensione. Ad esempio la posizione corrente all'interno di un file è sempre
464 stata associata ad un intero a 32 bit, mentre il numero di dispositivo è
465 sempre stato associato ad un intero a 16 bit. Storicamente questi erano
466 definiti rispettivamente come \ctyp{int} e \ctyp{short}, ma tutte le volte
467 che, con l'evolversi ed il mutare delle piattaforme hardware, alcuni di questi
468 tipi si sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad
469 una infinita serie di problemi di portabilità.
474 \begin{tabular}[c]{|l|l|}
476 \textbf{Tipo} & \textbf{Contenuto} \\
479 \type{caddr\_t} & Core address.\\
480 \type{clock\_t} & Contatore del tempo di sistema.\\
481 \type{dev\_t} & Numero di dispositivo (vedi sez.~\ref{sec:file_mknod}).\\
482 \type{gid\_t} & Identificatore di un gruppo.\\
483 \type{ino\_t} & Numero di \index{inode} \textit{inode}.\\
484 \type{key\_t} & Chiave per il System V IPC.\\
485 \type{loff\_t} & Posizione corrente in un file.\\
486 \type{mode\_t} & Attributi di un file.\\
487 \type{nlink\_t} & Contatore dei link su un file.\\
488 \type{off\_t} & Posizione corrente in un file.\\
489 \type{pid\_t} & Identificatore di un processo.\\
490 \type{rlim\_t} & Limite sulle risorse.\\
491 \type{sigset\_t}& Insieme di segnali.\\
492 \type{size\_t} & Dimensione di un oggetto.\\
493 \type{ssize\_t} & Dimensione in numero di byte ritornata dalle funzioni.\\
494 \type{ptrdiff\_t}& Differenza fra due puntatori.\\
495 \type{time\_t} & Numero di secondi (in \itindex{calendar~time}
496 \textsl{tempo di calendario}, vedi
497 sez.~\ref{sec:sys_time}).\\
498 \type{uid\_t} & Identificatore di un utente.\\
501 \caption{Elenco dei tipi primitivi, definiti in \file{sys/types.h}.}
502 \label{tab:intro_primitive_types}
505 Per questo motivo tutte le funzioni di libreria di solito non fanno
506 riferimento ai tipi elementari dello standard del linguaggio C, ma ad una
507 serie di \index{tipo!primitivo} \textsl{tipi primitivi} del sistema, riportati
508 in tab.~\ref{tab:intro_primitive_types}, e definiti nell'header file
509 \file{sys/types.h}, in modo da mantenere completamente indipendenti i tipi
510 utilizzati dalle funzioni di sistema dai tipi elementari supportati dal
514 \subsection{Lo standard System V}
515 \label{sec:intro_sysv}
517 Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come
518 marchio depositato, sviluppandone una serie di versioni diverse; nel 1983 la
519 versione supportata ufficialmente venne rilasciata al pubblico con il nome di
520 Unix System V, e si fa rifermento a questa implementazione con la sigla SysV o
523 Negli anni successivi l'AT\&T proseguì lo sviluppo rilasciando varie versioni
524 con aggiunte e integrazioni, ed in particolare la \textit{release 2} nel 1985,
525 a cui si fa riferimento con SVr2 e la \textit{release 3} nel 1986 (denominata
526 SVr3). Le interfacce di programmazione di queste due versioni vennero
527 descritte formalmente in due documenti denominati \textit{System V Interface
528 Definition} (o SVID), pertanto nel 1995 venne rilasciata la specifica SVID 1
529 e nel 1986 la specifica SVID 2.
531 Nel 1989 un accordo fra vari venditori (AT\&T, Sun, HP, ed altri) portò ad una
532 versione di System V che provvedeva un'unificazione delle interfacce
533 comprendente anche Xenix e BSD, questa venne denominata \textit{release 4} o
534 SVr4. Anche le relative interfacce vennero descritte in un documento dal
535 titolo \textit{System V Interface Description}, venendo a costituire lo
536 standard SVID 3, che viene considerato la specifica finale di System V, ed a
537 cui spesso si fa riferimento semplicemente con SVID. Anche SVID costituisce un
538 sovrainsieme delle interfacce definite dallo standard POSIX.
540 Nel 1992 venne rilasciata una seconda versione del sistema, la SVr4.2; l'anno
541 successivo la divisione della AT\&T (già a suo tempo rinominata in Unix System
542 Laboratories) venne acquistata dalla Novell, che poi trasferì il marchio Unix
543 al consorzio X/Open. L'ultima versione di System V fu la SVr4.2MP rilasciata
544 nel Dicembre 93. Infine nel 1995 è stata rilasciata da SCO, che aveva
545 acquisito alcuni diritti sul codice di System V, una ulteriore versione delle
546 \textit{System V Interface Description}, che va sotto la denominazione di SVID
549 Linux e le \acr{glibc} implementano le principali funzionalità richieste dalle
550 specifiche SVID che non sono già incluse negli standard POSIX ed ANSI C, per
551 compatibilità con lo Unix System V e con altri Unix (come SunOS) che le
552 includono. Tuttavia le funzionalità più oscure e meno utilizzate (che non sono
553 presenti neanche in System V) sono state tralasciate.
555 Le funzionalità implementate sono principalmente il meccanismo di
556 intercomunicazione fra i processi e la memoria condivisa (il cosiddetto System
557 V IPC, che vedremo in sez.~\ref{sec:ipc_sysv}) le funzioni della famiglia
558 \func{hsearch} e \func{drand48}, \func{fmtmsg} e svariate funzioni
562 \subsection{Lo ``\textsl{standard}'' BSD}
563 \label{sec:intro_bsd}
565 Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
566 di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
567 mondo Unix. L'università di Berkeley proseguì nello sviluppo della base di
568 codice di cui disponeva, e che presentava parecchie migliorie rispetto alle
569 versioni allora disponibili, fino ad arrivare al rilascio di una versione
570 completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice
573 Benché BSD non sia mai stato uno standard formalizzato, l'implementazione
574 dello Unix dell'Università di Berkeley nella sua storia ha introdotto una
575 serie di estensioni e interfacce di grandissima rilevanza, come i link
576 simbolici, la funzione \code{select} ed i socket di rete. Per questo motivo si
577 fa spesso riferimento esplicito alle interfacce presenti nelle varie versioni
578 dello Unix di Berkeley con una apposita sigla.
580 Nel 1983, con il rilascio della versione 4.2 di BSD, venne definita una
581 implementazione delle funzioni di interfaccia a cui si fa riferimento con la
582 sigla 4.2BSD. Per fare riferimento alle precedenti versioni si usano poi le
583 sigle 3BSD e 4BSD (per le due versioni pubblicate nel 1980), e 4.1BSD per
584 quella pubblicata nel 1981.
586 Le varie estensioni ideate a Berkeley sono state via via aggiunte al sistema
587 nelle varie versioni succedutesi negli anni, che vanno sotto il nome di
588 4.3BSD, per la versione rilasciata nel 1986 e 4.4BSD, per la versione
589 rilasciata nel 1993, che costituisce l'ultima release ufficiale
590 dell'università di Berkeley. Si tenga presente che molte di queste interfacce
591 sono presenti in derivati commerciali di BSD come SunOS. Il kernel Linux e le
592 \acr{glibc} forniscono tutte queste estensioni che sono state in gran parte
593 incorporate negli standard successivi.
596 \subsection{Gli standard IEEE -- POSIX}
597 \label{sec:intro_posix}
599 Lo standard ufficiale creato da un organismo indipendente più attinente alle
600 interfacce di un sistema unix-like nel suo complesso (e che concerne sia il
601 kernel che le librerie che i comandi) è stato lo standard POSIX. Esso prende
602 origine dallo standard ANSI C, che contiene come sottoinsieme, prevedendo
603 ulteriori capacità per le funzioni in esso definite, ed aggiungendone di
606 In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da
607 Richard Stallman, sta per \textit{Portable Operating System Interface}, ma la
608 X finale denuncia la sua stretta relazione con i sistemi Unix. Esso nasce dal
609 lavoro dell'IEEE (\textit{Institute of Electrical and Electronics Engeneers})
610 che ne produsse una prima versione, nota come \textsl{IEEE 1003.1-1988},
611 mirante a standardizzare l'interfaccia con il sistema operativo.
613 Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
614 libreria, e in seguito sono stati prodotti anche altri standard per la shell e
615 i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
616 \itindex{thread} \textit{thread} (rispettivamente 1003.1d e 1003.1c) per i
617 socket (1003.1g) e vari altri. In tab.~\ref{tab:intro_posix_std} è riportata
618 una classificazione sommaria dei principali documenti prodotti, e di come sono
619 identificati fra IEEE ed ISO; si tenga conto inoltre che molto spesso si usa
620 l'estensione IEEE anche come aggiunta al nome POSIX; ad esempio è più comune
621 parlare di POSIX.4 come di POSIX.1b.
623 Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione
624 si aggiungono continuamente, mentre le versioni precedenti vengono riviste;
625 talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le
626 denominazioni usate diventa particolarmente faticoso; una pagina dove si
627 possono recuperare varie (e di norma piuttosto intricate) informazioni è
628 \href{http://www.pasc.org/standing/sd11.html}
629 {\textsf{http://www.pasc.org/standing/sd11.html}}.
634 \begin{tabular}[c]{|l|l|l|l|}
636 \textbf{Standard} & \textbf{IEEE} & \textbf{ISO} & \textbf{Contenuto} \\
639 POSIX.1 & 1003.1 & 9945-1& Interfacce di base \\
640 POSIX.1a& 1003.1a& 9945-1& Estensioni a POSIX.1 \\
641 POSIX.2 & 1003.2 & 9945-2& Comandi \\
642 POSIX.3 & 2003 &TR13210& Metodi di test \\
643 POSIX.4 & 1003.1b & --- & Estensioni real-time \\
644 POSIX.4a& 1003.1c & --- & \itindex{thread} Thread \\
645 POSIX.4b& 1003.1d &9945-1& Ulteriori estensioni real-time \\
646 POSIX.5 & 1003.5 & 14519& Interfaccia per il linguaggio ADA \\
647 POSIX.6 & 1003.2c,1e& 9945-2& Sicurezza \\
648 POSIX.8 & 1003.1f& 9945-1& Accesso ai file via rete \\
649 POSIX.9 & 1003.9 & --- & Interfaccia per il Fortran-77 \\
650 POSIX.12& 1003.1g& 9945-1& Socket \\
653 \caption{Elenco dei vari standard POSIX e relative denominazioni.}
654 \label{tab:intro_posix_std}
657 Benché l'insieme degli standard POSIX siano basati sui sistemi Unix, essi
658 definiscono comunque un'interfaccia di programmazione generica e non fanno
659 riferimento ad una implementazione specifica (ad esempio esiste
660 un'implementazione di POSIX.1 anche sotto Windows NT).
662 Linux e le \acr{glibc} implementano tutte le funzioni definite nello standard
663 POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per
664 funzioni di \textit{pattern matching} e per la manipolazione delle
665 \textit{regular expression}), che vengono usate dalla shell e dai comandi di
666 sistema e che sono definite nello standard POSIX.2.
668 Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
669 ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
670 \itindex{thread} \textit{thread} (vedi cap.~\ref{cha:threads}), e dallo
671 standard POSIX.1b per quanto riguarda i segnali e lo \itindex{scheduler}
672 scheduling real-time (sez.~\ref{sec:sig_real_time} e
673 sez.~\ref{sec:proc_real_time}), la misura del tempo, i meccanismi di
674 intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O asincrono
675 (sez.~\ref{sec:file_asyncronous_io}).
677 Lo standard principale resta comunque POSIX.1, che continua ad evolversi; la
678 versione più nota, cui gran parte delle implementazioni fanno riferimento, e
679 che costituisce una base per molti altri tentativi di standardizzazione, è
680 stata rilasciata anche come standard internazionale con la sigla
681 \textsl{ISO/IEC 9945-1:1996} ed include i precedenti POSIX.1b e POSIX.1c. In
682 genere si fa riferimento ad essa come POSIX.1-1996.
684 Nel 2001 è stata poi eseguita una sintesi degli standard POSIX.1, POSIX.2 e
685 SUSv3 (vedi sez.~\ref{sec:intro_xopen}) in un unico documento, redatto sotto
686 gli auspici del cosiddetto gruppo Austin che va sotto il nome di POSIX.1-2001.
687 Questo standard definisce due livelli di conformità, quello POSIX, in cui sono
688 presenti solo le interfacce di base, e quello XSI che richiede la presenza di
689 una serie di estensioni opzionali per lo standard POSIX, riprese da SUSv3.
690 Inoltre lo standard è stato allineato allo standard C99, e segue lo stesso
691 nella definizione delle interfacce.
693 A questo standard sono stati aggiunti due documenti di correzione e
694 perfezionamento denominati \textit{Technical Corrigenda}, il TC1 del 2003 ed
695 il TC2 del 2004, e talvolta si fa riferimento agli stessi con le sigle
696 POSIX.1-2003 e POSIX.1-2004.
698 Infine è in corso una ulteriore revisione degli standard POSIX e SUS, che
699 dovrebbe essere completata entro l'anno 2008 e che andrà presumibilmente
700 sotto il nome di POSIX.1-2008. È prevista l'incorporazione di molte interfacce
701 opzionali dentro le specifiche di base, oltre che le solite precisazioni ed
702 aggiornamenti. Anche in questo caso è prevista la suddivisione in una
703 conformità di base, e delle interfacce aggiuntive.
705 % vedi anche man standards
707 \subsection{Gli standard X/Open -- Opengroup -- Unix}
708 \label{sec:intro_xopen}
710 Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi
711 Unix per giungere ad un'armonizzazione delle varie implementazioni. Per far
712 questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il
713 nome di \textit{X/Open Portability Guide} a cui di norma si fa riferimento con
714 l'abbreviazione XPG$n$, con $n$ che indica la versione.
716 Nel 1989 il consorzio produsse una terza versione di questa guida
717 particolarmente voluminosa (la \textit{X/Open Portability Guide, Issue 3}),
718 contenente una dettagliata standardizzazione dell'interfaccia di sistema di
719 Unix, che venne presa come riferimento da vari produttori. Questo standard,
720 detto anche XPG3 dal nome della suddetta guida, è sempre basato sullo standard
721 POSIX.1, ma prevede una serie di funzionalità aggiuntive fra cui le specifiche
722 delle API\footnote{le \textit{Application Programmable Interface}, in sostanze
723 le interfacce di programmazione.} per l'interfaccia grafica (X11).
725 Nel 1992 lo standard venne rivisto con una nuova versione della guida, la
726 Issue 4, da cui la sigla XPG4, che aggiungeva l'interfaccia XTI (\textit{X
727 Transport Interface}) mirante a soppiantare (senza molto successo)
728 l'interfaccia dei socket derivata da BSD. Una seconda versione della guida fu
729 rilasciata nel 1994; questa è nota con il nome di Spec 1170 (dal numero delle
730 interfacce, header e comandi definiti) ma si fa riferimento ad essa anche come
733 Nel 1993 il marchio Unix passò di proprietà dalla Novell (che a sua volta lo
734 aveva comprato dalla AT\&T) al consorzio X/Open che iniziò a pubblicare le sue
735 specifiche sotto il nome di \textit{Single UNIX Specification} o SUS, l'ultima
736 versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX
737 Specification}, detta SUS o SUSv1, ma più comunemente nota anche come
740 Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata
741 da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
742 alla costituzione dell'\textit{Open Group}, un consorzio internazionale che
743 raccoglie produttori, utenti industriali, entità accademiche e governative.
744 Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
745 il lavoro di standardizzazione delle varie implementazioni, rilasciando
746 periodicamente nuove specifiche e strumenti per la verifica della conformità
749 Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
750 Specification}, nota con la sigla SUSv2, in questa versione le interfacce
751 specificate salgono a 1434, e addirittura a 3030 se si considerano le stazioni
752 di lavoro grafiche, per le quali sono inserite pure le interfacce usate da CDE
753 che richiede sia X11 che Motif. La conformità a questa versione permette l'uso
754 del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard. Un
755 altro nome alternativo di queste specifiche, date le origini, è XPG5.
757 Come accennato nel 2001, con il rilascio dello standard POSIX.1-2001, è stato
758 effettuato uno sforzo di sintesi in cui sono state comprese, nella parte di
759 interfacce estese, anche le interfacce definite nelle \textit{Single UNIX
760 Specification}, pertanto si può fare riferimento a detto standard, quando
761 comprensivo del rispetto delle estensioni XSI, come SUSv3, e fregiarsi del
762 marchio UNIX 03 se conformi ad esso.
764 Infine con la prossima revisione dello standard POSIX.1 è previsto che, come
765 avviene per il POSIX.1-2001, la conformità completa a tutte quelle che saranno
766 le nuove estensioni XSI previste dall'aggiornamento andrà a definire la nuova
767 versione delle \textit{Single UNIX Specification} che verranno chiamate SUSv4.
770 \subsection{Il controllo di aderenza agli standard}
771 \label{sec:intro_gcc_glibc_std}
773 In Linux, grazie alle \acr{glibc}, la conformità agli standard appena
774 descritti può essere richiesta sia attraverso l'uso di opportune opzioni del
775 compilatore (il \texttt{gcc}) che definendo delle specifiche costanti prima
776 dell'inclusione dei file di dichiarazione (gli \textit{header file}) che
777 definiscono le funzioni di libreria.
779 Ad esempio se si vuole che i programmi seguano una stretta attinenza allo
780 standard ANSI C si può usare l'opzione \texttt{-ansi} del compilatore, e non
781 potrà essere utilizzata nessuna funzione non riconosciuta dalle specifiche
782 standard ISO per il C. Il \texttt{gcc} possiede inoltre una specifica opzione
783 per richiedere la conformità ad uno standard, nella forma \texttt{-std=nome},
784 dove \texttt{nome} può essere \texttt{c89} per indicare lo standard ANSI C
785 (vedi sez.~\ref{sec:intro_ansiC}) o \texttt{c99} per indicare la conformità
786 allo standard C99.\footnote{che non è al momento completa, esistono anche le
787 possibilità di usare i valori \texttt{gnu89}, l'attuale default, che indica
788 l'uso delle estensioni GNU al C89, riprese poi dal C99, o \texttt{gnu89} che
789 indica il dialetto GNU del C99, che diventerà il default quando la
790 conformità a quest'ultimo sarà completa.}
792 Per attivare le varie opzioni di controllo di aderenza agli standard è poi
793 possibile definire delle macro di preprocessore che controllano le
794 funzionalità che le \acr{glibc} possono mettere a disposizione:\footnote{le
795 macro sono definite nel file di dichiarazione \file{<features.h>}, ma non è
796 necessario includerlo nei propri programmi in quanto viene automaticamente
797 incluso da tutti gli altri file di dichiarazione che utilizzano le macro in
798 esso definite; si tenga conto inoltre che il file definisce anche delle
799 ulteriori macro interne, in genere con un doppio prefisso di \texttt{\_},
800 che non devono assolutamente mai essere usate direttamente. } questo può
801 essere fatto attraverso l'opzione \texttt{-D} del compilatore, ma è buona
802 norma farlo inserendo gli opportuni \code{\#define} prima della inclusione dei
803 propri \textit{header file}.
805 Le macro disponibili per controllare l'aderenza ai vari standard messe a
806 disposizione delle \acr{glibc}, che rendono disponibili soltanto le funzioni
807 in esse definite, sono illustrate nel seguente elenco:
808 \begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
809 \item[\macro{\_\_STRICT\_ANSI\_\_}] richiede l'aderenza stretta allo standard
810 C ISO; viene automaticamente predefinita qualora si invochi il \texttt{gcc}
811 con le opzione \texttt{-ansi} o \texttt{-std=c99}.
813 \item[\macro{\_POSIX\_SOURCE}] definendo questa macro (considerata obsoleta)
814 si rendono disponibili tutte le funzionalità dello standard POSIX.1 (la
815 versione IEEE Standard 1003.1) insieme a tutte le funzionalità dello
816 standard ISO C. Se viene anche definita con un intero positivo la macro
817 \macro{\_POSIX\_C\_SOURCE} lo stato di questa non viene preso in
820 \item[\macro{\_POSIX\_C\_SOURCE}] definendo questa macro ad un valore intero
821 positivo si controlla quale livello delle funzionalità specificate da POSIX
822 viene messa a disposizione; più alto è il valore maggiori sono le
825 \item un valore uguale a ``\texttt{1}'' rende disponibili le funzionalità
826 specificate nella edizione del 1990 (IEEE Standard 1003.1-1990);
827 \item valori maggiori o uguali a ``\texttt{2}'' rendono disponibili le
828 funzionalità previste dallo standard POSIX.2 specificate nell'edizione del
829 1992 (IEEE Standard 1003.2-1992),
830 \item un valore maggiore o uguale a ``\texttt{199309L}'' rende disponibili
831 le funzionalità previste dallo standard POSIX.1b specificate nell'edizione
832 del 1993 (IEEE Standard 1003.1b-1993);
833 \item un valore maggiore o uguale a ``\texttt{199506L}'' rende disponibili
834 le funzionalità previste dallo standard POSIX.1 specificate nell'edizione
835 del 1996 (\textit{ISO/IEC 9945-1:1996}), ed in particolare le definizioni
836 dello standard POSIX.1c per i \itindex{thread} \textit{thread};
837 \item a partire dalla versione 2.3.3 delle \acr{glibc} un valore maggiore o
838 uguale a ``\texttt{200112L}'' rende disponibili le funzionalità di base
839 previste dallo standard POSIX.1-2001, escludendo le estensioni XSI;
840 \item a partire dalla versione 2.10 delle \acr{glibc} un valore maggiore o
841 uguale a ``\texttt{200809L}'' rende disponibili le funzionalità di base
842 previste dallo standard POSIX.1-2008, escludendo le estensioni XSI;
843 \item in futuro valori superiori potranno abilitare ulteriori estensioni.
846 \item[\macro{\_BSD\_SOURCE}] definendo questa macro si rendono disponibili le
847 funzionalità derivate da BSD4.3, insieme a quelle previste dagli standard
848 ISO C, POSIX.1 e POSIX.2; alcune delle funzionalità previste da BSD sono
849 però in conflitto con le corrispondenti definite nello standard POSIX.1, in
850 questo caso se la macro è definita le definizioni previste da BSD4.3 avranno
851 la precedenza rispetto a POSIX.
853 A causa della natura dei conflitti con POSIX per ottenere una piena
854 compatibilità con BSD4.3 può essere necessario anche usare una libreria di
855 compatibilità, dato che alcune funzioni sono definite in modo diverso. In
856 questo caso occorrerà anche usare l'opzione \cmd{-lbsd-compat} con il
857 compilatore per indicargli di utilizzare le versioni nella libreria di
858 compatibilità prima di quelle normali.
860 Si tenga inoltre presente che la preferenza verso le versioni delle funzioni
861 usate da BSD viene mantenuta soltanto se nessuna delle ulteriori macro di
862 specificazione di standard successivi (vale a dire una fra
863 \macro{\_POSIX\_C\_SOURCE}, \macro{\_POSIX\_SOURCE}, \macro{\_SVID\_SOURCE},
864 \macro{\_XOPEN\_SOURCE}, \macro{\_XOPEN\_SOURCE\_EXTENDED} o
865 \macro{\_GNU\_SOURCE}) è stata a sua volta attivata, nel qual caso queste
866 hanno la precedenza. Se però si definisce \macro{\_BSD\_SOURCE} dopo aver
867 definito una di queste macro, l'effetto sarà quello di dare la precedenza
868 alle funzioni in forma BSD.
870 \item[\macro{\_SVID\_SOURCE}] definendo questa macro si rendono disponibili le
871 funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
872 standard ISO C, POSIX.1, POSIX.2, e X/Open (XPG$n$) illustrati in
875 \item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si rendono disponibili
876 le funzionalità descritte nella \textit{X/Open Portability Guide}. Anche
877 queste sono un sovrainsieme di quelle definite negli standard POSIX.1 e
878 POSIX.2 ed in effetti sia \macro{\_POSIX\_SOURCE} che
879 \macro{\_POSIX\_C\_SOURCE} vengono automaticamente definite. Sono incluse
880 anche ulteriori funzionalità disponibili in BSD e SVID, più una serie di
881 estensioni a secondo dei seguenti valori:
883 \item la definizione della macro ad un valore qualunque attiva le
884 funzionalità specificate negli standard POSIX.1, POSIX.2 e XPG4;
885 \item un valore di ``\texttt{500}'' o superiore rende disponibili anche le
886 funzionalità introdotte con SUSv2, vale a dire la conformità ad Unix98;
887 \item a partire dalla versione 2.2 delle \acr{glibc} un valore uguale a
888 ``\texttt{600}'' o superiore rende disponibili anche le funzionalità
889 introdotte con SUSv3, corrispondenti allo standard POSIX.1-2001 più le
891 \item a partire dalla versione 2.10 delle \acr{glibc} un valore uguale a
892 ``\texttt{700}'' o superiore rende disponibili anche le funzionalità
893 introdotte con SUSv4, corrispondenti allo standard POSIX.1-2008 più le
897 \item[\macro{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si rendono
898 disponibili le ulteriori funzionalità necessarie ad essere conformi al
899 rilascio del marchio \textit{X/Open Unix} corrispondenti allo standard
900 Unix95, vale a dire quelle specificate da SUSv1/XPG4v2. Questa macro viene
901 definita implicitamente tutte le volte che si imposta
902 \macro{\_XOPEN\_SOURCE} ad un valore maggiore o uguale a 500.
904 \item[\macro{\_ISOC99\_SOURCE}] definendo questa macro si rendono disponibili
905 le funzionalità previste per la revisione delle librerie standard del C
906 introdotte con lo standard ISO C99. La macro è definita a partire dalla
907 versione 2.1.3 delle \acr{glibc}.
909 Le precedenti versioni della serie 2.1.x riconoscevano le stesse estensioni
910 con la macro \macro{\_ISOC9X\_SOURCE}, dato che lo standard non era stato
911 finalizzato, ma le \acr{glibc} avevano già un'implementazione completa che
912 poteva essere attivata definendo questa macro. Benché questa sia obsoleta
913 viene tuttora riconosciuta come equivalente di \macro{\_ISOC99\_SOURCE} per
916 \item[\macro{\_GNU\_SOURCE}] definendo questa macro si rendono disponibili
917 tutte le funzionalità disponibili nei vari standard oltre a varie estensioni
918 specifiche presenti solo nelle \acr{glibc} ed in Linux. Gli standard coperti
919 sono: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, SUS.
921 L'uso di \macro{\_GNU\_SOURCE} è equivalente alla definizione contemporanea
922 delle macro: \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
923 \macro{\_POSIX\_SOURCE}, \macro{\_ISOC99\_SOURCE}, inoltre
924 \macro{\_POSIX\_C\_SOURCE} con valore ``\texttt{200112L}'' (o
925 ``\texttt{199506L}'' per le versioni delle \acr{glibc} precedenti la 2.5),
926 \macro{\_XOPEN\_SOURCE\_EXTENDED} e \macro{\_XOPEN\_SOURCE} con valore 600
927 (o 500 per le versioni delle \acr{glibc} precedenti la 2.2); oltre a queste
928 vengono pure attivate le ulteriori due macro \macro{\_ATFILE\_SOURCE} e
929 \macro{\_LARGEFILE64\_SOURCE} che definiscono funzioni previste
930 esclusivamente dalle \acr{glibc}.
934 Benché Linux supporti in maniera estensiva gli standard più diffusi, esistono
935 comunque delle estensioni e funzionalità specifiche, non presenti in altri
936 standard e lo stesso vale per le \acr{glibc} stesse, che definiscono anche
937 delle ulteriori funzioni di libreria. Ovviamente l'uso di queste funzionalità
938 deve essere evitato se si ha a cuore la portabilità, ma qualora questo non sia
939 un requisito esse possono rivelarsi molto utili.
941 Come per l'aderenza ai vari standard, le funzionalità aggiuntive possono
942 essere rese esplicitamente disponibili tramite la definizione di opportune
943 macro di preprocessore, alcune di queste vengono attivate con la definizione
944 di \macro{\_GNU\_SOURCE}, mentre altre devono essere attivate esplicitamente,
945 inoltre alcune estensioni possono essere attivate indipendentemente tramite
946 una opportuna macro; queste estensioni sono illustrate nel seguente elenco:
948 \begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
950 \item[\macro{\_LARGEFILE\_SOURCE}] definendo questa macro si rendono
951 disponibili alcune funzioni che consentono di superare una inconsistenza
952 presente negli standard con i file di grandi dimensioni, ed in particolare
953 definire le due funzioni \func{fseeko} e \func{ftello} che al contrario
954 delle corrispettive \func{fseek} e \func{ftell} usano il tipo di dato
955 specifico \ctyp{off\_t} (vedi sez.~\ref{sec:file_fseek}).
957 \item[\macro{\_LARGEFILE64\_SOURCE}] definendo questa macro si rendono
958 disponibili le funzioni di una interfaccia alternativa al supporto di valori
959 a 64 bit nelle funzioni di gestione dei file (non supportati in certi
960 sistemi), caratterizzate dal suffisso \texttt{64} aggiunto ai vari nomi di
961 tipi di dato e funzioni (come \ctyp{off64\_t} al posto di \ctyp{off\_t} o
962 \func{lseek64} al posto di \func{lseek}).
964 Le funzioni di questa interfaccia alternativa sono state proposte come una
965 estensione ad uso di transizione per le \textit{Single UNIX Specification},
966 per consentire la gestione di file di grandi dimensioni anche nei sistemi a
967 32 bit, in cui la dimensione massima, espressa con un intero, non poteva
968 superare i 2Gb. Nei nuovi programmi queste funzioni devono essere evitate,
969 a favore dell'uso macro \macro{\_FILE\_OFFSET\_BITS}, che definita al valore
970 di \texttt{64} consente di usare in maniera trasparente le funzioni
971 dell'interfaccia classica.
973 \item[\macro{\_FILE\_OFFSET\_BITS}] la definizione di questa macro al valore
974 di \texttt{64} consente di attivare la conversione automatica di tutti i
975 riferimenti a dati e funzioni a 32 bit nelle funzioni di interfaccia ai file
976 con le equivalenti a 64 bit, senza dover utilizzare esplicitamente
977 l'interfaccia alternativa appena illustrata. In questo modo diventa
978 possibile usare le ordinarie funzioni per effettuare operazioni a 64 bit sui
979 file anche su sistemi a 32 bit.\footnote{basterà ricompilare il programma
980 dopo averla definita, e saranno usate in modo trasparente le funzioni a 64
983 Se la macro non è definita o è definita con valore \texttt{32} questo
984 comportamento viene disabilitato, e sui sistemi a 32 bit verranno usate le
985 ordinarie funzioni a 32 bit, non avendo più il supporto per file di grandi
986 dimensioni. Su sistemi a 64 bit invece, dove il problema non sussiste, la
987 macro non ha nessun effetto.
989 \item[\macro{\_ATFILE\_SOURCE}] definendo questa macro si rendono disponibili
990 le estensioni delle funzioni di creazione, accesso e modifica di file e
991 directory che risolvono i problemi di sicurezza insiti nell'uso di pathname
992 relativi con programmi \itindex{thread} \textit{multi-thread} illustrate in
993 sez.~\ref{sec:file_openat}.
995 \item[\macro{\_REENTRANT}] definendo questa macro, o la equivalente
996 \macro{\_THREAD\_SAFE} (fornita per compatibilità) si rendono disponibili le
997 versioni \index{funzioni!rientranti} rientranti (vedi
998 sez.~\ref{sec:proc_reentrant}) di alcune funzioni, necessarie quando si
999 usano i \itindex{thread} \textit{thread}. Alcune di queste funzioni sono
1000 anche previste nello standard POSIX.1c, ma ve ne sono altre che sono
1001 disponibili soltanto su alcuni sistemi, o specifiche del \acr{glibc}, e
1002 possono essere utilizzate una volta definita la macro.
1004 \item[\macro{\_FORTIFY\_SOURCE}] definendo questa macro viene abilitata
1005 l'inserimento di alcuni controlli per alcune funzioni di allocazione e
1006 manipolazione di memoria e stringhe che consentono di rilevare
1007 automaticamente alcuni errori di \textit{buffer overflow} nell'uso delle
1008 stesse. La funzionalità è stata introdotta a partire dalla versione 2.3.4
1009 delle \acr{glibc} e richiede anche il supporto da parte del compilatore, che
1010 è disponibile solo a partire dalla versione 4.0 del \texttt{gcc}.
1012 Le funzioni di libreria che vengono messe sotto controllo quando questa
1013 funzionalità viene attivata sono, al momento della stesura di queste note,
1014 le seguenti: \func{memcpy}, \func{mempcpy}, \func{memmove}, \func{memset},
1015 \func{stpcpy}, \func{strcpy}, \func{strncpy}, \func{strcat}, \func{strncat},
1016 \func{sprintf}, \func{snprintf}, \func{vsprintf}, \func{vsnprintf}, e
1019 La macro prevede due valori, con \texttt{1} vengono eseguiti dei controlli
1020 di base che non cambiano il comportamento dei programmi se si richiede una
1021 ottimizzazione di livello uno o superiore,\footnote{vale a dire se si usa
1022 l'opzione \texttt{-O1} o superiore del \texttt{gcc}.} mentre con il
1023 valore \texttt{2} vengono aggiunti maggiori controlli. Dato che alcuni dei
1024 controlli vengono effettuati in fase di compilazione l'uso di questa macro
1025 richiede anche la collaborazione del compilatore, disponibile dalla
1026 versione 4.0 del \texttt{gcc}.
1030 Se non è stata specificata esplicitamente nessuna di queste macro il default
1031 assunto è che siano definite \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE},
1032 \macro{\_POSIX\_SOURCE} e, con le \acr{glibc} più recenti, che la macro
1033 \macro{\_POSIX\_C\_SOURCE} abbia il valore ``\texttt{200809L}'', per versioni
1034 precedenti delle \acr{glibc} il valore assegnato a \macro{\_POSIX\_C\_SOURCE}
1035 era di ``\texttt{200112L}'' prima delle 2.10, di ``\texttt{199506L}'' prima
1036 delle 2.4, di ``\texttt{199506L}'' prima delle 2.1. Si ricordi infine che
1037 perché queste macro abbiano effetto devono essere sempre definite prima
1038 dell'inclusione dei file di dichiarazione.
1041 % vedi anche man feature_test_macros
1043 % LocalWords: like kernel multitasking scheduler preemptive sez swap is cap VM
1044 % LocalWords: everything bootstrap init shell Windows Foundation system call
1045 % LocalWords: fig libc uClib glibc embedded Library POSIX username PAM Methods
1046 % LocalWords: Pluggable Autentication group supplementary Name Service Switch
1047 % LocalWords: LDAP identifier uid gid superuser root if BSD SVr dall' American
1048 % LocalWords: National Institute International Organisation IEC header tab gcc
1049 % LocalWords: assert ctype dirent errno fcntl limits malloc setjmp signal utmp
1050 % LocalWords: stdarg stdio stdlib string times unistd library int short caddr
1051 % LocalWords: address clock dev ino inode key IPC loff nlink off pid rlim size
1052 % LocalWords: sigset ssize ptrdiff sys nell'header IEEE Richard Portable of TR
1053 % LocalWords: Operating Interface dell'IEEE Electrical and Electronics thread
1054 % LocalWords: Engeneers Socket NT matching regular expression scheduling l'I
1055 % LocalWords: XPG Portability Issue Application Programmable XTI Transport AT
1056 % LocalWords: socket Spec Novell Specification SUSv CDE Motif Berkley select
1057 % LocalWords: SunOS l'AT Sun HP Xenix Description SVID Laboratories MP hsearch
1058 % LocalWords: drand fmtmsg define SOURCE lbsd compat XOPEN version ISOC Large
1059 % LocalWords: LARGEFILE Support LFS dell' black rectangle node fill cpu draw
1060 % LocalWords: ellipse mem anchor west proc SysV SV Definition SCO Austin XSI
1061 % LocalWords: Technical TC SUS Opengroup features STRICT std ATFILE fseeko
1062 % LocalWords: ftello fseek ftell lseek FORTIFY REENTRANT SAFE overflow memcpy
1063 % LocalWords: mempcpy memmove memset stpcpy strcpy strncpy strcat strncat gets
1064 % LocalWords: sprintf snprintf vsprintf vsnprintf syscall number calendar BITS
1066 %%% Local Variables:
1068 %%% TeX-master: "gapil"
1070 % LocalWords: pathname