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