GaPiL - Guida alla Programmazione in Linux

GaPiL
Guida alla Programmazione in Linux
Simone Piccardi
13 dicembre 2011

ii
Copyright c 2000-2009 Simone Piccardi. Permission is granted to copy, distribute
and/or modify this document under the terms of the GNU Free Documentation
License, Version 1.1 or any later version published by the Free Software Foundation;
with the Invariant Sections being “Un preambolo” in “Prefazione”, with no Front-
Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the
section entitled “GNU Free Documentation License”.

Indice
Un preambolo xiii
Prefazione xv
I Programmazione di sistema 1
1 L’architettura del sistema 3
1.1 Una panoramica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Concetti base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Il kernel e il sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Chiamate al sistema e librerie di funzioni . . . . . . . . . . . . . . . . . . 5
1.1.4 Un sistema multiutente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Gli standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Lo standard ANSI C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 I tipi di dati primitivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.3 Lo standard System V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.4 Lo “standard” BSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.5 Gli standard IEEE – POSIX . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.6 Gli standard X/Open – Opengroup – Unix . . . . . . . . . . . . . . . . . 12
1.2.7 Il controllo di aderenza agli standard . . . . . . . . . . . . . . . . . . . . . 13
2 L’interfaccia base con i processi 19
2.1 Esecuzione e conclusione di un programma . . . . . . . . . . . . . . . . . . . . . 19
2.1.1 La funzione main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.2 Come chiudere un programma . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.3 Le funzioni exit e _exit . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.4 Le funzioni atexit e on_exit . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.5 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 I processi e l’uso della memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1 I concetti generali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 La struttura della memoria di un processo . . . . . . . . . . . . . . . . . . 23
2.2.3 Allocazione della memoria per i programmi C . . . . . . . . . . . . . . . . 25
2.2.4 Il controllo della memoria virtuale . . . . . . . . . . . . . . . . . . . . . . 29
2.2.5 Gestione avanzata dell’allocazione della memoria . . . . . . . . . . . . . . 32
2.3 Argomenti, ambiente ed altre propriet`a di un processo . . . . . . . . . . . . . . . 34
2.3.1 Il formato degli argomenti . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.2 La gestione delle opzioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.3 Le variabili di ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.4 La localizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
iii

iv INDICE
2.4 Problematiche di programmazione generica . . . . . . . . . . . . . . . . . . . . . 40
2.4.1 Il passaggio delle variabili e dei valori di ritorno . . . . . . . . . . . . . . . 40
2.4.2 Il passaggio di un numero variabile di argomenti . . . . . . . . . . . . . . 41
2.4.3 Potenziali problemi con le variabili automatiche . . . . . . . . . . . . . . . 43
2.4.4 Il controllo di flusso non locale . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4.5 La endianess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3 La gestione dei processi 47
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.1 L’architettura della gestione dei processi . . . . . . . . . . . . . . . . . . . 47
3.1.2 Una panoramica sulle funzioni fondamentali . . . . . . . . . . . . . . . . . 49
3.2 Le funzioni di base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.1 Gli identificatori dei processi . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.2 La funzione fork e le funzioni di creazione dei processi . . . . . . . . . . . 51
3.2.3 La conclusione di un processo . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.4 Le funzioni di attesa e ricezione degli stati di uscita . . . . . . . . . . . . 59
3.2.5 La funzione exec e le funzioni di esecuzione dei programmi . . . . . . . . 64
3.3 Il controllo di accesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.3.1 Gli identificatori del controllo di accesso . . . . . . . . . . . . . . . . . . . 68
3.3.2 Le funzioni di gestione degli identificatori dei processi . . . . . . . . . . . 70
3.3.3 Le funzioni per la gestione dei gruppi associati a un processo . . . . . . . 73
3.4 La gestione della priorità dei processi . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.4.1 I meccanismi di scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.4.2 Il meccanismo di scheduling standard . . . . . . . . . . . . . . . . . . . . 76
3.4.3 Il meccanismo di scheduling real-time . . . . . . . . . . . . . . . . . . . . 79
3.4.4 Il controllo dello scheduler per i sistemi multiprocessore . . . . . . . . . . 83
3.4.5 Le priorità per le operazioni di I/O . . . . . . . . . . . . . . . . . . . . . . 85
3.5 Funzioni di gestione avanzata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.5.1 La system call clone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.5.2 La funzione prctl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.5.3 La funzione ptrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.5.4 L’accesso alle porte di I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.6 Problematiche di programmazione multitasking . . . . . . . . . . . . . . . . . . . 94
3.6.1 Le operazioni atomiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.6.2 Le race condition ed i deadlock . . . . . . . . . . . . . . . . . . . . . . . . 95
3.6.3 Le funzioni rientranti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4 L’architettura dei file 97
4.1 L’architettura generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.1.1 L’organizzazione di file e directory . . . . . . . . . . . . . . . . . . . . . . 97
4.1.2 I tipi di file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.1.3 Le due interfacce ai file . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.2 L’architettura della gestione dei file . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.2.1 Il Virtual File System di Linux . . . . . . . . . . . . . . . . . . . . . . . . 100
4.2.2 Il funzionamento del Virtual File System . . . . . . . . . . . . . . . . . . 102
4.2.3 Il funzionamento di un filesystem Unix . . . . . . . . . . . . . . . . . . . . 103
4.2.4 I filesystem di uso comune . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

INDICE v
5 File e directory 109
5.1 La gestione di file e directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.1.1 Le funzioni link e unlink . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.1.2 Le funzioni remove e rename . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.1.3 I link simbolici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.1.4 La creazione e la cancellazione delle directory . . . . . . . . . . . . . . . . 116
5.1.5 La creazione di file speciali . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.1.6 Accesso alle directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.1.7 La directory di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.1.8 I file temporanei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.2 La manipolazione delle caratteristiche dei file . . . . . . . . . . . . . . . . . . . . 129
5.2.1 La lettura delle caratteristiche dei file . . . . . . . . . . . . . . . . . . . . 130
5.2.2 I tipi di file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.2.3 Le dimensioni dei file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.2.4 I tempi dei file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.3 Il controllo di accesso ai file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.3.1 I permessi per l’accesso ai file . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.3.2 I bit dei permessi speciali . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.3.3 Le funzioni per la gestione dei permessi dei file . . . . . . . . . . . . . . . 141
5.3.4 La gestione della titolarità dei file . . . . . . . . . . . . . . . . . . . . . . 144
5.3.5 Un quadro d’insieme sui permessi . . . . . . . . . . . . . . . . . . . . . . . 145
5.4 Caratteristiche e funzionalità avanzate . . . . . . . . . . . . . . . . . . . . . . . . 146
5.4.1 Gli attributi estesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.4.2 Le Access Control List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.4.3 La gestione delle quote disco . . . . . . . . . . . . . . . . . . . . . . . . . 160
5.4.4 La gestione delle capabilities . . . . . . . . . . . . . . . . . . . . . . . . . 165
5.4.5 La funzione chroot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
6 I file: l’interfaccia standard Unix 181
6.1 L’architettura di base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.1.1 L’architettura dei file descriptor . . . . . . . . . . . . . . . . . . . . . . . 181
6.1.2 I file standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
6.2 Le funzioni base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.2.1 La funzione open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.2.2 La funzione close . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.2.3 La funzione lseek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.2.4 Le funzioni read e pread . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.2.5 Le funzioni write e pwrite . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.3 Caratteristiche avanzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
6.3.1 La condivisione dei files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
6.3.2 Operazioni atomiche con i file . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.3.3 Le funzioni sync e fsync . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.3.4 Le funzioni dup e dup2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
6.3.5 Le funzioni openat, mkdirat e affini . . . . . . . . . . . . . . . . . . . . . 195
6.3.6 La funzione fcntl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
6.3.7 La funzione ioctl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

vi INDICE
7 I file: l’interfaccia standard ANSI C 203
7.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
7.1.1 I file stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
7.1.2 Gli oggetti FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
7.1.3 Gli stream standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
7.1.4 Le modalità di bufferizzazione . . . . . . . . . . . . . . . . . . . . . . . . . 204
7.2 Funzioni base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
7.2.1 Apertura e chiusura di uno stream . . . . . . . . . . . . . . . . . . . . . . 206
7.2.2 Lettura e scrittura su uno stream . . . . . . . . . . . . . . . . . . . . . . . 208
7.2.3 Input/output binario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
7.2.4 Input/output a caratteri . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
7.2.5 Input/output di linea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
7.2.6 L’input/output formattato . . . . . . . . . . . . . . . . . . . . . . . . . . 214
7.2.7 Posizionamento su uno stream . . . . . . . . . . . . . . . . . . . . . . . . 218
7.3 Funzioni avanzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
7.3.1 Le funzioni di controllo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
7.3.2 Il controllo della bufferizzazione . . . . . . . . . . . . . . . . . . . . . . . . 220
7.3.3 Gli stream e i thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
8 La gestione del sistema, del tempo e degli errori 225
8.1 Capacità e caratteristiche del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 225
8.1.1 Limiti e parametri di sistema . . . . . . . . . . . . . . . . . . . . . . . . . 225
8.1.2 La funzione sysconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
8.1.3 I limiti dei file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
8.1.4 La funzione pathconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
8.1.5 La funzione uname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
8.2 Opzioni e configurazione del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 231
8.2.1 La funzione sysctl ed il filesystem /proc . . . . . . . . . . . . . . . . . . 231
8.2.2 La gestione delle proprietà dei filesystem . . . . . . . . . . . . . . . . . . . 233
8.2.3 La gestione delle informazioni su utenti e gruppi . . . . . . . . . . . . . . 236
8.2.4 Il registro della contabilità degli utenti . . . . . . . . . . . . . . . . . . . . 239
8.3 Il controllo dell’uso delle risorse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
8.3.1 L’uso delle risorse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
8.3.2 Limiti sulle risorse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
8.3.3 Le risorse di memoria e processore . . . . . . . . . . . . . . . . . . . . . . 244
8.3.4 La contabilità in stile BSD . . . . . . . . . . . . . . . . . . . . . . . . . . 246
8.4 La gestione dei tempi del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
8.4.1 La misura del tempo in Unix . . . . . . . . . . . . . . . . . . . . . . . . . 247
8.4.2 La gestione del process time . . . . . . . . . . . . . . . . . . . . . . . . . . 248
8.4.3 Le funzioni per il calendar time . . . . . . . . . . . . . . . . . . . . . . . . 249
8.4.4 La gestione delle date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
8.5 La gestione degli errori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
8.5.1 La variabile errno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
8.5.2 Le funzioni strerror e perror . . . . . . . . . . . . . . . . . . . . . . . . 255
8.5.3 Alcune estensioni GNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
9 I segnali 259
9.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
9.1.1 I concetti base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
9.1.2 Le semantiche del funzionamento dei segnali . . . . . . . . . . . . . . . . 260
9.1.3 Tipi di segnali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

INDICE vii
9.1.4 La notifica dei segnali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
9.2 La classificazione dei segnali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
9.2.1 I segnali standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
9.2.2 Segnali di errore di programma . . . . . . . . . . . . . . . . . . . . . . . . 263
9.2.3 I segnali di terminazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
9.2.4 I segnali di allarme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
9.2.5 I segnali di I/O asincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
9.2.6 I segnali per il controllo di sessione . . . . . . . . . . . . . . . . . . . . . . 267
9.2.7 I segnali di operazioni errate . . . . . . . . . . . . . . . . . . . . . . . . . 267
9.2.8 Ulteriori segnali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
9.2.9 Le funzioni strsignal e psignal . . . . . . . . . . . . . . . . . . . . . . . 268
9.3 La gestione di base dei segnali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
9.3.1 Il comportamento generale del sistema . . . . . . . . . . . . . . . . . . . . 269
9.3.2 La funzione signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
9.3.3 Le funzioni kill e raise . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
9.3.4 Le funzioni alarm, abort ed i timer . . . . . . . . . . . . . . . . . . . . . 273
9.3.5 Le funzioni di pausa e attesa . . . . . . . . . . . . . . . . . . . . . . . . . 276
9.3.6 Un esempio elementare . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
9.4 La gestione avanzata dei segnali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
9.4.1 Alcune problematiche aperte . . . . . . . . . . . . . . . . . . . . . . . . . 279
9.4.2 Gli insiemi di segnali o signal set . . . . . . . . . . . . . . . . . . . . . . . 281
9.4.3 La funzione sigaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
9.4.4 La gestione della maschera dei segnali o signal mask . . . . . . . . . . . . 287
9.4.5 Criteri di programmazione per i gestori dei segnali . . . . . . . . . . . . . 289
9.5 Funzionalità avanzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
9.5.1 I segnali real-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
9.5.2 La gestione avanzata delle temporizzazioni . . . . . . . . . . . . . . . . . 294
9.5.3 Ulteriori funzioni di gestione . . . . . . . . . . . . . . . . . . . . . . . . . 301
10 Interfaccia utente: terminali e sessioni di lavoro 305
10.1 L’interazione con i terminali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
10.1.1 Il job control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
10.1.2 I process group e le sessioni . . . . . . . . . . . . . . . . . . . . . . . . . . 306
10.1.3 Il terminale di controllo e il controllo di sessione . . . . . . . . . . . . . . 309
10.1.4 Dal login alla shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
10.1.5 Interazione senza terminale: i demoni ed il syslog . . . . . . . . . . . . . . 313
10.2 L’I/O su terminale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
10.2.1 L’architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
10.2.2 La gestione delle caratteristiche di un terminale . . . . . . . . . . . . . . . 321
10.2.3 La gestione della disciplina di linea. . . . . . . . . . . . . . . . . . . . . . 332
10.2.4 Operare in modo non canonico . . . . . . . . . . . . . . . . . . . . . . . . 333
10.3 La gestione dei terminali virtuali . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
10.3.1 I terminali virtuali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
10.3.2 Allocazione dei terminali virtuali . . . . . . . . . . . . . . . . . . . . . . . 334
11 L’intercomunicazione fra processi 335
11.1 L’intercomunicazione fra processi tradizionale . . . . . . . . . . . . . . . . . . . . 335
11.1.1 Le pipe standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
11.1.2 Un esempio dell’uso delle pipe . . . . . . . . . . . . . . . . . . . . . . . . 337
11.1.3 Le funzioni popen e pclose . . . . . . . . . . . . . . . . . . . . . . . . . . 339
11.1.4 Le pipe con nome, o fifo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

viii INDICE
11.1.5 La funzione socketpair . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
11.2 L’intercomunicazione fra processi di System V . . . . . . . . . . . . . . . . . . . . 348
11.2.1 Considerazioni generali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
11.2.2 Il controllo di accesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
11.2.3 Gli identificatori ed il loro utilizzo . . . . . . . . . . . . . . . . . . . . . . 351
11.2.4 Code di messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
11.2.5 Semafori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
11.2.6 Memoria condivisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
11.3 Tecniche alternative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
11.3.1 Alternative alle code di messaggi . . . . . . . . . . . . . . . . . . . . . . . 383
11.3.2 I file di lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
11.3.3 La sincronizzazione con il file locking . . . . . . . . . . . . . . . . . . . . . 385
11.3.4 Il memory mapping anonimo . . . . . . . . . . . . . . . . . . . . . . . . . 387
11.4 L’intercomunicazione fra processi di POSIX . . . . . . . . . . . . . . . . . . . . . 387
11.4.1 Considerazioni generali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
11.4.2 Code di messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
11.4.3 Memoria condivisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
11.4.4 Semafori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
12 La gestione avanzata dei file 407
12.1 Il file locking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
12.1.1 L’advisory locking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
12.1.2 La funzione flock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
12.1.3 Il file locking POSIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
12.1.4 La funzione lockf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
12.1.5 Il mandatory locking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
12.2 L’I/O multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
12.2.1 La problematica dell’I/O multiplexing . . . . . . . . . . . . . . . . . . . . 419
12.2.2 Le funzioni select e pselect . . . . . . . . . . . . . . . . . . . . . . . . . 420
12.2.3 Le funzioni poll e ppoll . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
12.2.4 L’interfaccia di epoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
12.2.5 La notifica di eventi tramite file descriptor . . . . . . . . . . . . . . . . . . 431
12.3 L’accesso asincrono ai file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
12.3.1 Il Signal driven I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
12.3.2 I meccanismi di notifica asincrona. . . . . . . . . . . . . . . . . . . . . . . 441
12.3.3 L’interfaccia POSIX per l’I/O asincrono . . . . . . . . . . . . . . . . . . . 451
12.4 Altre modalità di I/O avanzato . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
12.4.1 File mappati in memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
12.4.2 I/O vettorizzato: readv e writev . . . . . . . . . . . . . . . . . . . . . . . 464
12.4.3 L’I/O diretto fra file descriptor: sendfile e splice . . . . . . . . . . . . 466
12.4.4 Gestione avanzata dell’accesso ai dati dei file . . . . . . . . . . . . . . . . 475
13 I thread 479
13.1 Introduzione ai thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
13.1.1 Una panoramica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
13.1.2 I thread e Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
13.1.3 Implementazioni alternative . . . . . . . . . . . . . . . . . . . . . . . . . . 479
13.2 Posix thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
13.2.1 Una panoramica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
13.2.2 La gestione dei thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
13.2.3 I mutex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480

INDICE ix
13.2.4 Le variabili di condizione . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
II Programmazione di rete 481
14 Introduzione alla programmazione di rete 483
14.1 Modelli di programmazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
14.1.1 Il modello client-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
14.1.2 Il modello peer-to-peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
14.1.3 Il modello three-tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
14.2 I protocolli di rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
14.2.1 Il modello ISO/OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
14.2.2 Il modello TCP/IP (o DoD) . . . . . . . . . . . . . . . . . . . . . . . . . . 486
14.2.3 Criteri generali dell’architettura del TCP/IP . . . . . . . . . . . . . . . . 488
14.3 Il protocollo TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
14.3.1 Il quadro generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
14.3.2 Internet Protocol (IP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
14.3.3 User Datagram Protocol (UDP) . . . . . . . . . . . . . . . . . . . . . . . 492
14.3.4 Transport Control Protocol (TCP) . . . . . . . . . . . . . . . . . . . . . . 492
14.3.5 Limiti e dimensioni riguardanti la trasmissione dei dati . . . . . . . . . . 493
15 Introduzione ai socket 497
15.1 Una panoramica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
15.1.1 I socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
15.1.2 Concetti base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
15.2 La creazione di un socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
15.2.1 La funzione socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
15.2.2 Il dominio dei socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
15.2.3 Il tipo di socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
15.3 Le strutture degli indirizzi dei socket . . . . . . . . . . . . . . . . . . . . . . . . . 501
15.3.1 La struttura generica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
15.3.2 La struttura degli indirizzi IPv4 . . . . . . . . . . . . . . . . . . . . . . . 502
15.3.3 La struttura degli indirizzi IPv6 . . . . . . . . . . . . . . . . . . . . . . . 503
15.3.4 La struttura degli indirizzi locali . . . . . . . . . . . . . . . . . . . . . . . 504
15.3.5 La struttura degli indirizzi AppleTalk . . . . . . . . . . . . . . . . . . . . 504
15.3.6 La struttura degli indirizzi dei packet socket . . . . . . . . . . . . . . . . . 505
15.4 Le funzioni di conversione degli indirizzi . . . . . . . . . . . . . . . . . . . . . . . 506
15.4.1 Le funzioni per il riordinamento . . . . . . . . . . . . . . . . . . . . . . . 506
15.4.2 Le funzioni inet_aton, inet_addr e inet_ntoa . . . . . . . . . . . . . . 507
15.4.3 Le funzioni inet_pton e inet_ntop . . . . . . . . . . . . . . . . . . . . . 508
16 I socket TCP 509
16.1 Il funzionamento di una connessione TCP . . . . . . . . . . . . . . . . . . . . . . 509
16.1.1 La creazione della connessione: il three way handshake . . . . . . . . . . . 509
16.1.2 Le opzioni TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
16.1.3 La terminazione della connessione . . . . . . . . . . . . . . . . . . . . . . 511
16.1.4 Un esempio di connessione . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
16.1.5 Lo stato TIME_WAIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
16.1.6 I numeri di porta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
16.1.7 Le porte ed il modello client/server . . . . . . . . . . . . . . . . . . . . . . 517
16.2 Le funzioni di base per la gestione dei socket . . . . . . . . . . . . . . . . . . . . 518

x INDICE
16.2.1 La funzione bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
16.2.2 La funzione connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
16.2.3 La funzione listen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
16.2.4 La funzione accept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
16.2.5 Le funzioni getsockname e getpeername . . . . . . . . . . . . . . . . . . . 524
16.2.6 La funzione close . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
16.3 Un esempio elementare: il servizio daytime . . . . . . . . . . . . . . . . . . . . . . 526
16.3.1 Il comportamento delle funzioni di I/O . . . . . . . . . . . . . . . . . . . . 526
16.3.2 Il client daytime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
16.3.3 Un server daytime iterativo . . . . . . . . . . . . . . . . . . . . . . . . . . 530
16.3.4 Un server daytime concorrente . . . . . . . . . . . . . . . . . . . . . . . . 532
16.4 Un esempio più completo: il servizio echo . . . . . . . . . . . . . . . . . . . . . . 534
16.4.1 Il servizio echo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
16.4.2 Il client echo: prima versione . . . . . . . . . . . . . . . . . . . . . . . . . 535
16.4.3 Il server echo: prima versione . . . . . . . . . . . . . . . . . . . . . . . . . 536
16.4.4 L’avvio e il funzionamento normale . . . . . . . . . . . . . . . . . . . . . . 539
16.4.5 La conclusione normale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
16.4.6 La gestione dei processi figli . . . . . . . . . . . . . . . . . . . . . . . . . . 541
16.5 I vari scenari critici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
16.5.1 La terminazione precoce della connessione . . . . . . . . . . . . . . . . . . 545
16.5.2 La terminazione precoce del server . . . . . . . . . . . . . . . . . . . . . . 546
16.5.3 Altri scenari di terminazione della connessione . . . . . . . . . . . . . . . 550
16.6 L’uso dell’I/O multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
16.6.1 Il comportamento della funzione select con i socket. . . . . . . . . . . . 553
16.6.2 Un esempio di I/O multiplexing . . . . . . . . . . . . . . . . . . . . . . . 554
16.6.3 La funzione shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
16.6.4 Un server basato sull’I/O multiplexing . . . . . . . . . . . . . . . . . . . . 561
16.6.5 I/O multiplexing con poll . . . . . . . . . . . . . . . . . . . . . . . . . . 564
16.6.6 I/O multiplexing con epoll . . . . . . . . . . . . . . . . . . . . . . . . . . 567
17 La gestione dei socket 569
17.1 La risoluzione dei nomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
17.1.1 La struttura del resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
17.1.2 Le funzioni di interrogazione del resolver . . . . . . . . . . . . . . . . . . 571
17.1.3 La risoluzione dei nomi a dominio . . . . . . . . . . . . . . . . . . . . . . 577
17.1.4 Le funzioni avanzate per la risoluzione dei nomi . . . . . . . . . . . . . . . 584
17.2 Le opzioni dei socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
17.2.1 Le funzioni setsockopt e getsockopt . . . . . . . . . . . . . . . . . . . . 595
17.2.2 Le opzioni generiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
17.2.3 L’uso delle principali opzioni dei socket . . . . . . . . . . . . . . . . . . . 601
17.2.4 Le opzioni per il protocollo IPv4 . . . . . . . . . . . . . . . . . . . . . . . 607
17.2.5 Le opzioni per i protocolli TCP e UDP . . . . . . . . . . . . . . . . . . . 611
17.3 La gestione attraverso le funzioni di controllo . . . . . . . . . . . . . . . . . . . . 618
17.3.1 L’uso di ioctl e fcntl per i socket generici . . . . . . . . . . . . . . . . . 618
17.3.2 L’uso di ioctl per l’accesso ai dispositivi di rete . . . . . . . . . . . . . . 619
17.3.3 L’uso di ioctl per i socket TCP e UDP . . . . . . . . . . . . . . . . . . . 624
17.4 La gestione con sysctl ed il filesystem /proc . . . . . . . . . . . . . . . . . . . . 624
17.4.1 L’uso di sysctl e /proc per le proprietà della rete . . . . . . . . . . . . . 625
17.4.2 I valori di controllo per i socket generici . . . . . . . . . . . . . . . . . . . 625
17.4.3 I valori di controllo per il protocollo IPv4 . . . . . . . . . . . . . . . . . . 627

INDICE xi
18 Gli altri tipi di socket 635
18.1 I socket UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
18.1.1 Le caratteristiche di un socket UDP . . . . . . . . . . . . . . . . . . . . . 635
18.1.2 Le funzioni sendto e recvfrom . . . . . . . . . . . . . . . . . . . . . . . . 636
18.1.3 Un client UDP elementare . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
18.1.4 Un server UDP elementare . . . . . . . . . . . . . . . . . . . . . . . . . . 641
18.1.5 Le problematiche dei socket UDP . . . . . . . . . . . . . . . . . . . . . . . 642
18.1.6 L’uso della funzione connect con i socket UDP . . . . . . . . . . . . . . . 646
18.2 I socket Unix domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
18.2.1 Il passaggio di file descriptor . . . . . . . . . . . . . . . . . . . . . . . . . 647
18.3 Altri socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
18.3.1 I socket raw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
18.3.2 I socket netlink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
18.3.3 I packet socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
19 Socket avanzati 649
19.1 Le funzioni di I/O avanzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
19.1.1 La funzioni sendmsg e recvmsg . . . . . . . . . . . . . . . . . . . . . . . . 649
19.1.2 I messaggi ancillari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
19.1.3 I dati urgenti o out-of-band . . . . . . . . . . . . . . . . . . . . . . . . . . 650
19.2 L’uso dell’I/O non bloccante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
19.2.1 La gestione delle opzioni IP . . . . . . . . . . . . . . . . . . . . . . . . . . 650
III Appendici 651
A Il livello di rete 653
A.1 Il protocollo IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
A.1.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
A.1.2 L’intestazione di IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
A.1.3 Le opzioni di IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
A.2 Il protocollo IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
A.2.1 I motivi della transizione . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
A.2.2 Principali caratteristiche di IPv6 . . . . . . . . . . . . . . . . . . . . . . . 657
A.2.3 L’intestazione di IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
A.2.4 Gli indirizzi di IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
A.2.5 La notazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
A.2.6 La architettura degli indirizzi di IPv6 . . . . . . . . . . . . . . . . . . . . 660
A.2.7 Indirizzi unicast provider-based . . . . . . . . . . . . . . . . . . . . . . . . 661
A.2.8 Indirizzi ad uso locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
A.2.9 Indirizzi riservati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
A.2.10 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
A.2.11 Indirizzi anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
A.2.12 Le estensioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
A.2.13 Qualità di servizio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
A.2.14 Etichette di flusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
A.2.15 Priorità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
A.2.16 Sicurezza a livello IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
A.2.17 Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
A.2.18 Riservatezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
A.2.19 Auto-configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669

xii INDICE
A.2.20 Auto-configurazione stateless . . . . . . . . . . . . . . . . . . . . . . . . . 670
A.2.21 Auto-configurazione stateful . . . . . . . . . . . . . . . . . . . . . . . . . . 670
A.3 Il protocollo ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
A.3.1 L’intestazione di ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
B Il livello di trasporto 673
B.1 Il protocollo TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
B.1.1 Gli stati del TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
B.2 Il protocollo UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
C I codici di errore 675
C.1 Gli errori dei file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
C.2 Gli errori dei processi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
C.3 Gli errori di rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
C.4 Errori generici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
D Gli strumenti di ausilio per la programmazione 683
D.1 L’uso di make per l’automazione della compilazione . . . . . . . . . . . . . . . . . 683
D.1.1 Introduzione a make . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
D.1.2 Utilizzo di make . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
D.2 Source Control Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
D.2.1 Introduzione a Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
D.2.2 Utilizzo di svn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
E Ringraziamenti 691
F GNU Free Documentation License 693
F.1 Applicability and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
F.2 Verbatim Copying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
F.3 Copying in Quantity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
F.4 Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
F.5 Combining Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
F.6 Collections of Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
F.7 Aggregation With Independent Works . . . . . . . . . . . . . . . . . . . . . . . . 697
F.8 Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
F.9 Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
F.10 Future Revisions of This License . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

Un preambolo
Questa guida nasce dalla mia profonda convinzione che le istanze di libertà e di condivisione
della conoscenza che hanno dato vita a quello straordinario movimento di persone ed intelligenza
che va sotto il nome di software libero hanno la stessa rilevanza anche quando applicate alla
produzione culturale in genere.
L’ambito più comune in cui questa filosofia viene applicata è quello della documentazione
perché il software, per quanto possa essere libero, se non accompagnato da una buona docu-
mentazione che aiuti a comprenderne il funzionamento, rischia di essere fortemente deficitario
riguardo ad una delle libertà fondamentali, quella di essere studiato e migliorato.
Ritengo inoltre che in campo tecnico ed educativo sia importante poter disporre di testi
didattici (come manuali, enciclopedie, dizionari, ecc.) in grado di crescere, essere adattati alle
diverse esigenze, modificati e ampliati, o anche ridotti per usi specifici, nello stesso modo in cui
si fa per il software libero.
Questa guida è il mio tentativo di restituire indietro, nei limiti di quelle che sono le mie
capacità, un po’ della conoscenza che ho ricevuto, mettendo a disposizione un testo che possa
fare da riferimento a chi si avvicina alla programmazione su Linux, nella speranza anche di
trasmettergli non solo delle conoscenze tecniche, ma anche un po’ di quella passione per la
libertà e la condivisione della conoscenza che sono la ricchezza maggiore che ho ricevuto.
E, come per il software libero, anche in questo caso è importante la possibilità di accedere ai
sorgenti (e non solo al risultato finale, sia questo una stampa o un file formattato) e la libertà
di modificarli per apportarvi migliorie, aggiornamenti, ecc.
Per questo motivo la Free Software Foundation ha creato una apposita licenza che potesse
giocare lo stesso ruolo fondamentale che la GPL ha avuto per il software libero nel garantire la
permanenza delle libertà date, ma potesse anche tenere conto delle differenze che comunque ci
sono fra un testo ed un programma.
Una di queste differenze è che in un testo, come in questa sezione, possono venire espresse
quelle che sono le idee ed i punti di vista dell’autore, e mentre trovo che sia necessario permettere
cambiamenti nei contenuti tecnici, che devono essere aggiornati e corretti, non vale lo stesso per
l’espressione delle mie idee contenuta in questa sezione, che ho richiesto resti invariata.
Il progetto pertanto prevede il rilascio della guida con licenza GNU FDL, ed una modalità
di realizzazione aperta che permetta di accogliere i contributi di chiunque sia interessato. Tutti
i programmi di esempio sono rilasciati con licenza GNU GPL.
xiii

Prefazione
Questo progetto mira alla stesura di un testo il più completo e chiaro possibile sulla programma-
zione di sistema su un kernel Linux. Essendo i concetti in gran parte gli stessi, il testo dovrebbe
restare valido anche per la programmazione in ambito di sistemi Unix generici, ma resta una
attenzione specifica alle caratteristiche peculiari del kernel Linux e delle versioni delle librerie
del C in uso con esso; in particolare si darà ampio spazio alla versione realizzata dal progetto
GNU, le cosiddette GNU C Library o glibc, che ormai sono usate nella stragrande maggioranza
dei casi, senza tralasciare, là dove note, le differenze con altre implementazioni come le libc5 o
le uclib.
L’obiettivo finale di questo progetto è quello di riuscire a ottenere un testo utilizzabile per
apprendere i concetti fondamentali della programmazione di sistema della stessa qualità dei libri
del compianto R. W. Stevens (è un progetto molto ambizioso ...).
Infatti benché le pagine di manuale del sistema (quelle che si accedono con il comando man)
e il manuale delle librerie del C GNU siano una fonte inesauribile di informazioni (da cui si
è costantemente attinto nella stesura di tutto il testo) la loro struttura li rende totalmente
inadatti ad una trattazione che vada oltre la descrizione delle caratteristiche particolari dello
specifico argomento in esame (ed in particolare lo GNU C Library Reference Manual non brilla
per chiarezza espositiva).
Per questo motivo si è cercato di fare tesoro di quanto appreso dai testi di R. W. Stevens (in
particolare [1] e [2]) per rendere la trattazione dei vari argomenti in una sequenza logica il più
esplicativa possibile, corredando il tutto, quando possibile, con programmi di esempio.
Dato che sia il kernel che tutte le librerie fondamentali di GNU/Linux sono scritte in C, questo
sarà il linguaggio di riferimento del testo. In particolare il compilatore usato per provare tutti i
programmi e gli esempi descritti nel testo è lo GNU GCC. Il testo presuppone una conoscenza
media del linguaggio, e di quanto necessario per scrivere, compilare ed eseguire un programma.
Infine, dato che lo scopo del progetto è la produzione di un libro, si è scelto di usare LATEX
come ambiente di sviluppo del medesimo, sia per l’impareggiabile qualità tipografica ottenibile,
che per la congruenza dello strumento con il fine, tanto sul piano pratico, quanto su quello
filosofico.
Il testo sarà, almeno inizialmente, in italiano. Per il momento lo si è suddiviso in due parti,
la prima sulla programmazione di sistema, in cui si trattano le varie funzionalità disponibili per i
programmi che devono essere eseguiti su una singola macchina, la seconda sulla programmazione
di rete, in cui si trattano le funzionalità per eseguire programmi che mettono in comunicazione
macchine diverse.
xv

GaPiL - Guida alla Programmazione in Linux

Parte I
Programmazione di sistema
1

Capitolo 1
L’architettura del sistema
In questo primo capitolo sarà fatta un’introduzione ai concetti generali su cui è basato un
sistema operativo di tipo Unix come GNU/Linux, in questo modo potremo fornire una base di
comprensione mirata a sottolineare le peculiarità del sistema che sono più rilevanti per quello
che riguarda la programmazione.
Dopo un’introduzione sulle caratteristiche principali di un sistema di tipo Unix passeremo ad
illustrare alcuni dei concetti base dell’architettura di GNU/Linux (che sono comunque comuni
a tutti i sistemi unix-like) ed introdurremo alcuni degli standard principali a cui viene fatto
riferimento.
1.1 Una panoramica
In questa prima sezione faremo una breve panoramica sull’architettura di un sistema tipo Unix
come GNU/Linux, e della relazione fra le varie parti che lo compongono. Chi avesse già una
conoscenza di questa materia può tranquillamente saltare questa sezione ad eccezione di sez. 1.1.3
dove introdotti alcuni concetti fondamentali relativi alle funzioni di libreria.
1.1.1 Concetti base
Il concetto base di un sistema unix-like è quello di un nucleo del sistema, il cosiddetto kernel
(nel nostro caso Linux) a cui si demanda la gestione delle risorse essenziali (la CPU, la memoria,
le periferiche) mentre tutto il resto, quindi anche la parte che prevede l’interazione con l’utente,
dev’essere realizzato tramite programmi eseguiti dal kernel, che accedano alle risorse hardware
tramite opportune richieste a quest’ultimo.
Fin dall’inizio uno Unix si presenta come un sistema operativo multitasking, cioè in grado
di eseguire contemporaneamente più programmi, e multiutente, in cui è possibile che più utenti
siano connessi ad una macchina eseguendo più programmi“in contemporanea”. In realtà, almeno
per macchine a processore singolo, i programmi vengono eseguiti singolarmente a rotazione.
I kernel Unix più recenti, come Linux, sono realizzati sfruttando alcune caratteristiche dei
processori moderni come la gestione hardware della memoria e la modalità protetta. In sostanza
con i processori moderni si può disabilitare temporaneamente l’uso di certe istruzioni e l’accesso
a certe zone di memoria fisica. Quello che succede è che il kernel è il solo programma ad essere
eseguito in modalità privilegiata, con il completo accesso all’hardware, mentre i programmi
normali vengono eseguiti in modalità protetta e non possono accedere direttamente alle zone di
memoria riservate o alle porte di input/output.
Una parte del kernel, lo scheduler, si occupa di stabilire, ad intervalli fissi e sulla base di
un opportuno calcolo delle priorità, quale “processo” deve essere posto in esecuzione (il cosid-
detto preemptive multitasking). Questo verrà comunque eseguito in modalità protetta; quando
3

4 CAPITOLO 1. L’ARCHITETTURA DEL SISTEMA
necessario il processo potrà accedere alle risorse hardware soltanto attraverso delle opportune
chiamate al sistema che restituiranno il controllo al kernel.
La memoria viene sempre gestita dal kernel attraverso il meccanismo della memoria virtuale,
che consente di assegnare a ciascun processo uno spazio di indirizzi “virtuale” (vedi sez. 2.2) che
il kernel stesso, con l’ausilio della unità di gestione della memoria, si incaricherà di rimappare au-
tomaticamente sulla memoria disponibile, salvando su disco quando necessario (nella cosiddetta
area di swap) le pagine di memoria in eccedenza.
Le periferiche infine vengono viste in genere attraverso un’interfaccia astratta che permette
di trattarle come fossero file, secondo il concetto per cui everything is a file, su cui torneremo in
dettaglio in cap. 4. Questo non è vero per le interfacce di rete, che non rispondendo bene a detta
astrazione hanno un’interfaccia diversa, ma resta valido anche per loro il concetto generale che
tutto il lavoro di accesso e gestione delle periferiche a basso livello è effettuato dal kernel.
1.1.2 Il kernel e il sistema
Uno dei concetti fondamentali su cui si basa l’architettura dei sistemi Unix è quello della di-
stinzione fra il cosiddetto user space, che contraddistingue l’ambiente in cui vengono eseguiti i
programmi, e il kernel space, che è l’ambiente in cui viene eseguito il kernel. Ogni programma
vede sé stesso come se avesse la piena disponibilità della CPU e della memoria ed è, salvo i
meccanismi di comunicazione previsti dall’architettura, completamente ignaro del fatto che altri
programmi possono essere messi in esecuzione dal kernel.
Per questa separazione non è possibile ad un singolo programma disturbare l’azione di un
altro programma o del sistema e questo è il principale motivo della stabilità di un sistema unix-
like nei confronti di altri sistemi in cui i processi non hanno di questi limiti, o in cui vengono per
vari motivi eseguiti al livello del kernel. Pertanto deve essere chiaro a chi programma in Unix
che l’accesso diretto all’hardware non può avvenire se non all’interno del kernel; al di fuori dal
kernel il programmatore deve usare le opportune interfacce che quest’ultimo fornisce allo user
space.
Per capire meglio la distinzione fra kernel space e user space si può prendere in esame
la procedura di avvio di un sistema unix-like; all’avvio il BIOS (o in generale il software di
avvio posto nelle EPROM) eseguirà la procedura di avvio del sistema (il cosiddetto bootstrap1),
incaricandosi di caricare il kernel in memoria e di farne partire l’esecuzione; quest’ultimo, dopo
aver inizializzato le periferiche, farà partire il primo processo, init, che è quello che a sua volta
farà partire tutti i processi successivi. Fra questi ci sarà pure quello che si occupa di dialogare
con la tastiera e lo schermo della console, e quello che mette a disposizione dell’utente che si
vuole collegare, un terminale e la shell da cui inviare i comandi.
E’ da rimarcare come tutto ciò che riguarda l’interazione con l’utente, che usualmente viene
visto come parte del sistema, non abbia in realtà niente a che fare con il kernel, ma sia effettuato
da opportuni programmi che vengono eseguiti, allo stesso modo di un qualunque programma di
scrittura o di disegno e della stessa interfaccia grafica, in user space.
Questo significa ad esempio che il sistema di per sé non dispone di primitive per tutta una
serie di operazioni (ad esempio come la copia di un file) che altri sistemi (come Windows) hanno
invece al loro interno. Pertanto buona parte delle operazioni di normale amministrazione di un
sistema, come quella in esempio, sono implementate come normali programmi.
Per questo motivo quando ci si riferisce al sistema nella sua interezza è corretto parlare di un
sistema GNU/Linux: da solo il kernel è assolutamente inutile; quello che costruisce un sistema
operativo utilizzabile è la presenza di tutta una serie di librerie e programmi di utilità (i più
1
il nome deriva da un’espressione gergale che significa “sollevarsi da terra tirandosi per le stringhe delle scarpe”,
per indicare il compito, almeno apparentemente impossibile, di far eseguire un programma a partire da un computer
appena acceso che appunto non ne contiene nessuno; non è impossibile perché in realtà c’è un programma iniziale,
che è il BIOS.

1.1. UNA PANORAMICA 5
diffusi sono quelli realizzati dal progetto GNU della Free Software Foundation) che permettono
di eseguire le normali operazioni che ci si aspetta da un sistema operativo.
1.1.3 Chiamate al sistema e librerie di funzioni
Come accennato le interfacce con cui i programmi possono accedere all’hardware vanno sotto il
nome di chiamate al sistema (le cosiddette system call), si tratta di un insieme di funzioni che
un programma può chiamare, per le quali viene generata un’interruzione del processo passando
il controllo dal programma al kernel. Sarà poi quest’ultimo che (oltre a compiere una serie di
operazioni interne come la gestione del multitasking e l’allocazione della memoria) eseguirà la
funzione richiesta in kernel space restituendo i risultati al chiamante.
Ogni versione di Unix ha storicamente sempre avuto un certo numero di queste chiamate,
che sono riportate nella seconda sezione del Manuale di programmazione di Unix (quella cui si
accede con il comando man 2 <nome>) e Linux non fa eccezione. Queste sono poi state codificate
da vari standard, che esamineremo brevemente in sez. 1.2. Uno schema elementare della struttura
del sistema è riportato in fig. 1.1.
System Call Interface
kernel
scheduler VM driver
CPU memoria disco
kernel space
user space
GNU C Library
processo processo processo
Figura 1.1: Schema di massima della struttura di interazione fra processi, kernel e dispositivi in Linux.
Normalmente ciascuna di queste chiamate al sistema fornite dal kernel viene rimappata
in opportune funzioni con lo stesso nome definite dentro la libreria fondamentale del sistema,
chiamata Libreria Standard del C (C Standard Library) in ragione del fatto che il primo Unix
venne scritto con il linguaggio C ed usando le librerie ad esso associato. Detta libreria, oltre alle
interfacce alle system call, contiene anche tutta la serie delle ulteriori funzioni di base definite
nei vari standard, che sono comunemente usate nella programmazione.
Questo è importante da capire perché programmare in Linux significa anzitutto essere in
grado di usare le varie funzioni fornite dalla Libreria Standard del C, in quanto né il kernel,
né il linguaggio C implementano direttamente operazioni comuni come l’allocazione dinamica

della memoria, l’input/output bufferizzato sui file o la manipolazione delle stringhe, presenti in
qualunque programma.
Quanto appena illustrato mette in evidenza il fatto che nella stragrande maggioranza dei
casi,2 si dovrebbe usare il nome GNU/Linux (piuttosto che soltanto Linux) in quanto una parte
essenziale del sistema (senza la quale niente funzionerebbe) è la GNU Standard C Library (in
breve glibc), ovvero la libreria realizzata dalla Free Software Foundation nella quale sono state
implementate tutte le funzioni essenziali definite negli standard POSIX e ANSI C, utilizzate da
qualunque programma.
Le funzioni della libreria standard sono quelle riportate dalla terza sezione del Manuale
di Programmazione di Unix (cioè accessibili con il comando man 3 <nome>) e sono costruite
sulla base delle chiamate al sistema del kernel; è importante avere presente questa distinzione,
fondamentale dal punto di vista dell’implementazione, anche se poi, nella realizzazione di normali
programmi, non si hanno differenze pratiche fra l’uso di una funzione di libreria e quello di una
chiamata al sistema.
Le librerie standard del C GNU consentono comunque, nel caso non sia presente una specifica
funzione di libreria corrispondente, di eseguire una system call generica tramite la funzione
syscall, il cui prototipo, accessibile se si è definita la macro _GNU_SOURCE, (vedi sez. 1.2.7) è:
#include <unistd.h>
#include <sys/syscall.h>
int syscall(int number, ...)
Esegue la system call indicata da number.
La funzione richiede come primo argomento il numero della system call da invocare, seguita
dagli argomenti da passare alla stessa (che ovviamente dipendono da quest’ultima), e restituisce
il codice di ritorno della system call invocata. In generale un valore nullo indica il successo ed
un valore negativo è un codice di errore che poi viene memorizzato nella variabile errno (sulla
gestione degli errori torneremo in dettaglio in sez. 8.5).
Il valore di number dipende sia dalla versione di kernel che dall’architettura,3 ma ciascuna
system call viene in genere identificata da una costante nella forma SYS_* dove al prefisso viene
aggiunto il nome che spesso corrisponde anche alla omonima funzione di libreria; queste costanti
sono definite nel file sys/syscall.h, ma si possono anche usare direttamente valori numerici.
1.1.4 Un sistema multiutente
Linux, come gli altri kernel Unix, nasce fin dall’inizio come sistema multiutente, cioè in grado
di fare lavorare più persone in contemporanea. Per questo esistono una serie di meccanismi di
sicurezza, che non sono previsti in sistemi operativi monoutente, e che occorre tenere presenti.
Il concetto base è quello di utente (user) del sistema, le cui capacità rispetto a quello che
può fare sono sottoposte a ben precisi limiti. Sono cos`ı previsti una serie di meccanismi per
identificare i singoli utenti ed una serie di permessi e protezioni per impedire che utenti diversi
possano danneggiarsi a vicenda o danneggiare il sistema. Questi meccanismi sono realizzati dal
kernel stesso ed attengono alle operazioni più varie, e torneremo su di essi in dettaglio più avanti.
Normalmente l;utente è identificato da un nome (il cosiddetto username), che ad esempio
è quello che viene richiesto all’ingresso nel sistema dalla procedura di login (torneremo su que-
sto in sez. 10.1.4). Questa procedura si incarica di verificare l’identità dell’utente, in genere
2
esistono implementazioni diverse delle librerie Standard del C, come le libc5 o le uClib, che non derivano dal
progetto GNU. Le libc5 oggi sono, tranne casi particolari, completamente soppiantate dalle glibc, le uClib pur
non essendo complete come le glibc, restano invece molto diffuse nel mondo embedded per le loro dimensioni
estremamente ridotte (e soprattutto per la possibilità di togliere le parti non necessarie), e pertanto costituiscono
un valido rimpiazzo delle glibc in tutti quei sistemi specializzati che richiedono una minima occupazione di
memoria, un’altra versione di queste librerie è quella realizzata da Google per Android.
3
in genere le vecchie system call non vengono eliminate e se ne aggiungono di nuove con nuovi numeri.

1.2. GLI STANDARD 7
attraverso la richiesta di una parola d’ordine (la password), anche se sono possibili meccanismi
diversi.4 Eseguita la procedura di riconoscimento in genere il sistema manda in esecuzione un
programma di interfaccia (che può essere la shell su terminale o un’interfaccia grafica) che mette
a disposizione dell’utente un meccanismo con cui questo può impartire comandi o eseguire altri
programmi.
Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto default group), ma può
essere associato ad altri gruppi (i supplementary group), questo permette di gestire i permessi
di accesso ai file e quindi anche alle periferiche, in maniera più flessibile, definendo gruppi di
lavoro, di accesso a determinate risorse, ecc.
L’utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad un nome
espresso in caratteri è inserita nei due file /etc/passwd e /etc/group.5 Questi numeri sono
l’user identifier, detto in breve user-ID, ed indicato dall’acronimo uid, e il group identifier, detto
in breve group-ID, ed identificato dall’acronimo gid, e sono quelli che vengono usati dal kernel
per identificare l’utente; torneremo in dettaglio su questo argomento in sez. 3.3.
In questo modo il sistema è in grado di tenere traccia dell’utente a cui appartiene ciascun
processo ed impedire ad altri utenti di interferire con quest’ultimo. Inoltre con questo sistema
viene anche garantita una forma base di sicurezza interna in quanto anche l’accesso ai file (vedi
sez. 5.3) è regolato da questo meccanismo di identificazione.
Infine in ogni Unix è presente un utente speciale privilegiato, il cosiddetto superuser, il cui
username è di norma root, ed il cui uid è zero. Esso identifica l’amministratore del sistema,
che deve essere in grado di fare qualunque operazione; per l’utente root infatti i meccanismi di
controllo descritti in precedenza sono disattivati.6
1.2 Gli standard
In questa sezione faremo una breve panoramica relativa ai vari standard che nel tempo sono stati
formalizzati da enti, associazioni, consorzi e organizzazioni varie al riguardo ai sistemi operativi
di tipo Unix o alle caratteristiche che si sono stabilite come standard di fatto in quanto facenti
parte di alcune implementazioni molto diffuse come BSD o System V.
Ovviamente prenderemo in considerazione solo gli standard riguardanti interfacce di pro-
grammazione e le altre caratteristiche di un sistema unix-like (alcuni standardizzano pure i
comandi base del sistema e la shell) ed in particolare ci concentreremo sul come ed in che modo
essi sono supportati sia per quanto riguarda il kernel che le librerie del C (con una particolare
attenzione alle glibc).
1.2.1 Lo standard ANSI C
Lo standard ANSI C è stato definito nel 1989 dall’American National Standard Institute come
prima standardizzazione del linguaggio C e per questo si fa riferimento ad esso anche come
C89. L’anno successivo è stato adottato dalla ISO (International Standard Organisation) come
standard internazionale con la sigla ISO/IEC 9899:1990, e per questo è noto anche sotto il nome
di standard ISO C, o ISO C90.
Nel 1999 è stata pubblicata una revisione dello standard C89, che viene usualmente indicata
come C99, anche questa è stata ratificata dalla ISO con la sigla ISO/IEC 9899:1990, per cui vi
si fa riferimento anche come ISO C99.
4
ad esempio usando la libreria PAM (Pluggable Autentication Methods) è possibile astrarre completamente
dai meccanismi di autenticazione e sostituire ad esempio l’uso delle password con meccanismi di identificazione
biometrica, per un approfondimento dell’argomento si rimanda alla sez. 4.3 di [3].
5
in realtà negli sistemi più moderni, come vedremo in sez. 8.2.3 queste informazioni possono essere mantenute,
con l’uso del Name Service Switch, su varie tipologie di supporti, compresi server centralizzati come LDAP.
6
i controlli infatti vengono sempre eseguiti da un codice del tipo: “if (uid) { ... }”.

Scopo dello standard è quello di garantire la portabilità dei programmi C fra sistemi operativi
diversi, ma oltre alla sintassi ed alla semantica del linguaggio C (operatori, parole chiave, tipi di
dati) lo standard prevede anche una libreria di funzioni che devono poter essere implementate
su qualunque sistema operativo.
Per questo motivo, anche se lo standard non ha alcun riferimento ad un sistema di tipo Unix,
GNU/Linux (per essere precisi le glibc), come molti Unix moderni, provvede la compatibilità
con questo standard, fornendo le funzioni di libreria da esso previste. Queste sono dichiarate in
una serie di header file7 (anch’essi provvisti dalla glibc); in tab. 1.1 si sono riportati i principali
header file definiti negli standard POSIX ed ANSI C, che sono anche quelli definiti negli altri
standard descritti nelle sezioni successive.
Header
Standard
Contenuto
ANSI C POSIX
assert.h • – Verifica le asserzioni fatte in un programma.
ctype.h • – Tipi standard.
dirent.h – • Manipolazione delle directory.
errno.h – • Errori di sistema.
fcntl.h – • Controllo sulle opzioni dei file.
limits.h – • Limiti e parametri del sistema.
malloc.h • – Allocazione della memoria.
setjmp.h • – Salti non locali.
signal.h – • Gestione dei segnali.
stdarg.h • – Gestione di funzioni a argomenti variabili.
stdio.h • – I/O bufferizzato in standard ANSI C.
stdlib.h • – Definizioni della libreria standard.
string.h • – Manipolazione delle stringhe.
time.h – • Gestione dei tempi.
times.h • – Gestione dei tempi.
unistd.h – • Unix standard library.
utmp.h – • Registro connessioni utenti.
Tabella 1.1: Elenco dei vari header file definiti dallo standard POSIX.
In realtà le glibc ed i relativi header file definiscono un insieme di funzionalità in cui sono
incluse come sottoinsieme anche quelle previste dallo standard ANSI C. È possibile ottenere
una conformità stretta allo standard (scartando le funzionalità addizionali) usando il gcc con
l’opzione -ansi. Questa opzione istruisce il compilatore a definire nei vari header file soltanto le
funzionalità previste dallo standard ANSI C e a non usare le varie estensioni al linguaggio e al
preprocessore da esso supportate.
1.2.2 I tipi di dati primitivi
Uno dei problemi di portabilità del codice più comune è quello dei tipi di dati utilizzati nei
programmi, che spesso variano da sistema a sistema, o anche da una architettura ad un’altra
(ad esempio passando da macchine con processori 32 bit a 64). In particolare questo è vero
nell’uso dei cosiddetti tipi elementari del linguaggio C (come int) la cui dimensione varia a
seconda dell’architettura hardware.
Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati associati ad alcune
variabili nei sistemi Unix, dando per scontata la dimensione. Ad esempio la posizione corrente
all’interno di un file è sempre stata associata ad un intero a 32 bit, mentre il numero di dispositivo
è sempre stato associato ad un intero a 16 bit. Storicamente questi erano definiti rispettivamente
come int e short, ma tutte le volte che, con l’evolversi ed il mutare delle piattaforme hardware,
7
si chiamano cos`ı i file di dichiarazione di variabili, tipi e funzioni, usati normalmente da un compilatore C;
per poter accedere alle funzioni occorre includere con la direttiva #include questi file nei propri programmi ed in
seguito per ciascuna funzione che tratteremo indicheremo anche gli header file necessari ad usarla.

1.2. GLI STANDARD 9
alcuni di questi tipi si sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad una
infinita serie di problemi di portabilità.
Tipo Contenuto
caddr_t Core address.
clock_t Contatore del tempo di sistema.
dev_t Numero di dispositivo (vedi sez. 5.1.5).
gid_t Identificatore di un gruppo.
ino_t Numero di inode.
key_t Chiave per il System V IPC.
loff_t Posizione corrente in un file.
mode_t Attributi di un file.
nlink_t Contatore dei link su un file.
off_t Posizione corrente in un file.
pid_t Identificatore di un processo.
rlim_t Limite sulle risorse.
sigset_t Insieme di segnali.
size_t Dimensione di un oggetto.
ssize_t Dimensione in numero di byte ritornata dalle funzioni.
ptrdiff_t Differenza fra due puntatori.
time_t Numero di secondi (in tempo di calendario, vedi sez. 8.4).
uid_t Identificatore di un utente.
Tabella 1.2: Elenco dei tipi primitivi, definiti in sys/types.h.
Per questo motivo tutte le funzioni di libreria di solito non fanno riferimento ai tipi elementari
dello standard del linguaggio C, ma ad una serie di tipi primitivi del sistema, riportati in tab. 1.2,
e definiti nell’header file sys/types.h, in modo da mantenere completamente indipendenti i tipi
utilizzati dalle funzioni di sistema dai tipi elementari supportati dal compilatore C.
1.2.3 Lo standard System V
Come noto Unix nasce nei laboratori della AT&T, che ne registrò il nome come marchio de-
positato, sviluppandone una serie di versioni diverse; nel 1983 la versione supportata ufficial-
mente venne rilasciata al pubblico con il nome di Unix System V, e si fa rifermento a questa
implementazione con la sigla SysV o SV.
Negli anni successivi l’AT&T prosegu`ı lo sviluppo rilasciando varie versioni con aggiunte e
integrazioni, ed in particolare la release 2 nel 1985, a cui si fa riferimento con SVr2 e la release
3 nel 1986 (denominata SVr3). Le interfacce di programmazione di queste due versioni vennero
descritte formalmente in due documenti denominati System V Interface Definition (o SVID),
pertanto nel 1995 venne rilasciata la specifica SVID 1 e nel 1986 la specifica SVID 2.
Nel 1989 un accordo fra vari venditori (AT&T, Sun, HP, ed altri) portò ad una versione
di System V che provvedeva un’unificazione delle interfacce comprendente anche Xenix e BSD,
questa venne denominata release 4 o SVr4. Anche le relative interfacce vennero descritte in un
documento dal titolo System V Interface Description, venendo a costituire lo standard SVID 3,
che viene considerato la specifica finale di System V, ed a cui spesso si fa riferimento semplice-
mente con SVID. Anche SVID costituisce un sovrainsieme delle interfacce definite dallo standard
POSIX.
Nel 1992 venne rilasciata una seconda versione del sistema, la SVr4.2; l’anno successivo
la divisione della AT&T (già a suo tempo rinominata in Unix System Laboratories) venne
acquistata dalla Novell, che poi trasfer`ı il marchio Unix al consorzio X/Open. L’ultima versione
di System V fu la SVr4.2MP rilasciata nel Dicembre 93. Infine nel 1995 è stata rilasciata da SCO,
che aveva acquisito alcuni diritti sul codice di System V, una ulteriore versione delle System V
Interface Description, che va sotto la denominazione di SVID 4.

Linux e le glibc implementano le principali funzionalità richieste dalle specifiche SVID che
non sono già incluse negli standard POSIX ed ANSI C, per compatibilità con lo Unix System
V e con altri Unix (come SunOS) che le includono. Tuttavia le funzionalità più oscure e meno
utilizzate (che non sono presenti neanche in System V) sono state tralasciate.
Le funzionalità implementate sono principalmente il meccanismo di intercomunicazione fra
i processi e la memoria condivisa (il cosiddetto System V IPC, che vedremo in sez. 11.2) le
funzioni della famiglia hsearch e drand48, fmtmsg e svariate funzioni matematiche.
1.2.4 Lo “standard” BSD
Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l’Università di Berkeley e la
AT&T generò una delle prime e più importanti fratture del mondo Unix. L’università di Berkeley
prosegu`ı nello sviluppo della base di codice di cui disponeva, e che presentava parecchie migliorie
rispetto alle versioni allora disponibili, fino ad arrivare al rilascio di una versione completa di
Unix, chiamata appunto BSD, del tutto indipendente dal codice della AT&T.
Benché BSD non sia mai stato uno standard formalizzato, l’implementazione dello Unix
dell’Università di Berkeley nella sua storia ha introdotto una serie di estensioni e interfacce di
grandissima rilevanza, come i link simbolici, la funzione select ed i socket di rete. Per questo
motivo si fa spesso riferimento esplicito alle interfacce presenti nelle varie versioni dello Unix di
Berkeley con una apposita sigla.
Nel 1983, con il rilascio della versione 4.2 di BSD, venne definita una implementazione delle
funzioni di interfaccia a cui si fa riferimento con la sigla 4.2BSD. Per fare riferimento alle pre-
cedenti versioni si usano poi le sigle 3BSD e 4BSD (per le due versioni pubblicate nel 1980), e
4.1BSD per quella pubblicata nel 1981.
Le varie estensioni ideate a Berkeley sono state via via aggiunte al sistema nelle varie versioni
succedutesi negli anni, che vanno sotto il nome di 4.3BSD, per la versione rilasciata nel 1986 e
4.4BSD, per la versione rilasciata nel 1993, che costituisce l’ultima release ufficiale dell’università
di Berkeley. Si tenga presente che molte di queste interfacce sono presenti in derivati commerciali
di BSD come SunOS. Il kernel Linux e le glibc forniscono tutte queste estensioni che sono state
in gran parte incorporate negli standard successivi.
1.2.5 Gli standard IEEE – POSIX
Lo standard ufficiale creato da un organismo indipendente più attinente alle interfacce di un
sistema unix-like nel suo complesso (e che concerne sia il kernel che le librerie che i comandi)
è stato lo standard POSIX. Esso prende origine dallo standard ANSI C, che contiene come
sottoinsieme, prevedendo ulteriori capacità per le funzioni in esso definite, ed aggiungendone di
nuove.
In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da Richard Stall-
man, sta per Portable Operating System Interface, ma la X finale denuncia la sua stretta rela-
zione con i sistemi Unix. Esso nasce dal lavoro dell’IEEE (Institute of Electrical and Electro-
nics Engeneers) che ne produsse una prima versione, nota come IEEE 1003.1-1988, mirante a
standardizzare l’interfaccia con il sistema operativo.
Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di libreria, e in
seguito sono stati prodotti anche altri standard per la shell e i comandi di sistema (1003.2), per
le estensioni real-time e per i thread (rispettivamente 1003.1d e 1003.1c) per i socket (1003.1g) e
vari altri. In tab. 1.3 è riportata una classificazione sommaria dei principali documenti prodotti,
e di come sono identificati fra IEEE ed ISO; si tenga conto inoltre che molto spesso si usa
l’estensione IEEE anche come aggiunta al nome POSIX; ad esempio è più comune parlare di
POSIX.4 come di POSIX.1b.

1.2. GLI STANDARD 11
Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione si aggiungono
continuamente, mentre le versioni precedenti vengono riviste; talvolta poi i riferimenti cambia-
no nome, per cui anche solo seguire le denominazioni usate diventa particolarmente faticoso;
una pagina dove si possono recuperare varie (e di norma piuttosto intricate) informazioni è
http://www.pasc.org/standing/sd11.html.
Standard IEEE ISO Contenuto
POSIX.1 1003.1 9945-1 Interfacce di base
POSIX.1a 1003.1a 9945-1 Estensioni a POSIX.1
POSIX.2 1003.2 9945-2 Comandi
POSIX.3 2003 TR13210 Metodi di test
POSIX.4 1003.1b — Estensioni real-time
POSIX.4a 1003.1c — Thread
POSIX.4b 1003.1d 9945-1 Ulteriori estensioni real-time
POSIX.5 1003.5 14519 Interfaccia per il linguaggio ADA
POSIX.6 1003.2c,1e 9945-2 Sicurezza
POSIX.8 1003.1f 9945-1 Accesso ai file via rete
POSIX.9 1003.9 — Interfaccia per il Fortran-77
POSIX.12 1003.1g 9945-1 Socket
Tabella 1.3: Elenco dei vari standard POSIX e relative denominazioni.
Benché l’insieme degli standard POSIX siano basati sui sistemi Unix, essi definiscono comun-
que un’interfaccia di programmazione generica e non fanno riferimento ad una implementazione
specifica (ad esempio esiste un’implementazione di POSIX.1 anche sotto Windows NT).
Linux e le glibc implementano tutte le funzioni definite nello standard POSIX.1, queste
ultime forniscono in più alcune ulteriori capacità (per funzioni di pattern matching e per la
manipolazione delle regular expression), che vengono usate dalla shell e dai comandi di sistema
e che sono definite nello standard POSIX.2.
Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate ulteriori funziona-
lità aggiunte dallo standard POSIX.1c per quanto riguarda i thread (vedi cap. 13), e dallo stan-
dard POSIX.1b per quanto riguarda i segnali e lo scheduling real-time (sez. 9.5.1 e sez. 3.4.3), la
misura del tempo, i meccanismi di intercomunicazione (sez. 11.4) e l’I/O asincrono (sez. 12.3.3).
Lo standard principale resta comunque POSIX.1, che continua ad evolversi; la versione più
nota, cui gran parte delle implementazioni fanno riferimento, e che costituisce una base per molti
altri tentativi di standardizzazione, è stata rilasciata anche come standard internazionale con
la sigla ISO/IEC 9945-1:1996 ed include i precedenti POSIX.1b e POSIX.1c. In genere si fa
riferimento ad essa come POSIX.1-1996.
Nel 2001 è stata poi eseguita una sintesi degli standard POSIX.1, POSIX.2 e SUSv3 (vedi
sez. 1.2.6) in un unico documento, redatto sotto gli auspici del cosiddetto gruppo Austin che
va sotto il nome di POSIX.1-2001. Questo standard definisce due livelli di conformità, quello
POSIX, in cui sono presenti solo le interfacce di base, e quello XSI che richiede la presenza di
una serie di estensioni opzionali per lo standard POSIX, riprese da SUSv3. Inoltre lo standard
è stato allineato allo standard C99, e segue lo stesso nella definizione delle interfacce.
A questo standard sono stati aggiunti due documenti di correzione e perfezionamento deno-
minati Technical Corrigenda, il TC1 del 2003 ed il TC2 del 2004, e talvolta si fa riferimento agli
stessi con le sigle POSIX.1-2003 e POSIX.1-2004.
Una ulteriore revisione degli standard POSIX e SUS è stata completata e ratificata nel 2008,
cosa che ha portato al rilascio di una nuova versione sotto il nome di POSIX.1-2008 (e SUSv4),
con l’incorporazione di alcune nuove interfacce, la obsolescenza di altre, la trasformazione da
opzionali a richieste di alcune specifiche di base, oltre alle solite precisazioni ed aggiornamenti.
Anche in questo caso è prevista la suddivisione in una conformità di base, e delle interfacce
aggiuntive.

Le procedure di aggiornamento dello standard POSIX prevedono comunque un percorso con-
tinuo, che prevede la possibilità di introduzione di nuove interfacce e la definizione di precisazioni
ed aggiornamenti, per questo in futuro verranno rilasciate nuove versioni. Alla stesura di que-
ste note l’ultima revisione approvata resta POSIX.1-2008, uno stato della situazione corrente
del supporto degli standard è allegato alla documentazione delle glibc e si può ottenere con il
comando man standards.
1.2.6 Gli standard X/Open – Opengroup – Unix
Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi Unix per giungere
ad un’armonizzazione delle varie implementazioni. Per far questo iniziò a pubblicare una serie
di documentazioni e specifiche sotto il nome di X/Open Portability Guide a cui di norma si fa
riferimento con l’abbreviazione XPGn, con n che indica la versione.
Nel 1989 il consorzio produsse una terza versione di questa guida particolarmente voluminosa
(la X/Open Portability Guide, Issue 3), contenente una dettagliata standardizzazione dell’inter-
faccia di sistema di Unix, che venne presa come riferimento da vari produttori. Questo standard,
detto anche XPG3 dal nome della suddetta guida, è sempre basato sullo standard POSIX.1,
ma prevede una serie di funzionalità aggiuntive fra cui le specifiche delle API8 per l’interfaccia
grafica (X11).
Nel 1992 lo standard venne rivisto con una nuova versione della guida, la Issue 4, da cui
la sigla XPG4, che aggiungeva l’interfaccia XTI (X Transport Interface) mirante a soppiantare
(senza molto successo) l’interfaccia dei socket derivata da BSD. Una seconda versione della guida
fu rilasciata nel 1994; questa è nota con il nome di Spec 1170 (dal numero delle interfacce, header
e comandi definiti) ma si fa riferimento ad essa anche come XPG4v2.
Nel 1993 il marchio Unix passò di proprietà dalla Novell (che a sua volta lo aveva comprato
dalla AT&T) al consorzio X/Open che iniziò a pubblicare le sue specifiche sotto il nome di Single
UNIX Specification o SUS, l’ultima versione di Spec 1170 diventò cos`ı la prima versione delle
Single UNIX Specification, detta SUS o SUSv1, ma più comunemente nota anche come Unix 95.
Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata da un
gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò alla costituzione dell’Open
Group, un consorzio internazionale che raccoglie produttori, utenti industriali, entità accademi-
che e governative. Attualmente il consorzio è detentore del marchio depositato Unix, e prose-
gue il lavoro di standardizzazione delle varie implementazioni, rilasciando periodicamente nuove
specifiche e strumenti per la verifica della conformità alle stesse.
Nel 1997 fu annunciata la seconda versione delle Single UNIX Specification, nota con la sigla
SUSv2, in questa versione le interfacce specificate salgono a 1434, e addirittura a 3030 se si
considerano le stazioni di lavoro grafiche, per le quali sono inserite pure le interfacce usate da
CDE che richiede sia X11 che Motif. La conformità a questa versione permette l’uso del nome
Unix 98, usato spesso anche per riferirsi allo standard. Un altro nome alternativo di queste
specifiche, date le origini, è XPG5.
Come accennato nel 2001, con il rilascio dello standard POSIX.1-2001, è stato effettuato uno
sforzo di sintesi in cui sono state comprese, nella parte di interfacce estese, anche le interfacce
definite nelle Single UNIX Specification, pertanto si può fare riferimento a detto standard, quando
comprensivo del rispetto delle estensioni XSI, come SUSv3, e fregiarsi del marchio UNIX 03 se
conformi ad esso.
Infine, come avvenuto per POSIX.1-2001, anche con la successiva revisione dello standard
POSIX.1 (la POSIX.1-2008) è stato stabilito che la conformità completa a tutte quelle che sono
le nuove estensioni XSI previste dall’aggiornamento vada a definire la quarta versione delle Single
UNIX Specification, chiamata appunto SUSv4.
8
le Application Programmable Interface, in sostanze le interfacce di programmazione.

1.2.7 Il controllo di aderenza agli standard
In Linux, se si usano le glibc, la conformità agli standard appena descritti può essere richiesta
sia attraverso l’uso di opportune opzioni del compilatore (il gcc) che definendo delle specifiche
costanti prima dell’inclusione dei file di dichiarazione (gli header file) che definiscono le funzioni
di libreria.
Ad esempio se si vuole che i programmi seguano una stretta attinenza allo standard ANSI C
si può usare l’opzione -ansi del compilatore, e non potrà essere utilizzata nessuna funzione non
riconosciuta dalle specifiche standard ISO per il C. Il gcc possiede inoltre una specifica opzione
per richiedere la conformità ad uno standard, nella forma -std=nome, dove nome può essere c89
per indicare lo standard ANSI C (vedi sez. 1.2.1) o c99 per indicare la conformità allo standard
C99.9
Per attivare le varie opzioni di controllo di aderenza agli standard è poi possibile definire
delle macro di preprocessore che controllano le funzionalità che le glibc possono mettere a di-
sposizione:10 questo può essere fatto attraverso l’opzione -D del compilatore, ma è buona norma
farlo inserendo gli opportuni #define prima della inclusione dei propri header file.
Le macro disponibili per controllare l’aderenza ai vari standard messe a disposizione delle
glibc, che rendono disponibili soltanto le funzioni in esse definite, sono illustrate nel seguente
elenco:
__STRICT_ANSI__
richiede l’aderenza stretta allo standard C ISO; viene automaticamente pre-
definita qualora si invochi il gcc con le opzione -ansi o -std=c99.
_POSIX_SOURCE definendo questa macro (considerata obsoleta) si rendono disponibili tutte
le funzionalità dello standard POSIX.1 (la versione IEEE Standard 1003.1)
insieme a tutte le funzionalità dello standard ISO C. Se viene anche definita
con un intero positivo la macro _POSIX_C_SOURCE lo stato di questa non viene
preso in considerazione.
_POSIX_C_SOURCE
definendo questa macro ad un valore intero positivo si controlla quale livello
delle funzionalità specificate da POSIX viene messa a disposizione; più alto
è il valore maggiori sono le funzionalità:
• un valore uguale a “1” rende disponibili le funzionalità specificate nella
edizione del 1990 (IEEE Standard 1003.1-1990);
• valori maggiori o uguali a “2” rendono disponibili le funzionalità pre-
viste dallo standard POSIX.2 specificate nell’edizione del 1992 (IEEE
Standard 1003.2-1992),
• un valore maggiore o uguale a “199309L” rende disponibili le funziona-
lità previste dallo standard POSIX.1b specificate nell’edizione del 1993
(IEEE Standard 1003.1b-1993);
• un valore maggiore o uguale a “199506L” rende disponibili le funziona-
lità previste dallo standard POSIX.1 specificate nell’edizione del 1996
(ISO/IEC 9945-1:1996), ed in particolare le definizioni dello standard
POSIX.1c per i thread;
9
che non è al momento completa, esistono anche le possibilità di usare i valori gnu89, l’attuale default, che
indica l’uso delle estensioni GNU al C89, riprese poi dal C99, o gnu89 che indica il dialetto GNU del C99, che
diventerà il default quando la conformità a quest’ultimo sarà completa.
10
le macro sono definite nel file di dichiarazione <features.h>, ma non è necessario includerlo nei propri
programmi in quanto viene automaticamente incluso da tutti gli altri file di dichiarazione che utilizzano le macro
in esso definite; si tenga conto inoltre che il file definisce anche delle ulteriori macro interne, in genere con un
doppio prefisso di _, che non devono assolutamente mai essere usate direttamente.

• a partire dalla versione 2.3.3 delle glibc un valore maggiore o ugua-
le a “200112L” rende disponibili le funzionalità di base previste dallo
standard POSIX.1-2001, escludendo le estensioni XSI;
• a partire dalla versione 2.10 delle glibc un valore maggiore o ugua-
le a “200809L” rende disponibili le funzionalità di base previste dallo
standard POSIX.1-2008, escludendo le estensioni XSI;
• in futuro valori superiori potranno abilitare ulteriori estensioni.
_BSD_SOURCE definendo questa macro si rendono disponibili le funzionalità derivate da
BSD4.3, insieme a quelle previste dagli standard ISO C, POSIX.1 e PO-
SIX.2; alcune delle funzionalità previste da BSD sono però in conflitto con
le corrispondenti definite nello standard POSIX.1, in questo caso se la macro
è definita le definizioni previste da BSD4.3 avranno la precedenza rispetto a
POSIX.
A causa della natura dei conflitti con POSIX per ottenere una piena com-
patibilità con BSD4.3 può essere necessario anche usare una libreria di com-
patibilità, dato che alcune funzioni sono definite in modo diverso. In questo
caso occorrerà anche usare l’opzione -lbsd-compat con il compilatore per in-
dicargli di utilizzare le versioni nella libreria di compatibilità prima di quelle
normali.
Si tenga inoltre presente che la preferenza verso le versioni delle funzioni
usate da BSD viene mantenuta soltanto se nessuna delle ulteriori macro di
specificazione di standard successivi (vale a dire una fra _POSIX_C_SOURCE,
_POSIX_SOURCE, _SVID_SOURCE, _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED
o _GNU_SOURCE) è stata a sua volta attivata, nel qual caso queste hanno la
precedenza. Se però si definisce _BSD_SOURCE dopo aver definito una di queste
macro, l’effetto sarà quello di dare la precedenza alle funzioni in forma BSD.
_SVID_SOURCE definendo questa macro si rendono disponibili le funzionalità derivate da
SVID. Esse comprendono anche quelle definite negli standard ISO C, PO-
SIX.1, POSIX.2, e X/Open (XPGn) illustrati in precedenza.
_XOPEN_SOURCE definendo questa macro si rendono disponibili le funzionalità descritte nel-
la X/Open Portability Guide. Anche queste sono un sovrainsieme di quelle
definite negli standard POSIX.1 e POSIX.2 ed in effetti sia _POSIX_SOURCE
che _POSIX_C_SOURCE vengono automaticamente definite. Sono incluse anche
ulteriori funzionalità disponibili in BSD e SVID, più una serie di estensioni
a secondo dei seguenti valori:
• la definizione della macro ad un valore qualunque attiva le funzionalità
specificate negli standard POSIX.1, POSIX.2 e XPG4;
• un valore di “500” o superiore rende disponibili anche le funzionalità
introdotte con SUSv2, vale a dire la conformità ad Unix98;
• a partire dalla versione 2.2 delle glibc un valore uguale a “600” o su-
periore rende disponibili anche le funzionalità introdotte con SUSv3,
corrispondenti allo standard POSIX.1-2001 più le estensioni XSI.
• a partire dalla versione 2.10 delle glibc un valore uguale a “700” o su-
periore rende disponibili anche le funzionalità introdotte con SUSv4,
corrispondenti allo standard POSIX.1-2008 più le estensioni XSI.

_XOPEN_SOURCE_EXTENDED
definendo questa macro si rendono disponibili le ulteriori funzionalità neces-
sarie ad essere conformi al rilascio del marchio X/Open Unix corrisponden-
ti allo standard Unix95, vale a dire quelle specificate da SUSv1/XPG4v2.
Questa macro viene definita implicitamente tutte le volte che si imposta
_XOPEN_SOURCE ad un valore maggiore o uguale a 500.
_ISOC99_SOURCE definendo questa macro si rendono disponibili le funzionalità previste per la
revisione delle librerie standard del C introdotte con lo standard ISO C99.
La macro è definita a partire dalla versione 2.1.3 delle glibc.
Le precedenti versioni della serie 2.1.x riconoscevano le stesse estensioni con
la macro _ISOC9X_SOURCE, dato che lo standard non era stato finalizzato, ma
le glibc avevano già un’implementazione completa che poteva essere attivata
definendo questa macro. Benché questa sia obsoleta viene tuttora riconosciuta
come equivalente di _ISOC99_SOURCE per compatibilità.
_GNU_SOURCE definendo questa macro si rendono disponibili tutte le funzionalità disponibili
nei vari standard oltre a varie estensioni specifiche presenti solo nelle glibc ed
in Linux. Gli standard coperti sono: ISO C89, ISO C99, POSIX.1, POSIX.2,
BSD, SVID, X/Open, SUS.
L’uso di _GNU_SOURCE è equivalente alla definizione contemporanea delle ma-
cro: _BSD_SOURCE, _SVID_SOURCE, _POSIX_SOURCE, _ISOC99_SOURCE, inoltre
_POSIX_C_SOURCE con valore “200112L” (o “199506L” per le versioni delle
glibc precedenti la 2.5), _XOPEN_SOURCE_EXTENDED e _XOPEN_SOURCE con va-
lore 600 (o 500 per le versioni delle glibc precedenti la 2.2); oltre a queste
vengono pure attivate le ulteriori due macro _ATFILE_SOURCE e _LARGEFI-
LE64_SOURCE che definiscono funzioni previste esclusivamente dalle glibc.
Benché Linux supporti in maniera estensiva gli standard più diffusi, esistono comunque delle
estensioni e funzionalità specifiche, non presenti in altri standard e lo stesso vale per le glibc
stesse, che definiscono anche delle ulteriori funzioni di libreria. Ovviamente l’uso di queste fun-
zionalità deve essere evitato se si ha a cuore la portabilità, ma qualora questo non sia un requisito
esse possono rivelarsi molto utili.
Come per l’aderenza ai vari standard, le funzionalità aggiuntive possono essere rese esplici-
tamente disponibili tramite la definizione di opportune macro di preprocessore, alcune di que-
ste vengono attivate con la definizione di _GNU_SOURCE, mentre altre devono essere attivate
esplicitamente, inoltre alcune estensioni possono essere attivate indipendentemente tramite una
opportuna macro; queste estensioni sono illustrate nel seguente elenco:
_LARGEFILE_SOURCE
definendo questa macro si rendono disponibili alcune funzioni che consentono
di superare una inconsistenza presente negli standard con i file di grandi
dimensioni, ed in particolare definire le due funzioni fseeko e ftello che
al contrario delle corrispettive fseek e ftell usano il tipo di dato specifico
off_t (vedi sez. 7.2.7).
_LARGEFILE64_SOURCE
definendo questa macro si rendono disponibili le funzioni di una interfaccia
alternativa al supporto di valori a 64 bit nelle funzioni di gestione dei file (non
supportati in certi sistemi), caratterizzate dal suffisso 64 aggiunto ai vari nomi
di tipi di dato e funzioni (come off64_t al posto di off_t o lseek64 al posto
di lseek).

Le funzioni di questa interfaccia alternativa sono state proposte come una
estensione ad uso di transizione per le Single UNIX Specification, per consen-
tire la gestione di file di grandi dimensioni anche nei sistemi a 32 bit, in cui
la dimensione massima, espressa con un intero, non poteva superare i 2Gb.
Nei nuovi programmi queste funzioni devono essere evitate, a favore dell’uso
macro _FILE_OFFSET_BITS, che definita al valore di 64 consente di usare in
maniera trasparente le funzioni dell’interfaccia classica.
_FILE_OFFSET_BITS
la definizione di questa macro al valore di 64 consente di attivare la conver-
sione automatica di tutti i riferimenti a dati e funzioni a 32 bit nelle funzioni
di interfaccia ai file con le equivalenti a 64 bit, senza dover utilizzare espli-
citamente l’interfaccia alternativa appena illustrata. In questo modo diventa
possibile usare le ordinarie funzioni per effettuare operazioni a 64 bit sui file
anche su sistemi a 32 bit.11
Se la macro non è definita o è definita con valore 32 questo comportamento
viene disabilitato, e sui sistemi a 32 bit verranno usate le ordinarie funzioni a
32 bit, non avendo più il supporto per file di grandi dimensioni. Su sistemi a
64 bit invece, dove il problema non sussiste, la macro non ha nessun effetto.
_ATFILE_SOURCE definendo questa macro si rendono disponibili le estensioni delle funzioni
di creazione, accesso e modifica di file e directory che risolvono i problemi
di sicurezza insiti nell’uso di pathname relativi con programmi multi-thread
illustrate in sez. 6.3.5.
_REENTRANT definendo questa macro, o la equivalente _THREAD_SAFE (fornita per compa-
tibilità) si rendono disponibili le versioni rientranti (vedi sez. 3.6.3) di alcune
funzioni, necessarie quando si usano i thread. Alcune di queste funzioni sono
anche previste nello standard POSIX.1c, ma ve ne sono altre che sono di-
sponibili soltanto su alcuni sistemi, o specifiche del glibc, e possono essere
utilizzate una volta definita la macro.
_FORTIFY_SOURCE
definendo questa macro viene abilitata l’inserimento di alcuni controlli per
alcune funzioni di allocazione e manipolazione di memoria e stringhe che
consentono di rilevare automaticamente alcuni errori di buffer overflow nel-
l’uso delle stesse. La funzionalità è stata introdotta a partire dalla versione
2.3.4 delle glibc e richiede anche il supporto da parte del compilatore, che è
disponibile solo a partire dalla versione 4.0 del gcc.
Le funzioni di libreria che vengono messe sotto controllo quando questa
funzionalità viene attivata sono, al momento della stesura di queste note,
le seguenti: memcpy, mempcpy, memmove, memset, stpcpy, strcpy, strncpy,
strcat, strncat, sprintf, snprintf, vsprintf, vsnprintf, e gets.
La macro prevede due valori, con 1 vengono eseguiti dei controlli di base che
non cambiano il comportamento dei programmi se si richiede una ottimiz-
zazione di livello uno o superiore,12 mentre con il valore 2 vengono aggiunti
maggiori controlli. Dato che alcuni dei controlli vengono effettuati in fase
di compilazione l’uso di questa macro richiede anche la collaborazione del
compilatore, disponibile dalla versione 4.0 del gcc.
11
basterà ricompilare il programma dopo averla definita, e saranno usate in modo trasparente le funzioni a 64
bit.
12
vale a dire se si usa l’opzione -O1 o superiore del gcc.

Se non è stata specificata esplicitamente nessuna di queste macro il default assunto è che
siano definite _BSD_SOURCE, _SVID_SOURCE, _POSIX_SOURCE e, con le glibc più recenti, che la
macro _POSIX_C_SOURCE abbia il valore “200809L”, per versioni precedenti delle glibc il valore
assegnato a _POSIX_C_SOURCE era di “200112L” prima delle 2.10, di “199506L” prima delle 2.4,
di “199506L” prima delle 2.1. Si ricordi infine che perché queste macro abbiano effetto devono
essere sempre definite prima dell’inclusione dei file di dichiarazione.

Capitolo 2
L’interfaccia base con i processi
Come accennato nell’introduzione il processo è l’unità di base con cui un sistema unix-like alloca
ed utilizza le risorse. Questo capitolo tratterà l’interfaccia base fra il sistema e i processi, come
vengono passati gli argomenti, come viene gestita e allocata la memoria, come un processo può
richiedere servizi al sistema e cosa deve fare quando ha finito la sua esecuzione. Nella sezione
finale accenneremo ad alcune problematiche generiche di programmazione.
In genere un programma viene eseguito quando un processo lo fa partire eseguendo una
funzione della famiglia exec; torneremo su questo e sulla creazione e gestione dei processi nel
prossimo capitolo. In questo affronteremo l’avvio e il funzionamento di un singolo processo
partendo dal punto di vista del programma che viene messo in esecuzione.
2.1 Esecuzione e conclusione di un programma
Uno dei concetti base di Unix è che un processo esegue sempre uno ed un solo programma: si
possono avere più processi che eseguono lo stesso programma ma ciascun processo vedrà la sua
copia del codice (in realtà il kernel fa s`ı che tutte le parti uguali siano condivise), avrà un suo
spazio di indirizzi, variabili proprie e sarà eseguito in maniera completamente indipendente da
tutti gli altri.1
2.1.1 La funzione main
Quando un programma viene lanciato il kernel esegue un opportuno codice di avvio, usando il
programma ld-linux.so. Questo programma prima carica le librerie condivise che servono al
programma, poi effettua il collegamento dinamico del codice e alla fine lo esegue. Infatti, a meno
di non aver specificato il flag -static durante la compilazione, tutti i programmi in Linux sono
incompleti e necessitano di essere collegati alle librerie condivise quando vengono avviati. La
procedura è controllata da alcune variabili di ambiente e dal contenuto di /etc/ld.so.conf. I
dettagli sono riportati nella pagina di manuale di ld.so.
Il sistema fa partire qualunque programma chiamando la funzione main; sta al programma-
tore chiamare cos`ı la funzione principale del programma da cui si suppone iniziare l’esecuzione;
in ogni caso senza questa funzione lo stesso linker (si chiama cos`ı il programma che effettua i
collegamenti di cui sopra) darebbe luogo ad errori. Lo standard ISO C specifica che la funzione
main può non avere argomenti o prendere due argomenti che rappresentano gli argomenti passati
da linea di comando, in sostanza un prototipo che va sempre bene è il seguente:
int main (int argc , char *argv [])
1
questo non è del tutto vero nel caso di un programma multi-thread, ma la gestione dei thread in Linux sarà
trattata a parte in cap. 13.
19

20 CAPITOLO 2. L’INTERFACCIA BASE CON I PROCESSI
In realtà nei sistemi Unix esiste un altro modo per definire la funzione main, che prevede
la presenza di un terzo argomento, char *envp[], che fornisce (vedi sez. 2.3.3) l’ambiente del
programma; questa forma però non è prevista dallo standard POSIX.1 per cui se si vogliono
scrivere programmi portabili è meglio evitarla.
2.1.2 Come chiudere un programma
Normalmente un programma finisce quando la funzione main ritorna, una modalità equivalente di
chiudere il programma è quella di chiamare direttamente la funzione exit (che viene comunque
chiamata automaticamente quando main ritorna). Una forma alternativa è quella di chiama-
re direttamente la system call _exit, che restituisce il controllo direttamente alla funzione di
conclusione dei processi del kernel.
Oltre alla conclusione “normale” esiste anche la possibilità di una conclusione “anomala” del
programma a causa della ricezione di un segnale (tratteremo i segnali in cap. 9) o della chiamata
alla funzione abort; torneremo su questo in sez. 3.2.3.
Il valore di ritorno della funzione main, o quello usato nelle chiamate ad exit e _exit, viene
chiamato stato di uscita (o exit status) e passato al processo che aveva lanciato il programma
(in genere la shell). In generale si usa questo valore per fornire informazioni sulla riuscita o il
fallimento del programma; l’informazione è necessariamente generica, ed il valore deve essere
compreso fra 0 e 255.
La convenzione in uso pressoché universale è quella di restituire 0 in caso di successo e 1
in caso di fallimento; l’unica eccezione è per i programmi che effettuano dei confronti (come
diff), che usano 0 per indicare la corrispondenza, 1 per indicare la non corrispondenza e 2 per
indicare l’incapacità di effettuare il confronto. È opportuno adottare una di queste convenzioni a
seconda dei casi. Si tenga presente che se si raggiunge la fine della funzione main senza ritornare
esplicitamente si ha un valore di uscita indefinito, è pertanto consigliabile di concludere sempre
in maniera esplicita detta funzione.
Un’altra convenzione riserva i valori da 128 a 256 per usi speciali: ad esempio 128 viene
usato per indicare l’incapacità di eseguire un altro programma in un sottoprocesso. Benché
questa convenzione non sia universalmente seguita è una buona idea tenerne conto.
Si tenga presente inoltre che non è una buona idea usare il codice di errore restituito dalla
variabile errno (per i dettagli si veda sez. 8.5) come stato di uscita. In generale infatti una shell
non si cura del valore se non per vedere se è diverso da zero; inoltre il valore dello stato di uscita
è sempre troncato ad 8 bit, per cui si potrebbe incorrere nel caso in cui restituendo un codice
di errore 256, si otterrebbe uno stato di uscita uguale a zero, che verrebbe interpretato come un
successo.
In stdlib.h sono definite, seguendo lo standard POSIX, le due costanti EXIT_SUCCESS e
EXIT_FAILURE, da usare sempre per specificare lo stato di uscita di un processo. In Linux esse
sono poste rispettivamente ai valori di tipo int 0 e 1.
2.1.3 Le funzioni exit e _exit
Come accennato le funzioni usate per effettuare un’uscita“normale”da un programma sono due,
la prima è la funzione exit, che è definita dallo standard ANSI C ed il cui prototipo è:
#include <stdlib.h>
void exit(int status)
Causa la conclusione ordinaria del programma.
La funzione non ritorna. Il processo viene terminato.
La funzione exit è pensata per eseguire una conclusione pulita di un programma che usi
le librerie standard del C; essa esegue tutte le funzioni che sono state registrate con atexit

2.1. ESECUZIONE E CONCLUSIONE DI UN PROGRAMMA 21
e on_exit (vedi sez. 2.1.4), e chiude tutti gli stream effettuando il salvataggio dei dati sospe-
si (chiamando fclose, vedi sez. 7.2.1), infine passa il controllo al kernel chiamando _exit e
restituendo il valore di status come stato di uscita.
La system call _exit restituisce direttamente il controllo al kernel, concludendo immediata-
mente il processo; i dati sospesi nei buffer degli stream non vengono salvati e le eventuali funzioni
registrate con atexit e on_exit non vengono eseguite. Il prototipo della funzione è:
#include <unistd.h>
void _exit(int status)
Causa la conclusione immediata del programma.
La funzione non ritorna. Il processo viene terminato.
La funzione chiude tutti i file descriptor appartenenti al processo; si tenga presente che questo
non comporta il salvataggio dei dati bufferizzati degli stream, (torneremo sulle due interfacce
dei file a partire da cap. 4), fa s`ı che ogni figlio del processo sia adottato da init (vedi cap. 3),
manda un segnale SIGCHLD al processo padre (vedi sez. 9.2.6) ed infine ritorna lo stato di uscita
specificato in status che può essere raccolto usando la funzione wait (vedi sez. 3.2.4).
2.1.4 Le funzioni atexit e on_exit
Un’esigenza comune che si incontra nella programmazione è quella di dover effettuare una serie
di operazioni di pulizia (ad esempio salvare dei dati, ripristinare delle impostazioni, eliminare
dei file temporanei, ecc.) prima della conclusione di un programma. In genere queste operazioni
vengono fatte in un’apposita sezione del programma, ma quando si realizza una libreria diventa
antipatico dover richiedere una chiamata esplicita ad una funzione di pulizia al programmatore
che la utilizza.
È invece molto meno soggetto ad errori, e completamente trasparente all’utente, avere la
possibilità di effettuare automaticamente la chiamata ad una funzione che effettui tali operazioni
all’uscita dal programma. A questo scopo lo standard ANSI C prevede la possibilità di registrare
un certo numero di funzioni che verranno eseguite all’uscita dal programma (sia per la chiamata
ad exit che per il ritorno di main). La prima funzione che si può utilizzare a tal fine è atexit
il cui prototipo è:
#include <stdlib.h>
void atexit(void (*function)(void))
Registra la funzione function per la chiamata all’uscita dal programma.
La funzione restituisce 0 in caso di successo e −1 in caso di fallimento, errno non viene modificata.
la funzione richiede come argomento l’indirizzo di una opportuna funzione di pulizia da chiamare
all’uscita del programma, che non deve prendere argomenti e non deve ritornare niente (deve
essere cioè definita come void function(void)).
Un’estensione di atexit è la funzione on_exit, che le glibc includono per compatibilità con
SunOS, ma che non è detto sia definita su altri sistemi; il suo prototipo è:
#include <stdlib.h>
void on_exit(void (*function)(int , void *), void *arg)
Registra la funzione function per la chiamata all’uscita dal programma.
La funzione restituisce 0 in caso di successo e −1 in caso di fallimento, errno non viene modificata.
In questo caso la funzione da chiamare all’uscita prende i due argomenti specificati nel
prototipo, dovrà cioè essere definita come void function(int status, void *argp). Il primo
argomento sarà inizializzato allo stato di uscita con cui è stata chiamata exit ed il secondo al
puntatore arg passato come secondo argomento di on_exit. Cos`ı diventa possibile passare dei
dati alla funzione di chiusura.

Nella sequenza di chiusura tutte le funzioni registrate verranno chiamate in ordine inverso
rispetto a quello di registrazione (ed una stessa funzione registrata più volte sarà chiamata più
volte); poi verranno chiusi tutti gli stream aperti, infine verrà chiamata _exit.
2.1.5 Conclusioni
Data l’importanza dell’argomento è opportuno sottolineare ancora una volta che in un sistema
Unix l’unico modo in cui un programma può essere eseguito dal kernel è attraverso la chiamata
alla system call execve (o attraverso una delle funzioni della famiglia exec che vedremo in
sez. 3.2.5).
Allo stesso modo l’unico modo in cui un programma può concludere volontariamente la sua
esecuzione è attraverso una chiamata alla system call _exit, o esplicitamente, o in maniera
indiretta attraverso l’uso di exit o il ritorno di main.
Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude normalmente un
programma è riportato in fig. 2.1.
kernel
ld-linux.so
exec
main
_exit
funzione
_exit
exit
exit
exit
_exit
exit handler
exit handler
chiusura stream
Figura 2.1: Schema dell’avvio e della conclusione di un programma.
Si ricordi infine che un programma può anche essere interrotto dall’esterno attraverso l’uso
di un segnale (modalità di conclusione non mostrata in fig. 2.1); tratteremo nei dettagli i segnali
e la loro gestione nel capitolo 9.
2.2 I processi e l’uso della memoria
Una delle risorse base che ciascun processo ha a disposizione è la memoria, e la gestione della
memoria è appunto uno degli aspetti più complessi di un sistema unix-like. In questa sezione,
dopo una breve introduzione ai concetti base, esamineremo come la memoria viene vista da parte
di un programma in esecuzione, e le varie funzioni utilizzabili per la sua gestione.
2.2.1 I concetti generali
Ci sono vari modi in cui i sistemi operativi organizzano la memoria, ed i dettagli di basso livello
dipendono spesso in maniera diretta dall’architettura dell’hardware, ma quello più tipico, usato
dai sistemi unix-like come Linux è la cosiddetta memoria virtuale che consiste nell’assegnare ad

2.2. I PROCESSI E L’USO DELLA MEMORIA 23
ogni processo uno spazio virtuale di indirizzamento lineare, in cui gli indirizzi vanno da zero ad
un qualche valore massimo.2
Come accennato in cap. 1 questo spazio di indirizzi è virtuale e non corrisponde all’effettiva
posizione dei dati nella RAM del computer; in genere detto spazio non è neppure continuo
(cioè non tutti gli indirizzi possibili sono utilizzabili, e quelli usabili non sono necessariamente
adiacenti).
Per la gestione da parte del kernel la memoria viene divisa in pagine di dimensione fissa,3
e ciascuna pagina nello spazio di indirizzi virtuale è associata ad un supporto che può essere
una pagina di memoria reale o ad un dispositivo di stoccaggio secondario (come lo spazio disco
riservato alla swap, o i file che contengono il codice). Per ciascun processo il kernel si cura di
mantenere un mappa di queste corrispondenze nella cosiddetta page table.4
Una stessa pagina di memoria reale può fare da supporto a diverse pagine di memoria virtuale
appartenenti a processi diversi (come accade in genere per le pagine che contengono il codice
delle librerie condivise). Ad esempio il codice della funzione printf starà su una sola pagina di
memoria reale che farà da supporto a tutte le pagine di memoria virtuale di tutti i processi che
hanno detta funzione nel loro codice.
La corrispondenza fra le pagine della memoria virtuale di un processo e quelle della memoria
fisica della macchina viene gestita in maniera trasparente dal kernel.5 Poiché in genere la memoria
fisica è solo una piccola frazione della memoria virtuale, è necessario un meccanismo che permetta
di trasferire le pagine che servono dal supporto su cui si trovano in memoria, eliminando quelle
che non servono. Questo meccanismo è detto paginazione (o paging), ed è uno dei compiti
principali del kernel.
Quando un processo cerca di accedere ad una pagina che non è nella memoria reale, avviene
quello che viene chiamato un page fault; la gestione della memoria genera un’interruzione e
passa il controllo al kernel il quale sospende il processo e si incarica di mettere in RAM la pagina
richiesta (effettuando tutte le operazioni necessarie per reperire lo spazio necessario), per poi
restituire il controllo al processo.
Dal punto di vista di un processo questo meccanismo è completamente trasparente, e tutto
avviene come se tutte le pagine fossero sempre disponibili in memoria. L’unica differenza avver-
tibile è quella dei tempi di esecuzione, che passano dai pochi nanosecondi necessari per l’accesso
in RAM, a tempi molto più lunghi, dovuti all’intervento del kernel.
Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed in genere il
sistema è molto efficiente in questo lavoro; quando però ci siano esigenze specifiche di prestazioni
è possibile usare delle funzioni che permettono di bloccare il meccanismo della paginazione
e mantenere fisse delle pagine in memoria (vedi sez. 2.2.4). Inoltre per certe applicazioni gli
algoritmi di gestione della memoria
2.2.2 La struttura della memoria di un processo
Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo una parte di essi
è effettivamente allocato ed utilizzabile dal processo; il tentativo di accedere ad un indirizzo
non allocato è un tipico errore che si commette quando si è manipolato male un puntatore e
2
nel caso di Linux fino al kernel 2.2 detto massimo era, per macchine a 32bit, di 2Gb. Con il kernel 2.4 ed il
supporto per la high-memory il limite è stato esteso anche per macchine a 32 bit.
3
inizialmente questi erano di 4kb sulle macchine a 32 bit e di 8kb sulle alpha, con le versioni più recenti del
kernel è possibile anche utilizzare pagine di dimensioni maggiori (4Mb), per sistemi con grandi quantitativi di
memoria in cui l’uso di pagine troppo piccole comporta una perdita di prestazioni.
4
questa è una semplificazione brutale, il meccanismo è molto più complesso; una buona trattazione di come
Linux gestisce la memoria virtuale si trova su [4].
5
in genere con l’ausilio dell’hardware di gestione della memoria (la Memory Management Unit del processore),
con i kernel della serie 2.6 è comunque diventato possibile utilizzare Linux anche su architetture che non dispongono
di una MMU.

genera quella che viene chiamata una segment violation. Se si tenta cioè di leggere o scrivere
da un indirizzo per il quale non esiste un’associazione della pagina virtuale, il kernel risponde
al relativo page fault mandando un segnale SIGSEGV al processo, che normalmente ne causa la
terminazione immediata.
È pertanto importante capire come viene strutturata la memoria virtuale di un processo.
Essa viene divisa in segmenti, cioè un insieme contiguo di indirizzi virtuali ai quali il processo
può accedere. Solitamente un programma C viene suddiviso nei seguenti segmenti:
1. Il segmento di testo o text segment. Contiene il codice del programma, delle funzioni di
librerie da esso utilizzate, e le costanti. Normalmente viene condiviso fra tutti i processi
che eseguono lo stesso programma (e anche da processi che eseguono altri programmi nel
caso delle librerie). Viene marcato in sola lettura per evitare sovrascritture accidentali (o
maliziose) che ne modifichino le istruzioni.
Viene allocato da exec all’avvio del programma e resta invariato per tutto il tempo
dell’esecuzione.
2. Il segmento dei dati o data segment. Contiene le variabili globali (cioè quelle definite al di
fuori di tutte le funzioni che compongono il programma) e le variabili statiche (cioè quelle
dichiarate con l’attributo static). Di norma è diviso in due parti.
La prima parte è il segmento dei dati inizializzati, che contiene le variabili il cui valore è
stato assegnato esplicitamente. Ad esempio se si definisce:
double pi = 3.14;
questo valore sarà immagazzinato in questo segmento. La memoria di questo segmento
viene preallocata all’avvio del programma e inizializzata ai valori specificati.
La seconda parte è il segmento dei dati non inizializzati, che contiene le variabili il cui
valore non è stato assegnato esplicitamente. Ad esempio se si definisce:
int vect [100];
questo vettore sarà immagazzinato in questo segmento. Anch’esso viene allocato all’avvio,
e tutte le variabili vengono inizializzate a zero (ed i puntatori a NULL).6
Storicamente questa seconda parte del segmento dati viene chiamata BSS (da Block Started
by Symbol). La sua dimensione è fissa.
3. Lo heap. Tecnicamente lo si può considerare l’estensione del segmento dati, a cui di solito è
posto giusto di seguito. È qui che avviene l’allocazione dinamica della memoria; può essere
ridimensionato allocando e disallocando la memoria dinamica con le apposite funzioni (vedi
sez. 2.2.3), ma il suo limite inferiore (quello adiacente al segmento dati) ha una posizione
fissa.
4. Il segmento di stack, che contiene quello che viene chiamato stack del programma. Tutte
le volte che si effettua una chiamata ad una funzione è qui che viene salvato l’indirizzo
di ritorno e le informazioni dello stato del chiamante (tipo il contenuto di alcuni registri
della CPU), poi la funzione chiamata alloca qui lo spazio per le sue variabili locali. Tutti
questi dati vengono impilati (da questo viene il nome stack) in sequenza uno sull’altro; in
questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno della funzione
lo spazio è automaticamente rilasciato e “ripulito”.7
6
si ricordi che questo vale solo per le variabili che vanno nel segmento dati, e non è affatto vero in generale.
7
il compilatore si incarica di generare automaticamente il codice necessario, seguendo quella che viene chiamata
una calling convention; quella standard usata con il C ed il C++ è detta cdecl e prevede che gli argomenti siano

La dimensione di questo segmento aumenta seguendo la crescita dello stack del programma,
ma non viene ridotta quando quest’ultimo si restringe.
text
dati inizializzati
dati non inizializzati
heap
stack
environment
0x08000000
0x08xxxxxx
0xC0000000
Figura 2.2: Disposizione tipica dei segmenti di memoria di un processo.
Una disposizione tipica dei vari segmenti (testo, heap, stack, ecc.) è riportata in fig. 2.2.
Usando il comando size su un programma se ne può stampare le dimensioni dei segmenti di
testo e di dati (inizializzati e BSS); si tenga presente però che il BSS non è mai salvato sul file che
contiene l’eseguibile, dato che viene sempre inizializzato a zero al caricamento del programma.
2.2.3 Allocazione della memoria per i programmi C
Il C supporta direttamente, come linguaggio di programmazione, soltanto due modalità di
allocazione della memoria: l’allocazione statica e l’allocazione automatica.
L’allocazione statica è quella con cui sono memorizzate le variabili globali e le variabili
statiche, cioè le variabili il cui valore deve essere mantenuto per tutta la durata del programma.
Come accennato queste variabili vengono allocate nel segmento dei dati all’avvio del programma
(come parte delle operazioni svolte da exec) e lo spazio da loro occupato non viene liberato fino
alla sua conclusione.
L’allocazione automatica è quella che avviene per gli argomenti di una funzione e per le
sue variabili locali (le cosiddette variabili automatiche), che esistono solo per la durata della
funzione. Lo spazio per queste variabili viene allocato nello stack quando viene eseguita la
funzione e liberato quando si esce dalla medesima.
caricati nello stack dal chiamante da destra a sinistra, e che sia il chiamante stesso ad eseguire la ripulitura dello
stack al ritorno della funzione, se ne possono però utilizzare di alternative (ad esempio nel Pascal gli argomenti
sono inseriti da sinistra a destra ed è compito del chiamato ripulire lo stack), in genere non ci si deve preoccupare
di questo fintanto che non si mescolano funzioni scritte con linguaggi diversi.

Esiste però un terzo tipo di allocazione, l’allocazione dinamica della memoria, che non è
prevista direttamente all’interno del linguaggio C, ma che è necessaria quando il quantitativo di
memoria che serve è determinabile solo durante il corso dell’esecuzione del programma.
Il C non consente di usare variabili allocate dinamicamente, non è possibile cioè definire in fase
di programmazione una variabile le cui dimensioni possano essere modificate durante l’esecuzione
del programma. Per questo le librerie del C forniscono una serie opportuna di funzioni per
eseguire l’allocazione dinamica di memoria (in genere nello heap).
Le variabili il cui contenuto è allocato in questo modo non potranno essere usate direttamente
come le altre (quelle nello stack), ma l’accesso sarà possibile solo in maniera indiretta, attraverso
i puntatori alla memoria loro riservata che si sono ottenuti dalle funzioni di allocazione.
Le funzioni previste dallo standard ANSI C per la gestione della memoria sono quattro:
malloc, calloc, realloc e free, i loro prototipi sono i seguenti:
#include <stdlib.h>
void *calloc(size_t nmemb, size_t size)
Alloca nello heap un’area di memoria per un vettore di nmemb membri di size byte di
dimensione. La memoria viene inizializzata a 0.
La funzione restituisce il puntatore alla zona di memoria allocata in caso di successo e NULL
in caso di fallimento, nel qual caso errno assumerà il valore ENOMEM.
void *malloc(size_t size)
Alloca size byte nello heap. La memoria non viene inizializzata.
void *realloc(void *ptr, size_t size)
Cambia la dimensione del blocco allocato all’indirizzo ptr portandola a size.
void free(void *ptr)
Disalloca lo spazio di memoria puntato da ptr.
La funzione non ritorna nulla e non riporta errori.
Il puntatore ritornato dalle funzioni di allocazione è garantito essere sempre allineato cor-
rettamente per tutti i tipi di dati; ad esempio sulle macchine a 32 bit in genere è allineato a
multipli di 4 byte e sulle macchine a 64 bit a multipli di 8 byte.
In genere si usano le funzioni malloc e calloc per allocare dinamicamente la quantità di
memoria necessaria al programma indicata da size,8 e siccome i puntatori ritornati sono di tipo
generico non è necessario effettuare un cast per assegnarli a puntatori al tipo di variabile per la
quale si effettua l’allocazione.
La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando free9 una
volta che non sia più necessaria. Questa funzione vuole come argomento un puntatore restitui-
to da una precedente chiamata a una qualunque delle funzioni di allocazione che non sia già
stato liberato da un’altra chiamata a free, in caso contrario il comportamento della funzione è
indefinito.
La funzione realloc si usa invece per cambiare (in genere aumentare) la dimensione di
un’area di memoria precedentemente allocata, la funzione vuole in ingresso il puntatore restituito
dalla precedente chiamata ad una malloc (se è passato un valore NULL allora la funzione si
comporta come malloc)10 ad esempio quando si deve far crescere la dimensione di un vettore. In
8
queste funzioni presentano un comportamento diverso fra le glibc e le uClib quando il valore di size è nullo.
Nel primo caso viene comunque restituito un puntatore valido, anche se non è chiaro a cosa esso possa fare
riferimento, nel secondo caso viene restituito NULL. Il comportamento è analogo con realloc(NULL, 0).
9
le glibc provvedono anche una funzione cfree definita per compatibilità con SunOS, che è deprecata.
10
questo è vero per Linux e l’implementazione secondo lo standard ANSI C, ma non è vero per alcune vecchie
implementazioni, inoltre alcune versioni delle librerie del C consentivano di usare realloc anche per un puntatore
liberato con free purché non ci fossero state nel frattempo altre chiamate a funzioni di allocazione, questa
funzionalità è totalmente deprecata e non è consentita sotto Linux.

questo caso se è disponibile dello spazio adiacente al precedente la funzione lo utilizza, altrimenti
rialloca altrove un blocco della dimensione voluta, copiandoci automaticamente il contenuto; lo
spazio aggiunto non viene inizializzato.
Si deve sempre avere ben presente il fatto che il blocco di memoria restituito da realloc
può non essere un’estensione di quello che gli si è passato in ingresso; per questo si dovrà
sempre eseguire la riassegnazione di ptr al valore di ritorno della funzione, e reinizializzare o
provvedere ad un adeguato aggiornamento di tutti gli altri puntatori all’interno del blocco di
dati ridimensionato.
Un errore abbastanza frequente (specie se si ha a che fare con vettori di puntatori) è quello di
chiamare free più di una volta sullo stesso puntatore; per evitare questo problema una soluzione
di ripiego è quella di assegnare sempre a NULL ogni puntatore liberato con free, dato che, quando
l’argomento è un puntatore nullo, free non esegue nessuna operazione.
Le glibc hanno un’implementazione delle funzioni di allocazione che è controllabile dall’utente
attraverso alcune variabili di ambiente (vedi sez. 2.3.3), in particolare diventa possibile tracciare
questo tipo di errori usando la variabile di ambiente MALLOC_CHECK_ che quando viene definita
mette in uso una versione meno efficiente delle funzioni suddette, che però è più tollerante nei
confronti di piccoli errori come quello di chiamate doppie a free. In particolare:
• se la variabile è posta a zero gli errori vengono ignorati;
• se è posta ad 1 viene stampato un avviso sullo standard error (vedi sez. 7.1.3);
• se è posta a 2 viene chiamata abort, che in genere causa l’immediata conclusione del
programma.
Il problema più comune e più difficile da risolvere che si incontra con le funzioni di allocazione
è quando non viene opportunamente liberata la memoria non più utilizzata, quello che in inglese
viene chiamato memory leak, cioè una perdita di memoria.
Un caso tipico che illustra il problema è quello in cui in una subroutine si alloca della me-
moria per uso locale senza liberarla prima di uscire. La memoria resta cos`ı allocata fino alla
terminazione del processo. Chiamate ripetute alla stessa subroutine continueranno ad effettua-
re altre allocazioni, causando a lungo andare un esaurimento della memoria disponibile (e la
probabile impossibilità di proseguire l’esecuzione del programma).
Il problema è che l’esaurimento della memoria può avvenire in qualunque momento, in cor-
rispondenza ad una qualunque chiamata di malloc che può essere in una sezione del codice che
non ha alcuna relazione con la subroutine che contiene l’errore. Per questo motivo è sempre
molto difficile trovare un memory leak.
In C e C++ il problema è particolarmente sentito. In C++, per mezzo della programmazione
ad oggetti, il problema dei memory leak è notevolmente ridimensionato attraverso l’uso accurato
di appositi oggetti come gli smartpointers. Questo però in genere va a scapito delle prestazioni
dell’applicazione in esecuzione.
Per limitare l’impatto di questi problemi, e semplificare la ricerca di eventuali errori, l’imple-
mentazione delle funzioni di allocazione delle glibc mette a disposizione una serie di funzionalità
che permettono di tracciare le allocazioni e le disallocazioni, e definisce anche una serie di pos-
sibili hook (ganci) che permettono di sostituire alle funzioni di libreria una propria versione
(che può essere più o meno specializzata per il debugging). Esistono varie librerie che forniscono
dei sostituti opportuni delle funzioni di allocazione in grado, senza neanche ricompilare il pro-
gramma,11 di eseguire diagnostiche anche molto complesse riguardo l’allocazione della memoria.
Vedremo alcune delle funzionalità di ausilio presenti nelle glibc in sez. 2.2.5.
Una possibile alternativa all’uso di malloc, per evitare di soffrire dei problemi di memory leak
descritti in precedenza, è di allocare la memoria nel segmento di stack della funzione corrente
11
esempi sono Dmalloc http://dmalloc.com/ di Gray Watson ed Electric Fence di Bruce Perens.

invece che nello heap, per farlo si può usare la funzione alloca, la cui sintassi è identica a quella
di malloc; il suo prototipo è:
#include <stdlib.h>
void *alloca(size_t size)
Alloca size byte nello stack.
La funzione restituisce il puntatore alla zona di memoria allocata.
La funzione alloca la quantità di memoria (non inizializzata) richiesta dall’argomento size
nel segmento di stack della funzione chiamante. Con questa funzione non è più necessario liberare
la memoria allocata (e quindi non esiste un analogo della free) in quanto essa viene rilasciata
automaticamente al ritorno della funzione.
Come è evidente questa funzione ha molti vantaggi, anzitutto permette di evitare alla radice i
problemi di memory leak, dato che non serve più la deallocazione esplicita; inoltre la deallocazione
automatica funziona anche quando si usa longjmp per uscire da una subroutine con un salto
non locale da una funzione (vedi sez. 2.4.4).
Un altro vantaggio è che in Linux la funzione è molto più veloce di malloc e non viene sprecato
spazio, infatti non è necessario gestire un pool di memoria da riservare e si evitano cos`ı anche
i problemi di frammentazione di quest’ultimo, che comportano inefficienze sia nell’allocazione
della memoria che nell’esecuzione dell’allocazione.
Gli svantaggi sono che questa funzione non è disponibile su tutti gli Unix, e non è inserita
né nello standard POSIX né in SUSv3 (ma è presente in BSD), il suo utilizzo quindi limita la
portabilità dei programmi. Inoltre la funzione non può essere usata nella lista degli argomenti
di una funzione, perché lo spazio verrebbe allocato nel mezzo degli stessi.
Inoltre non è chiaramente possibile usare alloca per allocare memoria che deve poi essere
usata anche al di fuori della funzione in cui essa viene chiamata, dato che all’uscita dalla funzione
lo spazio allocato diventerebbe libero, e potrebbe essere sovrascritto all’invocazione di nuove
funzioni. Questo è lo stesso problema che si può avere con le variabili automatiche, su cui
torneremo in sez. 2.4.3.
Infine non esiste un modo di sapere se l’allocazione ha avuto successo, la funzione infatti viene
realizzata inserendo del codice inline nel programma12 che si limita a modificare il puntatore
nello stack e non c’è modo di sapere se se ne sono superate le dimensioni, per cui in caso di
fallimento nell’allocazione il comportamento del programma può risultare indefinito, dando luogo
ad una segment violation la prima volta che cercherà di accedere alla memoria non effettivamente
disponibile.
Le due funzioni seguenti13 vengono utilizzate soltanto quando è necessario effettuare diretta-
mente la gestione della memoria associata allo spazio dati di un processo, ad esempio qualora si
debba implementare la propria versione delle funzioni di allocazione della memoria. Per poterle
utilizzare è necessario definire una della macro di funzionalità (vedi sez. 1.2.7) fra _BSD_SOURCE,
_SVID_SOURCE e _XOPEN_SOURCE (ad un valore maggiore o uguale di 500). La prima funzione è
brk, ed il suo prototipo è:
#include <unistd.h>
int brk(void *end_data_segment)
Sposta la fine del segmento dei dati.
La funzione restituisce 0 in caso di successo e −1 in caso di fallimento, nel qual caso errno assumerà
il valore ENOMEM.
La funzione è un’interfaccia all’omonima system call ed imposta l’indirizzo finale del segmento
dati di un processo all’indirizzo specificato da end_data_segment. Quest’ultimo deve essere un
12
questo comporta anche il fatto che non è possibile sostituirla con una propria versione o modificarne il
comportamento collegando il proprio programma con un’altra libreria.
13
le due funzioni sono state definite con BSD 4.3, sono marcate obsolete in SUSv2 e non fanno parte delle
librerie standard del C e mentre sono state esplicitamente rimosse dallo standard POSIX/1-2001.

valore ragionevole, ed inoltre la dimensione totale del segmento non deve comunque eccedere
un eventuale limite (si veda sez. 8.3.2) imposto sulle dimensioni massime dello spazio dati del
processo.
Il valore di ritorno della funzione fa riferimento alla versione fornita dalle glibc, in realtà
in Linux la system call corrispondente restituisce come valore di ritorno il nuovo valore della
fine del segmento dati in caso di successo e quello corrente in caso di fallimento, è la funzione
di interfaccia usata dalle glibc che fornisce i valori di ritorno appena descritti, questo può non
accadere se si usano librerie diverse.
Una seconda funzione per la manipolazione diretta delle dimensioni del segmento dati14 è
sbrk, ed il suo prototipo è:
#include <unistd.h>
void *sbrk(ptrdiff_t increment)
Incrementa la dimensione dello spazio dati.
La funzione restituisce il puntatore all’inizio della nuova zona di memoria allocata in caso di
successo e NULL in caso di fallimento, nel qual caso errno assumerà il valore ENOMEM.
la funzione incrementa la dimensione lo spazio dati di un programma di increment byte, re-
stituendo il nuovo indirizzo finale dello stesso. Un valore nullo permette di ottenere l’attuale
posizione della fine del segmento dati.
Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e per i programmi
normali è sempre opportuno usare le funzioni di allocazione standard descritte in precedenza,
che sono costruite su di esse.
2.2.4 Il controllo della memoria virtuale
Come spiegato in sez. 2.2.1 il kernel gestisce la memoria virtuale in maniera trasparente ai
processi, decidendo quando rimuovere pagine dalla memoria per metterle nello swap, sulla base
dell’utilizzo corrente da parte dei vari processi.
Nell’uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il meccanismo
della paginazione riporta in RAM, ed in maniera trasparente, tutte le pagine che gli occorrono;
esistono però esigenze particolari in cui non si vuole che questo meccanismo si attivi. In generale
i motivi per cui si possono avere di queste necessità sono due:
• La velocità. Il processo della paginazione è trasparente solo se il programma in esecuzione
non è sensibile al tempo che occorre a riportare la pagina in memoria; per questo mo-
tivo processi critici che hanno esigenze di tempo reale o tolleranze critiche nelle risposte
(ad esempio processi che trattano campionamenti sonori) possono non essere in grado di
sopportare le variazioni della velocità di accesso dovuta alla paginazione.
In certi casi poi un programmatore può conoscere meglio dell’algoritmo di allocazione
delle pagine le esigenze specifiche del suo programma e decidere quali pagine di memoria è
opportuno che restino in memoria per un aumento delle prestazioni. In genere queste sono
esigenze particolari e richiedono anche un aumento delle priorità in esecuzione del processo
(vedi sez. 3.4.3).
• La sicurezza. Se si hanno password o chiavi segrete in chiaro in memoria queste possono
essere portate su disco dal meccanismo della paginazione. Questo rende più lungo il periodo
di tempo in cui detti segreti sono presenti in chiaro e più complessa la loro cancellazione
(un processo può cancellare la memoria su cui scrive le sue variabili, ma non può toccare
lo spazio disco su cui una pagina di memoria può essere stata salvata). Per questo motivo
di solito i programmi di crittografia richiedono il blocco di alcune pagine di memoria.
14
in questo caso si tratta soltanto di una funzione di libreria, e non di una system call.

Per ottenere informazioni sulle modalità in cui un programma sta usando la memoria virtuale
è disponibile una apposita funzione, mincore, che però non è standardizzata da POSIX e pertanto
non è disponibile su tutte le versioni di kernel unix-like;15 il suo prototipo è:
#include <unistd.h>
#include <sys/mman.h>
int mincore(void *addr, size_t length, unsigned char *vec)
Ritorna lo stato delle pagine di memoria occupate da un processo.
La funzione ritorna 0 in caso di successo e −1 in caso di errore, nel qual caso errno assumerà uno
dei valori seguenti:
ENOMEM o addr + length eccede la dimensione della memoria usata dal processo o l’intervallo
di indirizzi specificato non è mappato.
EINVAL addr non è un multiplo delle dimensioni di una pagina.
EFAULT vec punta ad un indirizzo non valido.
EAGAIN il kernel è temporaneamente non in grado di fornire una risposta.
La funzione permette di ottenere le informazioni sullo stato della mappatura della memoria
per il processo chiamante, specificando l’intervallo da esaminare con l’indirizzo iniziale (indicato
con l’argomento addr) e la lunghezza (indicata con l’argomento length). L’indirizzo iniziale deve
essere un multiplo delle dimensioni di una pagina, mentre la lunghezza può essere qualunque,
fintanto che si resta nello spazio di indirizzi del processo,16 ma il risultato verrà comunque fornito
per l’intervallo compreso fino al multiplo successivo.
I risultati della funzione vengono forniti nel vettore puntato da vec, che deve essere allocato
preventivamente e deve essere di dimensione sufficiente a contenere tanti byte quante sono le
pagine contenute nell’intervallo di indirizzi specificato.17 Al ritorno della funzione il bit meno
significativo di ciascun byte del vettore sarà acceso se la pagina di memoria corrispondente è
al momento residente in memoria, o cancellato altrimenti. Il comportamento sugli altri bit è
indefinito, essendo questi al momento riservati per usi futuri. Per questo motivo in genere è
comunque opportuno inizializzare a zero il contenuto del vettore, cos`ı che le pagine attualmente
residenti in memoria saranno indicata da un valore non nullo del byte corrispondente.
Dato che lo stato della memoria di un processo può cambiare continuamente, il risultato
di mincore è assolutamente provvisorio e lo stato delle pagine potrebbe essere già cambiato al
ritorno stesso della funzione, a meno che, come vedremo ora, non si sia attivato il meccanismo
che forza il mantenimento di una pagina sulla memoria.
Il meccanismo che previene la paginazione di parte della memoria virtuale di un processo è
chiamato memory locking (o blocco della memoria). Il blocco è sempre associato alle pagine della
memoria virtuale del processo, e non al segmento reale di RAM su cui essa viene mantenuta. La
regola è che se un segmento di RAM fa da supporto ad almeno una pagina bloccata allora esso
viene escluso dal meccanismo della paginazione. I blocchi non si accumulano, se si blocca due
volte la stessa pagina non è necessario sbloccarla due volte, una pagina o è bloccata oppure no.
Il memory lock persiste fintanto che il processo che detiene la memoria bloccata non la
sblocca. Chiaramente la terminazione del processo comporta anche la fine dell’uso della sua
memoria virtuale, e quindi anche di tutti i suoi memory lock. Infine i memory lock non sono
ereditati dai processi figli,18 e vengono automaticamente rimossi se si pone in esecuzione un altro
programma con exec (vedi sez. 3.2.5).
15
nel caso di Linux devono essere comunque definite le macro _BSD_SOURCE e _SVID_SOURCE.
16
in caso contrario si avrà un errore di ENOMEM; fino al kernel 2.6.11 in questo caso veniva invece restituito
EINVAL, in considerazione che il caso più comune in cui si verifica questo errore è quando si usa per sbaglio un
valore negativo di length, che nel caso verrebbe interpretato come un intero positivo di grandi dimensioni.
17
la dimensione cioè deve essere almeno pari a (length+PAGE_SIZE-1)/PAGE_SIZE.
18
ma siccome Linux usa il copy on write (vedi sez. 3.2.2) gli indirizzi virtuali del figlio sono mantenuti sullo
stesso segmento di RAM del padre, quindi fintanto che un figlio non scrive su un segmento, può usufruire del
memory lock del padre.

Siccome la richiesta di un memory lock da parte di un processo riduce la memoria fisica
disponibile nel sistema, questo ha un evidente impatto su tutti gli altri processi, per cui fino al
kernel 2.6.9 solo un processo con i privilegi opportuni (la capability CAP_IPC_LOCK, vedi sez. 5.4.4)
aveva la capacità di bloccare una pagina.
Il sistema pone dei limiti all’ammontare di memoria di un processo che può essere bloccata
e al totale di memoria fisica che si può dedicare a questo, lo standard POSIX.1 richiede che
sia definita in unistd.h la macro _POSIX_MEMLOCK_RANGE per indicare la capacità di eseguire
il memory locking. Inoltre in alcuni sistemi è definita la costante PAGE_SIZE in limits.h per
indicare la dimensione di una pagina in byte.19
A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria memoria20 ma
mentre un processo privilegiato non ha limiti sulla quantità di memoria che può bloccare, un
processo normale è soggetto al limite della risorsa RLIMIT_MEMLOCK (vedi sez. 8.3.2). In generale
poi ogni processo può sbloccare le pagine relative alla propria memoria, se però diversi processi
bloccano la stessa pagina questa resterà bloccata fintanto che ci sarà almeno un processo che la
blocca.
Le funzioni per bloccare e sbloccare la paginazione di singole sezioni di memoria sono mlock
e munlock; i loro prototipi sono:
int mlock(const void *addr, size_t len)
Blocca la paginazione su un intervallo di memoria.
int munlock(const void *addr, size_t len)
Rimuove il blocco della paginazione su un intervallo di memoria.
Entrambe le funzioni ritornano 0 in caso di successo e −1 in caso di errore, nel qual caso errno
assumerà uno dei valori seguenti:
ENOMEM alcuni indirizzi dell’intervallo specificato non corrispondono allo spazio di indirizzi del
processo o si è ecceduto il numero massimo consentito di pagine bloccate.
EINVAL len non è un valore positivo.
EPERM con un kernel successivo al 2.6.9 il processo non è privilegiato e si un limite nullo per
RLIMIT_MEMLOCK.
e, per mlock, anche EPERM quando il processo non ha i privilegi richiesti per l’operazione.
Le due funzioni permettono rispettivamente di bloccare e sbloccare la paginazione per l’in-
tervallo di memoria specificato dagli argomenti, che ne indicano nell’ordine l’indirizzo iniziale e
la lunghezza. Tutte le pagine che contengono una parte dell’intervallo bloccato sono mantenute
in RAM per tutta la durata del blocco.21
Altre due funzioni, mlockall e munlockall, consentono di bloccare genericamente la pagi-
nazione per l’intero spazio di indirizzi di un processo. I prototipi di queste funzioni sono:
int mlockall(int flags)
Blocca la paginazione per lo spazio di indirizzi del processo corrente.
int munlockall(void)
Sblocca la paginazione per lo spazio di indirizzi del processo corrente.
Codici di ritorno ed errori sono gli stessi di mlock e munlock, con un kernel successivo al 2.6.9
l’uso di munlockall senza la capability CAP_IPC_LOCK genera un errore di EPERM.
L’argomento flags di mlockall permette di controllarne il comportamento; esso può essere
specificato come l’OR aritmetico delle due costanti:
19
con Linux questo non avviene e si deve ricorrere alla funzione getpagesize, vedi sez. 8.3.3.
20
la funzionalità è stata introdotta per non essere costretti a dare privilegi eccessivi a programmi di crittografia,
che necessitano di questa funzionalità, ma che devono essere usati da utenti normali.
21
con altri kernel si può ottenere un errore di EINVAL se addr non è un multiplo della dimensione delle pagine
di memoria.

MCL_CURRENT blocca tutte le pagine correntemente mappate nello spazio di indirizzi del pro-
cesso.
MCL_FUTURE blocca tutte le pagine che verranno mappate nello spazio di indirizzi del processo.
Con mlockall si possono bloccare tutte le pagine mappate nello spazio di indirizzi del pro-
cesso, sia che comprendano il segmento di testo, di dati, lo stack, lo heap e pure le funzioni di
libreria chiamate, i file mappati in memoria, i dati del kernel mappati in user space, la memoria
condivisa. L’uso dei flag permette di selezionare con maggior finezza le pagine da bloccare, ad
esempio limitandosi a tutte le pagine allocate a partire da un certo momento.
In ogni caso un processo real-time che deve entrare in una sezione critica deve provvedere
a riservare memoria sufficiente prima dell’ingresso, per scongiurare l’occorrenza di un eventuale
page fault causato dal meccanismo di copy on write. Infatti se nella sezione critica si va ad
utilizzare memoria che non è ancora stata riportata in RAM si potrebbe avere un page fault
durante l’esecuzione della stessa, con conseguente rallentamento (probabilmente inaccettabile)
dei tempi di esecuzione.
In genere si ovvia a questa problematica chiamando una funzione che ha allocato una quantità
sufficientemente ampia di variabili automatiche, in modo che esse vengano mappate in RAM dallo
stack, dopo di che, per essere sicuri che esse siano state effettivamente portate in memoria, ci si
scrive sopra.
2.2.5 Gestione avanzata dell’allocazione della memoria
La trattazione delle funzioni di allocazione di sez. 2.2.3 si è limitata a coprire le esigenze generiche
di un programma, in cui non si hanno dei requisiti specifici e si lascia il controllo delle modalità di
allocazione alle funzioni di libreria. Tuttavia esistono una serie di casi in cui può essere necessario
avere un controllo più dettagliato delle modalità con cui la memoria viene allocata; nel qual caso
potranno venire in aiuto le funzioni trattate in questa sezione.
Le prime funzioni che tratteremo sono quelle che consentono di richiedere di allocare un
blocco di memoria “allineato” ad un multiplo una certa dimensione. Questo tipo di esigenza
emerge usualmente quando si devono allocare dei buffer da utilizzare per eseguire dell’I/O diretto
su dispositivi a blocchi. In questo caso infatti il trasferimento di dati viene eseguito per blocchi
di dimensione fissa, ed è richiesto che l’indirizzo di partenza del buffer sia un multiplo intero di
questa dimensione, usualmente 512 byte. In tal caso l’uso di malloc non è sufficiente, ed occorre
utilizzare una funzione specifica.
Tradizionalmente per rispondere a questa esigenza sono state create due funzioni diverse,
memalign e valloc, oggi obsolete; i rispettivi prototipi sono:
#include <malloc.h>
void *valloc(size_t size)
Alloca un blocco di memoria allineato alla dimensione di una pagina di memoria.
void *memalign(size_t boundary, size_t size)
Alloca un blocco di memoria allineato ad un multiplo di boundary.
Entrambe le funzioni ritornano un puntatore al blocco di memoria allocato in caso di successo e
NULL in caso di errore, nel qual caso errno assumerà uno dei valori seguenti:
ENOMEM non c’è memoria sufficiente per l’allocazione.
EINVAL boundary non è multiplo di due.
Le funzioni restituiscono il puntatore al buffer di memoria allocata, che per memalign sarà
un multiplo di boundary mentre per valloc un multiplo della dimensione di una pagina di
memoria. Nel caso della versione fornita dalle glibc la memoria allocata con queste funzioni deve
essere liberata con free, cosa che non è detto accada con altre implementazioni.

Nessuna delle due funzioni ha una chiara standardizzazione (nessuna delle due compare in
POSIX.1), ed inoltre ci sono indicazioni discordi sui file che ne contengono la definizione;22 per
questo motivo il loro uso è sconsigliato, essendo state sostituite dalla nuova posix_memalign,
che è stata standardizzata in POSIX.1d; il suo prototipo è:
#include <stdlib.h>
posix_memalign(void **memptr, size_t alignment, size_t size)
Alloca un buffer di memoria allineato ad un multiplo di alignment.
La funzione restituisce 0 in caso di successo e NULL in caso di fallimento, o uno dei due codici di
errore ENOMEM o EINVAL; errno non viene impostata.
La funzione restituisce il puntatore al buffer allocato all’indirizzo indicato da memptr. La
funzione fallisce nelle stesse condizioni delle due funzioni precedenti, ma a differenza di memalign
restituisce un codice di errore EINVAL anche se alignment non è un multiplo della la dimensione
di sizeof(void *). Come per le precedenti la memoria allocata con posix_memalign può essere
disallocata con free.23
Un secondo caso in cui risulta estremamente utile poter avere un maggior controllo delle
modalità di allocazione della memoria è quello in cui cercano errori di programmazione. Esempi
di questi errori sono chiamate doppie alla funzione free con lo stesso puntatore, o i cosiddetti
buffer overrun, cioè le scritture su un buffer oltre le dimensioni della sua allocazione,24 o i classici
memory leak.
Una prima funzionalità di ausilio nella ricerca di questi errori viene fornita dalla glibc tramite
l’uso della variabile di ambiente MALLOC_CHECK_. Quando questa viene definita al posto della
versione ordinaria delle funzioni di allocazione (malloc, calloc, realloc, e free) viene usata
una versione meno efficiente ma in grado di rilevare (e tollerare) alcuni degli errori più semplici,
come le doppie chiamate a free o i buffer overrun di un byte.25
In questo caso a seconda del valore assegnato a MALLOC_CHECK_ si avranno diversi comporta-
menti: con 0 l’errore sarà ignorato, con 1 verrà stampato un messaggio sullo standard error (vedi
sez. 7.1.3), con 2 verrà invocata la funzione abort (vedi sez. 9.3.4) che termina il programma,
con 3 viene sia stampato il messaggio d’errore che abortito il programma. In genere è opportuno
definire la variabile ad un valore diverso da zero che consente di rilevare un errore nel momento
in cui avviene.
Una modalità alternativa per effettuare dei controlli di consistenza sullo stato delle allocazioni
di memoria eseguite con malloc, anche questa fornita come estensione specifica (e non standard)
delle glibc, è quella di utilizzare la funzione mcheck, che deve essere chiamata prima di eseguire
qualunque allocazione con malloc; il suo prototipo è:
#include <mcheck.h>
mcheck(void (*abortfn) (enum mcheck_status status))
Attiva i controlli di consistenza delle allocazioni eseguite da malloc.
La funzione restituisce 0 in caso di successo e −1 in caso di fallimento; errno non viene impostata.
La funzione consente di registrare una funzione di emergenza, da passare come argomento,
che verrà eseguita tutte le volte che, in una successiva esecuzione di malloc, venissero trovate
delle inconsistenze, come delle operazioni di scrittura oltre i limiti dei buffer allocati. Per questo
motivo la funzione deve essere chiamata prima di qualunque allocazione di memoria, altrimenti
fallirà con un valore di ritorno pari a −1.
22
secondo SUSv2 valloc è definita in stdlib.h, mentre sia le glibc che le precedenti libc4 e libc5 la dichiarano
in malloc.h, lo stesso vale per memalign che in alcuni sistemi è dichiarata in stdlib.h.
23
che in questo caso è quanto richiesto dallo standard.
24
entrambe queste operazioni causano in genere la corruzione dei dati di controllo delle funzioni di allocazione,
che vengono anch’essi mantenuti nello heap per tenere traccia delle zone di memoria allocata.
25
uno degli errori più comuni, causato ad esempio dalla scrittura di una stringa di dimensione pari a quella del
buffer, in cui ci si dimentica dello zero di terminazione finale.

Se come argomento di mcheck si passa NULL verrà utilizzata una funzione predefinita che
stampa un messaggio di errore ed invoca la funzione abort (vedi sez. 9.3.4), altrimenti si dovrà
create una funzione personalizzata che verrà eseguita ricevendo un unico argomento di tipo
mcheck_status,26 un tipo enumerato che può assumere soltanto i valori di tab. 2.1.
Valore Significato
MCHECK_OK riportato (a mprobe) se nessuna inconsistenza è
presente.
MCHECK_DISABLED riportato (a mprobe) se si è chiamata mcheck dopo
aver già usato malloc.
MCHECK_HEAD i dati immediatamente precedenti il buffer sono
stati modificati, avviene in genere quando si de-
crementa eccessivamente il valore di un puntatore
scrivendo poi prima dell’inizio del buffer.
MCHECK_TAIL i dati immediatamente seguenti il buffer sono stati
modificati, succede quando si va scrivere oltre la
dimensione corretta del buffer.
MCHECK_FREE il buffer è già stato disallocato.
Tabella 2.1: Valori dello stato dell’allocazione di memoria ottenibili dalla funzione di terminazione installata con
mcheck.
Una volta che si sia chiamata mcheck con successo si può anche controllare esplicitamente lo
stato delle allocazioni (senza aspettare un errore nelle relative funzioni) utilizzando la funzione
mprobe, il cui prototipo è:
#include <mcheck.h>
enum mcheck_status mprobe(ptr)
Esegue un controllo di consistenza delle allocazioni.
La funzione restituisce un codice fra quelli riportati in tab.2.1.
La funzione richiede che si passi come argomento un puntatore ad un blocco di memoria
precedentemente allocato con malloc o realloc, e restituisce lo stesso codice di errore che si
avrebbe per la funzione di emergenza ad una successiva chiamata di una funzione di allocazione,
e poi i primi due codici che indicano rispettivamente quando tutto è a posto o il controllo non
è possibile per non aver chiamato mcheck in tempo.
2.3 Argomenti, ambiente ed altre proprietà di un processo
In questa sezione esamineremo le funzioni che permettono di gestire gli argomenti e le opzio-
ni, e quelle che consentono di manipolare ed utilizzare le variabili di ambiente. Accenneremo
infine alle modalità con cui si può gestire la localizzazione di un programma modificandone il
comportamento a seconda della lingua o del paese a cui si vuole faccia riferimento nelle sue
operazioni.
2.3.1 Il formato degli argomenti
Tutti i programmi hanno la possibilità di ricevere argomenti e opzioni quando vengono lanciati.
Il passaggio degli argomenti e delle opzioni è effettuato attraverso gli argomenti argc e argv
della funzione main, che vengono passati al programma dalla shell (o dal processo che esegue la
exec, secondo le modalità che vedremo in sez. 3.2.5) quando questo viene messo in esecuzione.
In genere il passaggio di argomenti ed opzioni ad un programma viene effettuato dalla shell,
che si incarica di leggere la linea di comando e di effettuarne la scansione (il cosiddetto parsing)
26
trattasi in sostanza di un codice di errore che la funzione di emergenza potrà utilizzare per prendere le
opportune azioni.

2.3. ARGOMENTI, AMBIENTE ED ALTRE PROPRIETÀ DI UN PROCESSO 35
per individuare le parole che la compongono, ciascuna delle quali potrà essere considerata un
argomento o un’opzione. Di norma per individuare le parole che andranno a costituire la lista
degli argomenti viene usato come carattere di separazione lo spazio o il tabulatore, ma la cosa
dipende ovviamente dalle modalità con cui si effettua la scansione.
argc = 5 argv[0] touch
argv[1] -r
argv[2] riferimento.txt
argv[3] -m
argv[4] questofile.txt
touch -r riferimento.txt -m questofile.txt
Figura 2.3: Esempio dei valori di argv e argc generati nella scansione di una riga di comando.
Indipendentemente da come viene eseguita, il risultato della scansione deve essere la co-
struzione del vettore di puntatori argv in cui si devono inserire in successione i puntatori alle
stringhe costituenti i vari argomenti ed opzioni, e della variabile argc che deve essere inizializzata
al numero di stringhe passate. Nel caso della shell questo comporta che il primo argomento sia
sempre il nome del programma; un esempio di questo meccanismo è mostrato in fig. 2.3.
2.3.2 La gestione delle opzioni
In generale un programma Unix riceve da linea di comando sia gli argomenti che le opzioni, queste
ultime sono standardizzate per essere riconosciute come tali: un elemento di argv che inizia con
il carattere ’-’ e che non sia un singolo ’-’ o un ’--’ viene considerato un’opzione. In genere
le opzioni sono costituite da una lettera singola (preceduta dal carattere ’-’) e possono avere o
no un parametro associato; un comando tipico può essere quello mostrato in fig. 2.3. In quel caso
le opzioni sono -r e -m e la prima vuole un parametro mentre la seconda no (questofile.txt
è un argomento del programma, non un parametro di -m).
Per gestire le opzioni all’interno dei argomenti a linea di comando passati in argv le librerie
standard del C forniscono la funzione getopt, che ha il seguente prototipo:
#include <unistd.h>
int getopt(int argc, char *const argv[], const char *optstring)
Esegue il parsing degli argomenti passati da linea di comando riconoscendo le possibili
opzioni segnalate con optstring.
Ritorna il carattere che segue l’opzione, ’:’ se manca un parametro all’opzione, ’?’ se l’opzione
è sconosciuta, e −1 se non esistono altre opzioni.
Questa funzione prende come argomenti le due variabili argc e argv passate a main ed una
stringa che indica quali sono le opzioni valide; la funzione effettua la scansione della lista degli
argomenti ricercando ogni stringa che comincia con - e ritorna ogni volta che trova un’opzione
valida.
La stringa optstring indica quali sono le opzioni riconosciute ed è costituita da tutti i
caratteri usati per identificare le singole opzioni, se l’opzione ha un parametro al carattere deve
essere fatto seguire un segno di due punti ’:’; nel caso di fig. 2.3 ad esempio la stringa di opzioni
avrebbe dovuto contenere r:m.
La modalità di uso di getopt è pertanto quella di chiamare più volte la funzione all’interno
di un ciclo, fintanto che essa non ritorna il valore −1 che indica che non ci sono più opzioni. Nel
caso si incontri un’opzione non dichiarata in optstring viene ritornato il carattere ’?’ mentre
se un’opzione che lo richiede non è seguita da un parametro viene ritornato il carattere ’:’,

infine se viene incontrato il valore ’--’ la scansione viene considerata conclusa, anche se vi sono
altri elementi di argv che cominciano con il carattere ’-’.
1 opterr = 0; /* don’t want writing to stderr */
2 while ( (i = getopt(argc , argv , "hp:c:e:")) != -1) {
3 switch (i) {
4 /*
5 * Handling options
6 */
7 case ’h’: /* help option */
8 printf("Wrong -h option usen");
9 usage ();
10 return -1;
11 break;
12 case ’c’: /* take wait time for children */
13 wait_child = strtol(optarg , NULL , 10); /* convert input */
14 break;
15 case ’p’: /* take wait time for children */
16 wait_parent = strtol(optarg , NULL , 10); /* convert input */
17 break;
18 case ’e’: /* take wait before parent exit */
19 wait_end = strtol(optarg , NULL , 10); /* convert input */
20 break;
21 case ’?’: /* unrecognized options */
22 printf("Unrecognized options -%cn",optopt );
23 usage ();
24 default: /* should not reached */
25 usage ();
26 }
27 }
28 debug("Optind %d, argc %dn",optind ,argc );
Figura 2.4: Esempio di codice per la gestione delle opzioni.
Quando la funzione trova un’opzione essa ritorna il valore numerico del carattere, in questo
modo si possono eseguire azioni specifiche usando uno switch; getopt inoltre inizializza alcune
variabili globali:
• char *optarg contiene il puntatore alla stringa parametro dell’opzione.
• int optind alla fine della scansione restituisce l’indice del primo elemento di argv che
non è un’opzione.
• int opterr previene, se posto a zero, la stampa di un messaggio di errore in caso di
riconoscimento di opzioni non definite.
• int optopt contiene il carattere dell’opzione non riconosciuta.
In fig. 2.4 è mostrata la sezione del programma ForkTest.c (che useremo nel prossimo
capitolo per effettuare dei test sulla creazione dei processi) deputata alla decodifica delle opzioni
a riga di comando.
Si può notare che si è anzitutto (1) disabilitata la stampa di messaggi di errore per opzioni
non riconosciute, per poi passare al ciclo per la verifica delle opzioni (2-27); per ciascuna delle
opzioni possibili si è poi provveduto ad un’azione opportuna, ad esempio per le tre opzioni che
prevedono un parametro si è effettuata la decodifica del medesimo (il cui indirizzo è contenuto
nella variabile optarg) avvalorando la relativa variabile (12-14, 15-17 e 18-20). Completato il
ciclo troveremo in optind l’indice in argv[] del primo degli argomenti rimanenti nella linea di
comando.

Normalmente getopt compie una permutazione degli elementi di argv cosicché alla fine
della scansione gli elementi che non sono opzioni sono spostati in coda al vettore. Oltre a questa
esistono altre due modalità di gestire gli elementi di argv; se optstring inizia con il carattere
’+’ (o è impostata la variabile di ambiente POSIXLY_CORRECT) la scansione viene fermata non
appena si incontra un elemento che non è un’opzione.
L’ultima modalità, usata quando un programma può gestire la mescolanza fra opzioni e
argomenti, ma se li aspetta in un ordine definito, si attiva quando optstring inizia con il
carattere ’-’. In questo caso ogni elemento che non è un’opzione viene considerato comunque
un’opzione e associato ad un valore di ritorno pari ad 1, questo permette di identificare gli
elementi che non sono opzioni, ma non effettua il riordinamento del vettore argv.
2.3.3 Le variabili di ambiente
Oltre agli argomenti passati a linea di comando esiste un’altra modalità che permette di trasfe-
rire ad un processo delle informazioni in modo da modificarne il comportamento. Ogni processo
infatti riceve dal sistema, oltre alle variabili argv e argc anche un ambiente (in inglese environ-
ment); questo viene espresso nella forma di una lista (chiamata environment list) delle cosiddette
variabili di ambiente, i valori di queste variabili possono essere poi usati dal programma.
Anche in questo caso la lista delle variabili di ambiente deve essere costruita ed utilizzata nella
chiamata alla funzione exec (torneremo su questo in sez. 3.2.5) quando questo viene lanciato.
Come per la lista degli argomenti anche questa lista è un vettore di puntatori a caratteri, ciascuno
dei quali punta ad una stringa, terminata da un NULL. A differenza di argv[] in questo caso non
si ha una lunghezza del vettore data da un equivalente di argc, ma la lista è terminata da un
puntatore nullo.
L’indirizzo della lista delle variabili di ambiente è passato attraverso la variabile globale
environ, che viene definita automaticamente per ciascun processo, e a cui si può accedere
attraverso una semplice dichiarazione del tipo:
extern char ** environ;
un esempio della struttura di questa lista, contenente alcune delle variabili più comuni che
normalmente sono definite dal sistema, è riportato in fig. 2.5.
Environment pointer Environment list Environment string
environ environ[0]
environ[1]
NULL
HOME=/home/piccardi
PATH=:/bin:/usr/bin
SHELL=/bin/bash
EDITOR=emacs
OSTYPE=linux-gnu
Figura 2.5: Esempio di lista delle variabili di ambiente.
Per convenzione le stringhe che definiscono l’ambiente sono tutte del tipo nome=valore ed
in questa forma che le funzioni di gestione che vedremo a breve se le aspettano, se pertanto
si dovesse costruire manualmente un ambiente si abbia cura di rispettare questa convenzione.
Inoltre alcune variabili, come quelle elencate in fig. 2.5, sono definite dal sistema per essere usate
da diversi programmi e funzioni: per queste c’è l’ulteriore convenzione di usare nomi espressi in
caratteri maiuscoli.27
Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è riservata alle
applicazioni e ad alcune funzioni di libreria; in genere esse costituiscono un modo comodo per
27
ma si tratta solo di una convenzione, niente vieta di usare caratteri minuscoli.

definire un comportamento specifico senza dover ricorrere all’uso di opzioni a linea di comando o
di file di configurazione. É di norma cura della shell, quando esegue un comando, passare queste
variabili al programma messo in esecuzione attraverso un uso opportuno delle relative chiamate
(si veda sez. 3.2.5).
La shell ad esempio ne usa molte per il suo funzionamento, come PATH per indicare la lista
delle directory in cui effettuare la ricerca dei comandi o PS1 per impostare il proprio prompt. Al-
cune di esse, come HOME, USER, ecc. sono invece definite al login (per i dettagli si veda sez. 10.1.4),
ed in genere è cura della propria distribuzione definire le opportune variabili di ambiente in uno
script di avvio. Alcune servono poi come riferimento generico per molti programmi, come EDITOR
che indica l’editor preferito da invocare in caso di necessità. Una in particolare, LANG, serve a
controllare la localizzazione del programma (su cui torneremo in sez. 2.3.4) per adattarlo alla
lingua ed alle convezioni dei vari paesi.
Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più comuni), come
riportato in tab. 2.2. GNU/Linux le supporta tutte e ne definisce anche altre, in particolare
poi alcune funzioni di libreria prevedono la presenza di specifiche variabili di ambiente che ne
modificano il comportamento, come quelle usate per indicare una localizzazione e quelle per
indicare un fuso orario; una lista più completa che comprende queste ed ulteriori variabili si può
ottenere con il comando man 7 environ.
Variabile POSIX XPG3 Linux Descrizione
USER • • • Nome utente
LOGNAME • • • Nome di login
HOME • • • Directory base dell’utente
LANG • • • Localizzazione
PATH • • • Elenco delle directory dei programmi
PWD • • • Directory corrente
SHELL • • • Shell in uso
TERM • • • Tipo di terminale
PAGER • • • Programma per vedere i testi
EDITOR • • • Editor preferito
BROWSER • • • Browser preferito
TMPDIR • • • Directory dei file temporanei
Tabella 2.2: Esempi delle variabili di ambiente più comuni definite da vari standard.
Lo standard ANSI C prevede l’esistenza di un ambiente, e pur non entrando nelle specifiche
di come sono strutturati i contenuti, definisce la funzione getenv che permette di ottenere i
valori delle variabili di ambiente; il suo prototipo è:
#include <stdlib.h>
char *getenv(const char *name)
Esamina l’ambiente del processo cercando una stringa che corrisponda a quella specificata
da name.
La funzione ritorna NULL se non trova nulla, o il puntatore alla stringa che corrisponde (di solito
nella forma NOME=valore).
Oltre a questa funzione di lettura, che è l’unica definita dallo standard ANSI C, nell’evolu-
zione dei sistemi Unix ne sono state proposte altre, da utilizzare per impostare e per cancellare
le variabili di ambiente. Uno schema delle funzioni previste nei vari standard e disponibili in
Linux è riportato in tab. 2.3.
In Linux28 sono definite tutte le funzioni elencate in tab. 2.3. La prima, getenv, l’abbiamo
appena esaminata; delle restanti le prime due, putenv e setenv, servono per assegnare nuove
variabili di ambiente, i loro prototipi sono i seguenti:
28
in realtà nelle libc4 e libc5 sono definite solo le prime quattro, clearenv è stata introdotta con le glibc 2.0.

Funzione ANSI C POSIX.1 XPG3 SVr4 BSD Linux
getenv • • • • • •
setenv – – – – • •
unsetenv – – – – • •
putenv – opz. • – • •
clearenv – opz. – – – •
Tabella 2.3: Funzioni per la gestione delle variabili di ambiente.
#include <stdlib.h>
int setenv(const char *name, const char *value, int overwrite)
Imposta la variabile di ambiente name al valore value.
int putenv(char *string)
Aggiunge la stringa string all’ambiente.
Entrambe le funzioni ritornano 0 in caso di successo e −1 per un errore, che è sempre ENOMEM.
La terza funzione della lista, unsetenv, serve a cancellare una variabile dall’ambiente, il suo
prototipo è:
#include <stdlib.h>
void unsetenv(const char *name)
Rimuove la variabile di ambiente name.
la funzione elimina ogni occorrenza della variabile specificata; se la variabile non esiste non
succede nulla. Non è prevista (dato che la funzione è void) nessuna segnalazione di errore.
Per modificare o aggiungere una variabile di ambiente si possono usare sia setenv che putenv.
La prima permette di specificare separatamente nome e valore della variabile di ambiente, inoltre
il valore di overwrite specifica il comportamento della funzione nel caso la variabile esista già,
sovrascrivendola se diverso da zero, lasciandola immutata se uguale a zero.
La seconda funzione prende come argomento una stringa analoga a quella restituita da ge-
tenv, e sempre nella forma NOME=valore. Se la variabile specificata non esiste la stringa sarà
aggiunta all’ambiente, se invece esiste il suo valore sarà impostato a quello specificato da string.
Si tenga presente che, seguendo lo standard SUSv2, le glibc successive alla versione 2.1.2
aggiungono string alla lista delle variabili di ambiente;29 pertanto ogni cambiamento alla stringa
in questione si riflette automaticamente sull’ambiente, e quindi si deve evitare di passare a questa
funzione una variabile automatica (per evitare i problemi esposti in sez. 2.4.3). Si tenga infine
presente che se si passa a putenv solo il nome di una variabile (cioè string è nella forma NAME
e non contiene un carattere ’=’) allora questa viene cancellata dall’ambiente.
Infine quando chiamata a putenv comporta la necessità di creare una nuova versione del
vettore environ questo sarà allocato automaticamente, ma la versione corrente sarà deallocata
solo se anch’essa è risultante da un’allocazione fatta in precedenza da un’altra putenv. Questo
avviene perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata ad exec (vedi
sez. 3.2.5) è piazzato nella memoria al di sopra dello stack, (vedi fig. 2.2) e non nello heap e quindi
non può essere deallocato. Inoltre la memoria associata alle variabili di ambiente eliminate non
viene liberata.
L’ultima funzione per la gestione dell’ambiente è clearenv, che viene usata per cancellare
completamente tutto l’ambiente; il suo prototipo è:
29
il comportamento è lo stesso delle vecchie libc4 e libc5; nelle glibc, dalla versione 2.0 alla 2.1.1, veniva invece
fatta una copia, seguendo il comportamento di BSD4.4; dato che questo può dar luogo a perdite di memoria e
non rispetta lo standard. Il comportamento è stato modificato a partire dalle 2.1.2, eliminando anche, sempre in
conformità a SUSv2, l’attributo const dal prototipo.

#include <stdlib.h>
int clearenv(void)
Cancella tutto l’ambiente.
la funzione restituisce 0 in caso di successo e un valore diverso da zero per un errore.
In genere si usa questa funzione in maniera precauzionale per evitare i problemi di sicurezza
connessi nel trasmettere ai programmi che si invocano un ambiente che può contenere dei dati
non controllati. In tal caso si provvede alla cancellazione di tutto l’ambiente per costruirne una
versione “sicura” da zero.
2.3.4 La localizzazione
Abbiamo accennato in sez. 2.3.3 come la variabile di ambiente LANG sia usata per indicare
ai processi il valore della cosiddetta localizzazione. Si tratta di una funzionalità fornita dalle
librerie di sistema30 che consente di gestire in maniera automatica sia la lingua in cui vengono
stampati i vari messaggi (come i messaggi associati agli errori che vedremo in sez. 8.5.2) che le
convenzioni usate nei vari paesi per una serie di aspetti come il formato dell’ora, quello delle
date, gli ordinamenti alfabetici, le espressioni della valute, ecc.
La localizzazione di un programma si può selezionare con la
In realtà perché un programma sia effettivamente localizzato non è sufficiente
2.4 Problematiche di programmazione generica
Benché questo non sia un libro di C, è opportuno affrontare alcune delle problematiche generali
che possono emergere nella programmazione e di quali precauzioni o accorgimenti occorre pren-
dere per risolverle. Queste problematiche non sono specifiche di sistemi unix-like o multitasking,
ma avendo trattato in questo capitolo il comportamento dei processi visti come entità a sé stanti,
le riportiamo qui.
2.4.1 Il passaggio delle variabili e dei valori di ritorno
Una delle caratteristiche standard del C è che le variabili vengono passate alle subroutine attra-
verso un meccanismo che viene chiamato by value (diverso ad esempio da quanto avviene con il
Fortran, dove le variabili sono passate, come suol dirsi, by reference, o dal C++ dove la modalità
del passaggio può essere controllata con l’operatore &).
Il passaggio di una variabile by value significa che in realtà quello che viene passato alla
subroutine è una copia del valore attuale di quella variabile, copia che la subroutine potrà
modificare a piacere, senza che il valore originale nella funzione chiamante venga toccato. In
questo modo non occorre preoccuparsi di eventuali effetti delle operazioni della subroutine sulla
variabile passata come argomento.
Questo però va inteso nella maniera corretta. Il passaggio by value vale per qualunque varia-
bile, puntatori compresi; quando però in una subroutine si usano dei puntatori (ad esempio per
scrivere in un buffer) in realtà si va a modificare la zona di memoria a cui essi puntano, per cui
anche se i puntatori sono copie, i dati a cui essi puntano sono sempre gli stessi, e le eventuali
modifiche avranno effetto e saranno visibili anche nella funzione chiamante.
Nella maggior parte delle funzioni di libreria e delle system call i puntatori vengono usati
per scambiare dati (attraverso buffer o strutture) e le variabili semplici vengono usate per speci-
ficare argomenti; in genere le informazioni a riguardo dei risultati vengono passate alla funzione
chiamante attraverso il valore di ritorno. È buona norma seguire questa pratica anche nella
programmazione normale.
30
prenderemo in esame soltanto il caso delle glibc.

2.4. PROBLEMATICHE DI PROGRAMMAZIONE GENERICA 41
Talvolta però è necessario che la funzione possa restituire indietro alla funzione chiamante un
valore relativo ad uno dei suoi argomenti. Per far questo si usa il cosiddetto value result argument,
si passa cioè, invece di una normale variabile, un puntatore alla stessa; vedremo alcuni esempi
di questa modalità nelle funzioni che gestiscono i socket (in sez. 16.2), in cui, per permettere al
kernel di restituire informazioni sulle dimensioni delle strutture degli indirizzi utilizzate, viene
usato questo meccanismo.
2.4.2 Il passaggio di un numero variabile di argomenti
Come vedremo nei capitoli successivi, non sempre è possibile specificare un numero fisso di
argomenti per una funzione. Lo standard ISO C prevede nella sua sintassi la possibilità di
definire delle variadic function che abbiano un numero variabile di argomenti, attraverso l’uso
nella dichiarazione della funzione dello speciale costrutto “...”, che viene chiamato ellipsis.
Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui dette funzioni
possono accedere ai loro argomenti. L’accesso viene pertanto realizzato a livello delle librerie
standard del C che provvedono gli strumenti adeguati. L’uso di una variadic function prevede
quindi tre punti:
• Dichiarare la funzione come variadic usando un prototipo che contenga una ellipsis.
• Definire la funzione come variadic usando la stessa ellipsis, ed utilizzare le apposite macro
che consentono la gestione di un numero variabile di argomenti.
• Invocare la funzione specificando prima gli argomenti fissi, ed a seguire quelli addizionali.
Lo standard ISO C prevede che una variadic function abbia sempre almeno un argomento
fisso; prima di effettuare la dichiarazione deve essere incluso l’apposito header file stdarg.h; un
esempio di dichiarazione è il prototipo della funzione execl che vedremo in sez. 3.2.5:
int execl(const char *path , const char *arg , ...);
in questo caso la funzione prende due argomenti fissi ed un numero variabile di altri argomenti
(che verranno a costituire gli elementi successivi al primo del vettore argv passato al nuovo
processo). Lo standard ISO C richiede inoltre che l’ultimo degli argomenti fissi sia di tipo self-
promoting31 il che esclude vettori, puntatori a funzioni e interi di tipo char o short (con segno
o meno). Una restrizione ulteriore di alcuni compilatori è di non dichiarare l’ultimo argomento
fisso come register.
Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti quando la si
va a definire. Gli argomenti fissi infatti hanno un loro nome, ma quelli variabili vengono indicati
in maniera generica dalla ellipsis.
L’unica modalità in cui essi possono essere recuperati è pertanto quella sequenziale; essi
verranno estratti dallo stack secondo l’ordine in cui sono stati scritti. Per fare questo in stdarg.h
sono definite delle apposite macro; la procedura da seguire è la seguente:
1. Inizializzare un puntatore alla lista degli argomenti di tipo va_list attraverso la macro
va_start.
2. Accedere ai vari argomenti opzionali con chiamate successive alla macro va_arg, la prima
chiamata restituirà il primo argomento, la seconda il secondo e cos`ı via.
3. Dichiarare la conclusione dell’estrazione degli argomenti invocando la macro va_end.
In generale è perfettamente legittimo richiedere meno argomenti di quelli che potrebbero
essere stati effettivamente forniti, e nella esecuzione delle va_arg ci si può fermare in qualunque
31
il linguaggio C prevede che quando si mescolano vari tipi di dati, alcuni di essi possano essere promossi per
compatibilità; ad esempio i tipi float vengono convertiti automaticamente a double ed i char e gli short ad int.
Un tipo self-promoting è un tipo che verrebbe promosso a sé stesso.

momento ed i restanti argomenti saranno ignorati; se invece si richiedono più argomenti di quelli
forniti si otterranno dei valori indefiniti. Nel caso del gcc l’uso di va_end è inutile, ma si consiglia
di usarla ugualmente per compatibilità. Le definizioni delle macro citate sono le seguenti:
#include <stdarg.h>
void va_start(va_list ap, last)
Inizializza il puntatore alla lista di argomenti ap; il parametro last deve essere l’ultimo
degli argomenti fissi.
type va_arg(va_list ap, type)
Restituisce il valore del successivo argomento opzionale, modificando opportunamente ap;
la macro richiede che si specifichi il tipo dell’argomento attraverso il parametro type che
deve essere il nome del tipo dell’argomento in questione. Il tipo deve essere self-promoting.
void va_end(va_list ap)
Conclude l’uso di ap.
In generale si possono avere più puntatori alla lista degli argomenti, ciascuno andrà inizia-
lizzato con va_start e letto con va_arg e ciascuno potrà scandire la lista degli argomenti per
conto suo. Dopo l’uso di va_end la variabile ap diventa indefinita e successive chiamate a va_arg
non funzioneranno. Si avranno risultati indefiniti anche chiamando va_arg specificando un tipo
che non corrisponde a quello dell’argomento.
Un altro limite delle macro è che i passi 1) e 3) devono essere eseguiti nel corpo principale
della funzione, il passo 2) invece può essere eseguito anche in una subroutine passandole il
puntatore alla lista di argomenti; in questo caso però si richiede che al ritorno della funzione il
puntatore non venga più usato (lo standard richiederebbe la chiamata esplicita di va_end), dato
che il valore di ap risulterebbe indefinito.
Esistono dei casi in cui è necessario eseguire più volte la scansione degli argomenti e poter
memorizzare una posizione durante la stessa. In questo caso sembrerebbe naturale copiarsi il
puntatore alla lista degli argomenti con una semplice assegnazione. Dato che una delle realiz-
zazioni più comuni di va_list è quella di un puntatore nello stack all’indirizzo dove sono stati
salvati gli argomenti, è assolutamente normale pensare di poter effettuare questa operazione.
In generale però possono esistere anche realizzazioni diverse, per questo motivo va_list
è definito come tipo opaco e non può essere assegnato direttamente ad un’altra variabile dello
stesso tipo. Per risolvere questo problema lo standard ISO C9932 ha previsto una macro ulteriore
che permette di eseguire la copia di un puntatore alla lista degli argomenti:
#include <stdarg.h>
void va_copy(va_list dest, va_list src)
Copia l’attuale valore src del puntatore alla lista degli argomenti su dest.
anche in questo caso è buona norma chiudere ogni esecuzione di una va_copy con una corrispon-
dente va_end sul nuovo puntatore alla lista degli argomenti.
La chiamata di una funzione con un numero variabile di argomenti, posto che la si sia
dichiarata e definita come tale, non prevede nulla di particolare; l’invocazione è identica alle
altre, con gli argomenti, sia quelli fissi che quelli opzionali, separati da virgole. Quello che però
è necessario tenere presente è come verranno convertiti gli argomenti variabili.
In Linux gli argomenti dello stesso tipo sono passati allo stesso modo, sia che siano fissi sia
che siano opzionali (alcuni sistemi trattano diversamente gli opzionali), ma dato che il prototipo
non può specificare il tipo degli argomenti opzionali, questi verranno sempre promossi, pertanto
nella ricezione dei medesimi occorrerà tenerne conto (ad esempio un char verrà visto da va_arg
come int).
Uno dei problemi che si devono affrontare con le funzioni con un numero variabile di argo-
menti è che non esiste un modo generico che permetta di stabilire quanti sono gli argomenti
passati effettivamente in una chiamata.
32
alcuni sistemi che non hanno questa macro provvedono al suo posto __va_copy che era il nome proposto in
una bozza dello standard.

Esistono varie modalità per affrontare questo problema; una delle più immediate è quella di
specificare il numero degli argomenti opzionali come uno degli argomenti fissi. Una variazione di
questo metodo è l’uso di un argomento per specificare anche il tipo degli argomenti (come fa la
stringa di formato per printf).
Una modalità diversa, che può essere applicata solo quando il tipo degli argomenti lo rende
possibile, è quella che prevede di usare un valore speciale come ultimo argomento (come fa ad
esempio execl che usa un puntatore NULL per indicare la fine della lista degli argomenti).
2.4.3 Potenziali problemi con le variabili automatiche
Uno dei possibili problemi che si possono avere con le subroutine è quello di restituire alla fun-
zione chiamante dei dati che sono contenuti in una variabile automatica. Ovviamente quando
la subroutine ritorna la sezione dello stack che conteneva la variabile automatica potrà esse-
re riutilizzata da una nuova funzione, con le immaginabili conseguenze di sovrapposizione e
sovrascrittura dei dati.
Per questo una delle regole fondamentali della programmazione in C è che all’uscita di una
funzione non deve restare nessun riferimento alle variabili locali; qualora sia necessario utilizzare
variabili che possano essere viste anche dalla funzione chiamante queste devono essere allocate
esplicitamente, o in maniera statica (usando variabili di tipo static o extern), o dinamicamente
con una delle funzioni della famiglia malloc.
2.4.4 Il controllo di flusso non locale
Il controllo del flusso di un programma in genere viene effettuato con le varie istruzioni del
linguaggio C; fra queste la più bistrattata è il goto, che viene deprecato in favore dei costrutti
della programmazione strutturata, che rendono il codice più leggibile e mantenibile. Esiste però
un caso in cui l’uso di questa istruzione porta all’implementazione più efficiente e più chiara
anche dal punto di vista della struttura del programma: quello dell’uscita in caso di errore.
Il C però non consente di effettuare un salto ad una etichetta definita in un’altra funzione,
per cui se l’errore avviene in una funzione, e la sua gestione ordinaria è in un’altra, occorre usare
quello che viene chiamato un salto non-locale. Il caso classico in cui si ha questa necessità, citato
sia in [1] che in [5], è quello di un programma nel cui corpo principale vengono letti dei dati
in ingresso sui quali viene eseguita, tramite una serie di funzioni di analisi, una scansione dei
contenuti, da cui si ottengono le indicazioni per l’esecuzione di opportune operazioni.
Dato che l’analisi può risultare molto complessa, ed opportunamente suddivisa in fasi diverse,
la rilevazione di un errore nei dati in ingresso può accadere all’interno di funzioni profondamente
annidate l’una nell’altra. In questo caso si dovrebbe gestire, per ciascuna fase, tutta la casistica
del passaggio all’indietro di tutti gli errori rilevabili dalle funzioni usate nelle fasi successive.
Questo comporterebbe una notevole complessità, mentre sarebbe molto più comodo poter tornare
direttamente al ciclo di lettura principale, scartando l’input come errato.33
Tutto ciò può essere realizzato proprio con un salto non-locale; questo di norma viene rea-
lizzato salvando il contesto dello stack nel punto in cui si vuole tornare in caso di errore, e ri-
pristinandolo, in modo da tornare nella funzione da cui si era partiti, quando serve. La funzione
che permette di salvare il contesto dello stack è setjmp, il cui prototipo è:
#include <setjmp.h>
int setjmp(jmp_buf env)
Salva il contesto dello stack.
La funzione ritorna zero quando è chiamata direttamente e un valore diverso da zero quando
ritorna da una chiamata di longjmp che usa il contesto salvato in precedenza.
33
a meno che, come precisa [5], alla chiusura di ciascuna fase non siano associate operazioni di pulizia specifiche
(come deallocazioni, chiusure di file, ecc.), che non potrebbero essere eseguite con un salto non-locale.

Quando si esegue la funzione il contesto corrente dello stack viene salvato nell’argomento
env, una variabile di tipo jmp_buf34 che deve essere stata definita in precedenza. In genere le
variabili di tipo jmp_buf vengono definite come variabili globali in modo da poter essere viste
in tutte le funzioni del programma.
Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore diverso da
zero viene restituito solo quando il ritorno è dovuto ad una chiamata di longjmp in un’altra
parte del programma che ripristina lo stack effettuando il salto non-locale. Si tenga conto che il
contesto salvato in env viene invalidato se la funzione che ha chiamato setjmp ritorna, nel qual
caso un successivo uso di longjmp può comportare conseguenze imprevedibili (e di norma fatali)
per il processo.
Come accennato per effettuare un salto non-locale ad un punto precedentemente stabilito
con setjmp si usa la funzione longjmp; il suo prototipo è:
#include <setjmp.h>
void longjmp(jmp_buf env, int val)
Ripristina il contesto dello stack.
La funzione non ritorna.
La funzione ripristina il contesto dello stack salvato da una chiamata a setjmp nell’argomento
env. Dopo l’esecuzione della funzione il programma prosegue nel codice successivo al ritorno
della setjmp con cui si era salvato env, che restituirà il valore val invece di zero. Il valore di
val specificato nella chiamata deve essere diverso da zero, se si è specificato 0 sarà comunque
restituito 1 al suo posto.
In sostanza un longjmp è analogo ad un return, solo che invece di ritornare alla riga succes-
siva della funzione chiamante, il programma ritorna alla posizione della relativa setjmp, l’altra
differenza è che il ritorno può essere effettuato anche attraverso diversi livelli di funzioni annidate.
L’implementazione di queste funzioni comporta alcune restrizioni dato che esse interagiscono
direttamente con la gestione dello stack ed il funzionamento del compilatore stesso. In particolare
setjmp è implementata con una macro, pertanto non si può cercare di ottenerne l’indirizzo, ed
inoltre delle chiamate a questa funzione sono sicure solo in uno dei seguenti casi:
• come espressione di controllo in un comando condizionale, di selezione o di iterazione (come
if, switch o while);
• come operando per un operatore di uguaglianza o confronto in una espressione di controllo
di un comando condizionale, di selezione o di iterazione;
• come operando per l’operatore di negazione (!) in una espressione di controllo di un
comando condizionale, di selezione o di iterazione;
• come espressione a sé stante.
In generale, dato che l’unica differenza fra la chiamata diretta e quella ottenuta nell’uscita
con un longjmp è costituita dal valore di ritorno di setjmp, quest’ultima usualmente viene
chiamata all’interno di un comando if.
Uno dei punti critici dei salti non-locali è quello del valore delle variabili, ed in particolare
quello delle variabili automatiche della funzione a cui si ritorna. In generale le variabili globali e
statiche mantengono i valori che avevano al momento della chiamata di longjmp, ma quelli delle
variabili automatiche (o di quelle dichiarate register35) sono in genere indeterminati.
34
questo è un classico esempio di variabile di tipo opaco. Si definiscono cos`ı strutture ed altri oggetti usati da
una libreria, la cui struttura interna non deve essere vista dal programma chiamante (da cui il nome) che li devono
utilizzare solo attraverso dalle opportune funzioni di gestione.
35
la direttiva register del compilatore chiede che la variabile dichiarata tale sia mantenuta, nei limiti del
possibile, all’interno di un registro del processore. Questa direttiva è originaria dell’epoca dai primi compilatori,
quando stava al programmatore scrivere codice ottimizzato, riservando esplicitamente alle variabili più usate l’uso
dei registri del processore. Oggi questa direttiva è in disuso dato che tutti i compilatori sono normalmente in grado
di valutare con maggior efficacia degli stessi programmatori quando sia il caso di eseguire questa ottimizzazione.

Quello che succede infatti è che i valori delle variabili che sono tenute in memoria manterranno
il valore avuto al momento della chiamata di longjmp, mentre quelli tenuti nei registri del
processore (che nella chiamata ad un’altra funzione vengono salvati nel contesto nello stack)
torneranno al valore avuto al momento della chiamata di setjmp; per questo quando si vuole
avere un comportamento coerente si può bloccare l’ottimizzazione che porta le variabili nei
registri dichiarandole tutte come volatile.36
2.4.5 La endianess
Uno dei problemi di programmazione che può dar luogo ad effetti imprevisti è quello relativo
alla cosiddetta endianess. Questa è una caratteristica generale dell’architettura hardware di un
computer che dipende dal fatto che la rappresentazione di un numero binario può essere fatta
in due modi, chiamati rispettivamente big endian e little endian a seconda di come i singoli bit
vengono aggregati per formare le variabili intere (ed in genere in diretta corrispondenza a come
sono poi in realtà cablati sui bus interni del computer).
Figura 2.6: Schema della disposizione dei dati in memoria a seconda della endianess.
Per capire meglio il problema si consideri un intero a 32 bit scritto in una locazione di memoria
posta ad un certo indirizzo. Come illustrato in fig. 2.6 i singoli bit possono essere disposti in
memoria in due modi: a partire dal più significativo o a partire dal meno significativo. Cos`ı
nel primo caso si troverà il byte che contiene i bit più significativi all’indirizzo menzionato e il
byte con i bit meno significativi nell’indirizzo successivo; questo ordinamento è detto big endian,
dato che si trova per prima la parte più grande. Il caso opposto, in cui si parte dal bit meno
significativo è detto per lo stesso motivo little endian.
Si può allora verificare quale tipo di endianess usa il proprio computer con un programma
elementare che si limita ad assegnare un valore ad una variabile per poi ristamparne il contenuto
leggendolo un byte alla volta. Il codice di detto programma, endtest.c, è nei sorgenti allegati,
allora se lo eseguiamo su un normale PC compatibile, che è little endian otterremo qualcosa del
tipo:
[piccardi@gont sources]$ ./endtest
Using value ABCDEF01
val[0]= 1
val[1]=EF
val[2]=CD
val[3]=AB
mentre su un vecchio Macintosh con PowerPC, che è big endian avremo qualcosa del tipo:
36
la direttiva volatile informa il compilatore che la variabile che è dichiarata può essere modificata, durante
l’esecuzione del nostro, da altri programmi. Per questo motivo occorre dire al compilatore che non deve essere
mai utilizzata l’ottimizzazione per cui quanto opportuno essa viene mantenuta in un registro, poiché in questo
modo si perderebbero le eventuali modifiche fatte dagli altri programmi (che avvengono solo in una copia posta
in memoria).

piccardi@anarres:~/gapil/sources$ ./endtest
Using value ABCDEF01
val[0]=AB
val[1]=CD
val[2]=EF
val[3]= 1
L’attenzione alla endianess nella programmazione è importante, perché se si fanno assunzioni
relative alla propria architettura non è detto che queste restino valide su un’altra architettura.
Inoltre, come vedremo ad esempio in sez. 15.4, si possono avere problemi quando ci si trova a
usare valori di un formato con una infrastruttura che ne usa un altro.
La endianess di un computer dipende essenzialmente dalla architettura hardware usata; Intel
e Digital usano il little endian, Motorola, IBM, Sun (sostanzialmente tutti gli altri) usano il big
endian. Il formato dei dati contenuti nelle intestazioni dei protocolli di rete (il cosiddetto network
order è anch’esso big endian; altri esempi di uso di questi due diversi formati sono quello del
bus PCI, che è little endian, o quello del bus VME che è big endian.
Esistono poi anche dei processori che possono scegliere il tipo di formato all’avvio e alcuni
che, come il PowerPC o l’Intel i860, possono pure passare da un tipo di ordinamento all’altro con
una specifica istruzione. In ogni caso in Linux l’ordinamento è definito dall’architettura e dopo
l’avvio del sistema in genere resta sempre lo stesso,37 anche quando il processore permetterebbe
di eseguire questi cambiamenti.
1 int endian(void)
2 {
3 /*
4 * Variables definition
5 */
6 short magic , test;
7 char * ptr;
8
9 magic = 0xABCD; /* endianess magic number */
10 ptr = (char *) &magic;
11 test = (ptr [1]<<8) + (ptr [0]&0 xFF); /* build value byte by byte */
12 return (magic == test ); /* if the same is little endian */
13 }
Figura 2.7: La funzione endian, usata per controllare il tipo di architettura della macchina.
Per controllare quale tipo di ordinamento si ha sul proprio computer si è scritta una piccola
funzione di controllo, il cui codice è riportato fig. 2.7, che restituisce un valore nullo (falso) se
l’architettura è big endian ed uno non nullo (vero) se l’architettura è little endian.
Come si vede la funzione è molto semplice, e si limita, una volta assegnato (9) un valore di
test pari a 0xABCD ad una variabile di tipo short (cioè a 16 bit), a ricostruirne una copia byte a
byte. Per questo prima (10) si definisce il puntatore ptr per accedere al contenuto della prima
variabile, ed infine calcola (11) il valore della seconda assumendo che il primo byte sia quello
meno significativo (cioè, per quanto visto in fig. 2.6, che sia little endian). Infine la funzione
restituisce (12) il valore del confronto delle due variabili.
37
su architettura PowerPC è possibile cambiarlo, si veda sez. 3.5.2.

Capitolo 3
La gestione dei processi
Come accennato nell’introduzione in un sistema Unix tutte le operazioni vengono svolte tramite
opportuni processi. In sostanza questi ultimi vengono a costituire l’unità base per l’allocazione
e l’uso delle risorse del sistema.
Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come unità a
se stante, in questo esamineremo il funzionamento dei processi all’interno del sistema. Saranno
cioè affrontati i dettagli della creazione e della terminazione dei processi, della gestione dei
loro attributi e privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione finale
introdurremo alcune problematiche generiche della programmazione in ambiente multitasking.
3.1 Introduzione
Inizieremo con un’introduzione generale ai concetti che stanno alla base della gestione dei processi
in un sistema unix-like. Introdurremo in questa sezione l’architettura della gestione dei processi
e le sue principali caratteristiche, dando una panoramica sull’uso delle principali funzioni di
gestione.
3.1.1 L’architettura della gestione dei processi
A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la generazione di nuovi
processi è un’operazione privilegiata) una delle caratteristiche di Unix (che esamineremo in
dettaglio più avanti) è che qualunque processo può a sua volta generarne altri, detti processi figli
(child process). Ogni processo è identificato presso il sistema da un numero univoco, il cosiddetto
process identifier o, più brevemente, pid, assegnato in forma progressiva (vedi sez. 3.2.1) quando
il processo viene creato.
Una seconda caratteristica di un sistema Unix è che la generazione di un processo è un’o-
perazione separata rispetto al lancio di un programma. In genere la sequenza è sempre quella
di creare un nuovo processo, il quale eseguirà, in un passo successivo, il programma desiderato:
questo è ad esempio quello che fa la shell quando mette in esecuzione il programma che gli
indichiamo nella linea di comando.
Una terza caratteristica è che ogni processo è sempre stato generato da un altro, che viene
chiamato processo padre (parent process). Questo vale per tutti i processi, con una sola eccezione:
dato che ci deve essere un punto di partenza esiste un processo speciale (che normalmente è
/sbin/init), che viene lanciato dal kernel alla conclusione della fase di avvio; essendo questo
il primo processo lanciato dal sistema ha sempre il pid uguale a 1 e non è figlio di nessun altro
processo.
Ovviamente init è un processo speciale che in genere si occupa di far partire tutti gli altri
processi necessari al funzionamento del sistema, inoltre init è essenziale per svolgere una serie
47

48 CAPITOLO 3. LA GESTIONE DEI PROCESSI
di compiti amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di essi
in sez. 3.2.3) e non può mai essere terminato. La struttura del sistema comunque consente di
lanciare al posto di init qualunque altro programma, e in casi di emergenza (ad esempio se il
file di init si fosse corrotto) è ad esempio possibile lanciare una shell al suo posto, passando la
riga init=/bin/sh come parametro di avvio.
[piccardi@gont piccardi]$ pstree -n
init-+-keventd
|-kapm-idled
|-kreiserfsd
|-portmap
|-syslogd
|-klogd
|-named
|-rpc.statd
|-gpm
|-inetd
|-junkbuster
|-master-+-qmgr
| ‘-pickup
|-sshd
|-xfs
|-cron
|-bash---startx---xinit-+-XFree86
| ‘-WindowMaker-+-ssh-agent
| |-wmtime
| |-wmmon
| |-wmmount
| |-wmppp
| |-wmcube
| |-wmmixer
| |-wmgtemp
| |-wterm---bash---pstree
| ‘-wterm---bash-+-emacs
| ‘-man---pager
|-5*[getty]
|-snort
‘-wwwoffled
Figura 3.1: L’albero dei processi, cos`ı come riportato dal comando pstree.
Dato che tutti i processi attivi nel sistema sono comunque generati da init o da uno dei suoi
figli1 si possono classificare i processi con la relazione padre/figlio in un’organizzazione gerarchica
ad albero, in maniera analoga a come i file sono organizzati in un albero di directory (si veda
sez. 4.1.1); in fig. 3.1 si è mostrato il risultato del comando pstree che permette di visualizzare
questa struttura, alla cui base c’è init che è progenitore di tutti gli altri processi.
Il kernel mantiene una tabella dei processi attivi, la cosiddetta process table; per ciascun
processo viene mantenuta una voce, costituita da una struttura task_struct, nella tabella dei
processi che contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture usate
a questo scopo sono dichiarate nell’header file linux/sched.h, ed uno schema semplificato, che
riporta la struttura delle principali informazioni contenute nella task_struct (che in seguito
incontreremo a più riprese), è mostrato in fig. 3.2.
Come accennato in sez. 1.1 è lo scheduler che decide quale processo mettere in esecuzione;
esso viene eseguito ad ogni system call ed ad ogni interrupt,2 ma può essere anche attivato
1
in realtà questo non è del tutto vero, in Linux ci sono alcuni processi speciali che pur comparendo come figli
di init, o con pid successivi, sono in realtà generati direttamente dal kernel, (come keventd, kswapd, ecc.).
2
più in una serie di altre occasioni.

3.1. INTRODUZIONE 49
Figura 3.2: Schema semplificato dell’architettura delle strutture usate dal kernel nella gestione dei processi.
esplicitamente. Il timer di sistema provvede comunque a che esso sia invocato periodicamente;
generando un interrupt periodico secondo la frequenza specificata dalla costante HZ,3 definita in
asm/param.h, ed il cui valore è espresso in Hertz.4
Ogni volta che viene eseguito, lo scheduler effettua il calcolo delle priorità dei vari processi
attivi (torneremo su questo in sez. 3.4) e stabilisce quale di essi debba essere posto in esecuzione
fino alla successiva invocazione.
3.1.2 Una panoramica sulle funzioni fondamentali
Tradizionalmente in un sistema unix-like i processi vengono sempre creati da altri processi tra-
mite la funzione fork; il nuovo processo (che viene chiamato figlio) creato dalla fork è una copia
identica del processo processo originale (detto padre), ma ha un nuovo pid e viene eseguito in
maniera indipendente (le differenze fra padre e figlio sono affrontate in dettaglio in sez. 3.2.2).
Se si vuole che il processo padre si fermi fino alla conclusione del processo figlio questo deve
essere specificato subito dopo la fork chiamando la funzione wait o la funzione waitpid (si veda
sez. 3.2.4); queste funzioni restituiscono anche un’informazione abbastanza limitata sulle cause
della terminazione del processo figlio.
Quando un processo ha concluso il suo compito o ha incontrato un errore non risolvibile
esso può essere terminato con la funzione exit (si veda quanto discusso in sez. 2.1.2). La vita
3
fino al kernel 2.4 il valore di HZ era 100 su tutte le architetture tranne l’alpha, per cui era 1000, nel 2.6 è
stato portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di compilazione del kernel, con un default
di 250 e valori possibili di 100, 250, 1000 e dal 2.6.20 anche 300 (che è divisibile per le frequenze di refresh della
televisione); occorre fare attenzione a non confondere questo valore con quello dei clock tick (vedi sez. 8.4.1).
4
a partire dal kernel 2.6.21 è stato introdotto (a cura di Ingo Molnar) un meccanismo completamente diverso,
detto tickless, in cui non c’è più una interruzione periodica con frequenza prefissata, ma ad ogni chiamata del timer
viene programmata l’interruzione successiva sulla base di una stima; in questo modo si evita di dover eseguire
un migliaio di interruzioni al secondo anche su macchine che non stanno facendo nulla, con un forte risparmio
nell’uso dell’energia da parte del processore che può essere messo in stato di sospensione anche per lunghi periodi
di tempo.

del processo però termina completamente solo quando la notifica della sua conclusione viene
ricevuta dal processo padre, a quel punto tutte le risorse allocate nel sistema ad esso associate
vengono rilasciate.
Avere due processi che eseguono esattamente lo stesso codice non è molto utile, normalmente
si genera un secondo processo per affidargli l’esecuzione di un compito specifico (ad esempio gesti-
re una connessione dopo che questa è stata stabilita), o fargli eseguire (come fa la shell) un altro
programma. Per quest’ultimo caso si usa la seconda funzione fondamentale per programmazione
coi processi che è la exec.
Il programma che un processo sta eseguendo si chiama immagine del processo (o process
image), le funzioni della famiglia exec permettono di caricare un altro programma da disco
sostituendo quest’ultimo all’immagine corrente; questo fa s`ı che l’immagine precedente venga
completamente cancellata. Questo significa che quando il nuovo programma termina, anche il
processo termina, e non si può tornare alla precedente immagine.
Per questo motivo la fork e la exec sono funzioni molto particolari con caratteristiche uniche
rispetto a tutte le altre, infatti la prima ritorna due volte (nel processo padre e nel figlio) mentre
la seconda non ritorna mai (in quanto con essa viene eseguito un altro programma).
3.2 Le funzioni di base
In questa sezione tratteremo le problematiche della gestione dei processi all’interno del sistema,
illustrandone tutti i dettagli. Inizieremo con le funzioni elementari che permettono di leggerne
gli identificatori, per poi passare alla spiegazione delle funzioni base che si usano per la creazione
e la terminazione dei processi, e per la messa in esecuzione degli altri programmi.
3.2.1 Gli identificatori dei processi
Come accennato nell’introduzione, ogni processo viene identificato dal sistema da un numero
identificativo univoco, il process ID o pid; quest’ultimo è un tipo di dato standard, il pid_t che
in genere è un intero con segno (nel caso di Linux e delle glibc il tipo usato è int).
Il pid viene assegnato in forma progressiva5 ogni volta che un nuovo processo viene creato,
fino ad un limite che, essendo il pid un numero positivo memorizzato in un intero a 16 bit,
arriva ad un massimo di 32768. Oltre questo valore l’assegnazione riparte dal numero più basso
disponibile a partire da un minimo di 300,6 che serve a riservare i pid più bassi ai processi
eseguiti direttamente dal kernel. Per questo motivo, come visto in sez. 3.1.1, il processo di avvio
(init) ha sempre il pid uguale a uno.
Tutti i processi inoltre memorizzano anche il pid del genitore da cui sono stati creati, questo
viene chiamato in genere ppid (da parent process ID). Questi due identificativi possono essere
ottenuti usando le due funzioni getpid e getppid, i cui prototipi sono:
#include <sys/types.h>
#include <unistd.h>
pid_t getpid(void)
Restituisce il pid del processo corrente.
pid_t getppid(void)
Restituisce il pid del padre del processo corrente.
Entrambe le funzioni non riportano condizioni di errore.
5
in genere viene assegnato il numero successivo a quello usato per l’ultimo processo creato, a meno che questo
numero non sia già utilizzato per un altro pid, pgid o sid (vedi sez. 10.1.2).
6
questi valori, fino al kernel 2.4.x, sono definiti dalla macro PID_MAX in threads.h e direttamente in fork.c,
con il kernel 2.5.x e la nuova interfaccia per i thread creata da Ingo Molnar anche il meccanismo di allocazione dei
pid è stato modificato; il valore massimo è impostabile attraverso il file /proc/sys/kernel/pid_max e di default
vale 32768.

3.2. LE FUNZIONI DI BASE 51
esempi dell’uso di queste funzioni sono riportati in fig. 3.3, nel programma ForkTest.c.
Il fatto che il pid sia un numero univoco per il sistema lo rende un candidato per generare
ulteriori indicatori associati al processo di cui diventa possibile garantire l’unicità: ad esempio
in alcune implementazioni la funzione tempnam (si veda sez. 5.1.8) usa il pid per generare un
pathname univoco, che non potrà essere replicato da un altro processo che usi la stessa funzione.
Tutti i processi figli dello stesso processo padre sono detti sibling, questa è una delle relazioni
usate nel controllo di sessione, in cui si raggruppano i processi creati su uno stesso terminale, o
relativi allo stesso login. Torneremo su questo argomento in dettaglio in cap. 10, dove esamine-
remo gli altri identificativi associati ad un processo e le varie relazioni fra processi utilizzate per
definire una sessione.
Oltre al pid e al ppid, (e a quelli che vedremo in sez. 10.1.2, relativi al controllo di sessione),
ad ogni processo vengono associati degli altri identificatori che vengono usati per il controllo
di accesso. Questi servono per determinare se un processo può eseguire o meno le operazioni
richieste, a seconda dei privilegi e dell’identità di chi lo ha posto in esecuzione; l’argomento è
complesso e sarà affrontato in dettaglio in sez. 3.3.
3.2.2 La funzione fork e le funzioni di creazione dei processi
La funzione fork è la funzione fondamentale della gestione dei processi: come si è detto tradi-
zionalmente l’unico modo di creare un nuovo processo era attraverso l’uso di questa funzione,7
essa quindi riveste un ruolo centrale tutte le volte che si devono scrivere programmi che usano
il multitasking.8 Il prototipo della funzione è:
#include <unistd.h>
pid_t fork(void)
Crea un nuovo processo.
In caso di successo restituisce il pid del figlio al padre e zero al figlio; ritorna -1 al padre (senza
creare il figlio) in caso di errore; errno può assumere i valori:
EAGAIN non ci sono risorse sufficienti per creare un altro processo (per allocare la tabella delle
pagine e le strutture del task) o si è esaurito il numero di processi disponibili.
ENOMEM non è stato possibile allocare la memoria per le strutture necessarie al kernel per creare
il nuovo processo.
Dopo il successo dell’esecuzione di una fork sia il processo padre che il processo figlio con-
tinuano ad essere eseguiti normalmente a partire dall’istruzione successiva alla fork; il processo
figlio è però una copia del padre, e riceve una copia dei segmenti di testo, stack e dati (ve-
di sez. 2.2.2), ed esegue esattamente lo stesso codice del padre. Si tenga presente però che la
memoria è copiata, non condivisa, pertanto padre e figlio vedono variabili diverse.
Per quanto riguarda la gestione della memoria, in generale il segmento di testo, che è identico
per i due processi, è condiviso e tenuto in read-only per il padre e per i figli. Per gli altri segmenti
Linux utilizza la tecnica del copy on write; questa tecnica comporta che una pagina di memoria
viene effettivamente copiata per il nuovo processo solo quando ci viene effettuata sopra una
scrittura (e si ha quindi una reale differenza fra padre e figlio). In questo modo si rende molto
più efficiente il meccanismo della creazione di un nuovo processo, non essendo più necessaria la
copia di tutto lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di memoria che
sono state modificate, e solo al momento della modifica stessa.
7
in realtà oggi la system call usata da Linux per creare nuovi processi è clone (vedi 3.5.1), anche perché a
partire dalle glibc 2.3.3 non viene più usata la system call originale, ma la stessa fork viene implementata tramite
clone, cosa che consente una migliore interazione coi thread.
8
oggi questa rilevanza, con la diffusione dell’uso dei thread che tratteremo al cap. 13, è in parte minore, ma
fork resta comunque la funzione principale per la creazione di processi.

La differenza che si ha nei due processi è che nel processo padre il valore di ritorno della
funzione fork è il pid del processo figlio, mentre nel figlio è zero; in questo modo il programma
può identificare se viene eseguito dal padre o dal figlio. Si noti come la funzione fork ritorni
due volte: una nel padre e una nel figlio.
La scelta di questi valori di ritorno non è casuale, un processo infatti può avere più figli, ed il
valore di ritorno di fork è l’unico modo che gli permette di identificare quello appena creato; al
contrario un figlio ha sempre un solo padre (il cui pid può sempre essere ottenuto con getppid,
vedi sez. 3.2.1) per cui si usa il valore nullo, che non è il pid di nessun processo.
1 #include <errno.h> /* error definitions and routines */
2 #include <stdlib.h> /* C standard library */
3 #include <unistd.h> /* unix standard library */
4 #include <stdio.h> /* standard I/O library */
5 #include <string.h> /* string functions */
6
7 /* Help printing routine */
8 void usage(void );
9
10 int main(int argc , char *argv [])
11 {
12 /*
13 * Variables definition
14 */
15 int nchild , i;
16 pid_t pid;
17 int wait_child = 0;
18 int wait_parent = 0;
19 int wait_end = 0;
20 ... /* handling options */
21 nchild = atoi(argv[optind ]);
22 printf("Test for forking %d childn", nchild );
23 /* loop to fork children */
24 for (i=0; i<nchild; i++) {
25 if ( (pid = fork ()) < 0) {
26 /* on error exit */
27 printf("Error on %d child creation , %sn", i+1, strerror(errno ));
28 exit (-1);
29 }
30 if (pid == 0) { /* child */
31 printf("Child %d successfully executingn", ++i);
32 if (wait_child) sleep(wait_child );
33 printf("Child %d, parent %d, exitingn", i, getppid ());
34 exit (0);
35 } else { /* parent */
36 printf("Spawned %d child , pid %d n", i+1, pid);
37 if (wait_parent) sleep(wait_parent );
38 printf("Go to next child n");
39 }
40 }
41 /* normal exit */
42 if (wait_end) sleep(wait_end );
43 return 0;
44 }
Figura 3.3: Esempio di codice per la creazione di nuovi processi.
Normalmente la chiamata a fork può fallire solo per due ragioni, o ci sono già troppi processi
nel sistema (il che di solito è sintomo che qualcos’altro non sta andando per il verso giusto) o

si è ecceduto il limite sul numero totale di processi permessi all’utente (vedi sez. 8.3.2, ed in
particolare tab. 8.12).
L’uso di fork avviene secondo due modalità principali; la prima è quella in cui all’interno
di un programma si creano processi figli cui viene affidata l’esecuzione di una certa sezione di
codice, mentre il processo padre ne esegue un’altra. È il caso tipico dei programmi server (il
modello client-server è illustrato in sez. 14.1.1) in cui il padre riceve ed accetta le richieste da
parte dei programmi client, per ciascuna delle quali pone in esecuzione un figlio che è incaricato
di fornire il servizio.
La seconda modalità è quella in cui il processo vuole eseguire un altro programma; questo è
ad esempio il caso della shell. In questo caso il processo crea un figlio la cui unica operazione è
quella di fare una exec (di cui parleremo in sez. 3.2.5) subito dopo la fork.
Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa seconda
modalità (una fork seguita da una exec) in un’unica operazione che viene chiamata spawn. Nei
sistemi unix-like è stato scelto di mantenere questa separazione, dato che, come per la prima
modalità d’uso, esistono numerosi scenari in cui si può usare una fork senza aver bisogno di
eseguire una exec. Inoltre, anche nel caso della seconda modalità d’uso, avere le due funzioni
separate permette al figlio di cambiare gli attributi del processo (maschera dei segnali, redirezione
dell’output, identificatori) prima della exec, rendendo cos`ı relativamente facile intervenire sulle
le modalità di esecuzione del nuovo programma.
In fig. 3.3 è riportato il corpo del codice del programma di esempio forktest, che permette
di illustrare molte caratteristiche dell’uso della funzione fork. Il programma crea un numero di
figli specificato da linea di comando, e prende anche alcune opzioni per indicare degli eventuali
tempi di attesa in secondi (eseguiti tramite la funzione sleep) per il padre ed il figlio (con
forktest -h si ottiene la descrizione delle opzioni); il codice completo, compresa la parte che
gestisce le opzioni a riga di comando, è disponibile nel file ForkTest.c, distribuito insieme agli
altri sorgenti degli esempi su http://gapil.truelite.it/gapil source.tgz.
Decifrato il numero di figli da creare, il ciclo principale del programma (24-40) esegue in
successione la creazione dei processi figli controllando il successo della chiamata a fork (25-
29); ciascun figlio (31-34) si limita a stampare il suo numero di successione, eventualmente
attendere il numero di secondi specificato e scrivere un messaggio prima di uscire. Il processo
padre invece (36-38) stampa un messaggio di creazione, eventualmente attende il numero di
secondi specificato, e procede nell’esecuzione del ciclo; alla conclusione del ciclo, prima di uscire,
può essere specificato un altro periodo di attesa.
Se eseguiamo il comando9 senza specificare attese (come si può notare in (17-19) i valori
predefiniti specificano di non attendere), otterremo come output sul terminale:
[piccardi@selidor sources]$ export LD_LIBRARY_PATH=./; ./forktest 3
Process 1963: forking 3 child
Spawned 1 child, pid 1964
Child 1 successfully executing
Child 1, parent 1963, exiting
Go to next child
Go to next child
Go to next child
Esaminiamo questo risultato: una prima conclusione che si può trarre è che non si può
dire quale processo fra il padre ed il figlio venga eseguito per primo dopo la chiamata a fork;
9
che è preceduto dall’istruzione export LD_LIBRARY_PATH=./ per permettere l’uso delle librerie dinamiche.

dall’esempio si può notare infatti come nei primi due cicli sia stato eseguito per primo il padre
(con la stampa del pid del nuovo processo) per poi passare all’esecuzione del figlio (completata
con i due avvisi di esecuzione ed uscita), e tornare all’esecuzione del padre (con la stampa del
passaggio al ciclo successivo), mentre la terza volta è stato prima eseguito il figlio (fino alla
conclusione) e poi il padre.
In generale l’ordine di esecuzione dipenderà, oltre che dall’algoritmo di scheduling usato
dal kernel, dalla particolare situazione in cui si trova la macchina al momento della chiamata,
risultando del tutto impredicibile. Eseguendo più volte il programma di prova e producendo un
numero diverso di figli, si sono ottenute situazioni completamente diverse, compreso il caso in cui
il processo padre ha eseguito più di una fork prima che uno dei figli venisse messo in esecuzione.
Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle istruzioni
del codice fra padre e figli, né sull’ordine in cui questi potranno essere messi in esecuzione. Se
è necessaria una qualche forma di precedenza occorrerà provvedere ad espliciti meccanismi di
sincronizzazione, pena il rischio di incorrere nelle cosiddette race condition (vedi sez. 3.6.2).
In realtà a partire dal kernel 2.5.2-pre10 il nuovo scheduler di Ingo Molnar esegue sempre
per primo il figlio;10 questa è una ottimizzazione che serve a evitare che il padre, effettuan-
do per primo una operazione di scrittura in memoria, attivi il meccanismo del copy on write.
Questa operazione infatti potrebbe risultare del tutto inutile qualora il figlio fosse stato creato
solo per eseguire una exec, in tal caso infatti si invocherebbe un altro programma scartando
completamente lo spazio degli indirizzi, rendendo superflua la copia della memoria modificata
dal padre.
Eseguendo sempre per primo il figlio la exec verrebbe effettuata subito avendo cos`ı la certezza
che il copy on write viene utilizzato solo quando necessario. Quanto detto in precedenza vale
allora soltanto per i kernel fino al 2.4; per mantenere la portabilità è però opportuno non fare
affidamento su questo comportamento, che non si riscontra in altri Unix e nelle versioni del
kernel precedenti a quella indicata.
Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli processi completamente
separati, le modifiche delle variabili nei processi figli (come l’incremento di i in 31) sono visibili
solo a loro (ogni processo vede solo la propria copia della memoria), e non hanno alcun effetto
sul valore che le stesse variabili hanno nel processo padre (ed in eventuali altri processi figli che
eseguano lo stesso codice).
Un secondo aspetto molto importante nella creazione dei processi figli è quello dell’interazione
dei vari processi con i file; per illustrarlo meglio proviamo a redirigere su un file l’output del
nostro programma di test, quello che otterremo è:
[piccardi@selidor sources]$ ./forktest 3 > output
[piccardi@selidor sources]$ cat output
Test for forking 3 child
Go to next child
Go to next child
Go to next child
10
i risultati precedenti sono stati ottenuti usando un kernel della serie 2.4.

Go to next child
Go to next child
Go to next child
che come si vede è completamente diverso da quanto ottenevamo sul terminale.
Il comportamento delle varie funzioni di interfaccia con i file è analizzato in gran dettaglio in
cap. 6 e in cap. 7. Qui basta accennare che si sono usate le funzioni standard della libreria del C
che prevedono l’output bufferizzato; e questa bufferizzazione (trattata in dettaglio in sez. 7.1.4)
varia a seconda che si tratti di un file su disco (in cui il buffer viene scaricato su disco solo
quando necessario) o di un terminale (nel qual caso il buffer viene scaricato ad ogni carattere di
a capo).
Nel primo esempio allora avevamo che ad ogni chiamata a printf il buffer veniva scaricato,
e le singole righe erano stampate a video subito dopo l’esecuzione della printf. Ma con la
redirezione su file la scrittura non avviene più alla fine di ogni riga e l’output resta nel buffer.
Dato che ogni figlio riceve una copia della memoria del padre, esso riceverà anche quanto c’è nel
buffer delle funzioni di I/O, comprese le linee scritte dal padre fino allora. Cos`ı quando il buffer
viene scritto su disco all’uscita del figlio, troveremo nel file anche tutto quello che il processo
padre aveva scritto prima della sua creazione. E alla fine del file (dato che in questo caso il padre
esce per ultimo) troveremo anche l’output completo del padre.
L’esempio ci mostra un altro aspetto fondamentale dell’interazione con i file, valido anche
per l’esempio precedente, ma meno evidente: il fatto cioè che non solo processi diversi possono
scrivere in contemporanea sullo stesso file (l’argomento della condivisione dei file è trattato in
dettaglio in sez. 6.3.1), ma anche che, a differenza di quanto avviene per le variabili, la posizione
corrente sul file è condivisa fra il padre e tutti i processi figli.
Quello che succede è che quando lo standard output del padre viene rediretto come si è fatto
nell’esempio, lo stesso avviene anche per tutti i figli; la funzione fork infatti ha la caratteristica
di duplicare nei processi figli tutti i file descriptor aperti nel processo padre (allo stesso modo
in cui lo fa la funzione dup, trattata in sez. 6.3.4), il che comporta che padre e figli condividono
le stesse voci della file table (per la spiegazione di questi termini si veda sez. 6.3.1) fra cui c’è
anche la posizione corrente nel file.
In questo modo se un processo scrive sul file aggiornerà la posizione corrente sulla file table,
e tutti gli altri processi, che vedono la stessa file table, vedranno il nuovo valore. In questo modo
si evita, in casi come quello appena mostrato in cui diversi processi scrivono sullo stesso file,
che l’output successivo di un processo vada a sovrapporsi a quello dei precedenti: l’output potrà
risultare mescolato, ma non ci saranno parti perdute per via di una sovrascrittura.
Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre crea un figlio e
attende la sua conclusione per proseguire, ed entrambi scrivono sullo stesso file; un caso tipico
è la shell quando lancia un programma, il cui output va sullo standard output. In questo modo,
anche se l’output viene rediretto, il padre potrà sempre continuare a scrivere in coda a quanto
scritto dal figlio in maniera automatica; se cos`ı non fosse ottenere questo comportamento sarebbe
estremamente complesso necessitando di una qualche forma di comunicazione fra i due processi
per far riprendere al padre la scrittura al punto giusto.
In generale comunque non è buona norma far scrivere più processi sullo stesso file senza una
qualche forma di sincronizzazione in quanto, come visto anche con il nostro esempio, le varie
scritture risulteranno mescolate fra loro in una sequenza impredicibile. Per questo le modalità
con cui in genere si usano i file dopo una fork sono sostanzialmente due:
1. Il processo padre aspetta la conclusione del figlio. In questo caso non è necessaria nessuna
azione riguardo ai file, in quanto la sincronizzazione della posizione corrente dopo eventuali
operazioni di lettura e scrittura effettuate dal figlio è automatica.

2. L’esecuzione di padre e figlio procede indipendentemente. In questo caso ciascuno dei due
processi deve chiudere i file che non gli servono una volta che la fork è stata eseguita, per
evitare ogni forma di interferenza.
Oltre ai file aperti i processi figli ereditano dal padre una serie di altre proprietà; la lista
dettagliata delle proprietà che padre e figlio hanno in comune dopo l’esecuzione di una fork è
la seguente:
• i file aperti e gli eventuali flag di close-on-exec impostati (vedi sez. 3.2.5 e sez. 6.3.6);
• gli identificatori per il controllo di accesso: l’user-ID reale, il group-ID reale, l’user-ID
effettivo, il group-ID effettivo ed i group-ID supplementari (vedi sez. 3.3.1);
• gli identificatori per il controllo di sessione: il process group-ID e il session id ed il terminale
di controllo (vedi sez. 10.1.2);
• la directory di lavoro e la directory radice (vedi sez. 5.1.7 e sez. 5.4.5);
• la maschera dei permessi di creazione dei file (vedi sez. 5.3.3);
• la maschera dei segnali bloccati (vedi sez. 9.4.4) e le azioni installate (vedi sez. 9.3.1);
• i segmenti di memoria condivisa agganciati al processo (vedi sez. 11.2.6);
• i limiti sulle risorse (vedi sez. 8.3.2);
• il valori di nice, le priorità real-time e le affinità di processore (vedi sez. 3.4.2, sez. 3.4.3 e
sez. 3.4.4);
• le variabili di ambiente (vedi sez. 2.3.3).
Le differenze fra padre e figlio dopo la fork invece sono:11
• il valore di ritorno di fork;
• il pid (process id), assegnato ad un nuovo valore univoco;
• il ppid (parent process id), quello del figlio viene impostato al pid del padre;
• i valori dei tempi di esecuzione (vedi sez. 8.4.2) e delle risorse usate (vedi sez. 8.3.1), che
nel figlio sono posti a zero;
• i lock sui file (vedi sez. 12.1) e sulla memoria (vedi sez. 2.2.4), che non vengono ereditati
dal figlio;
• gli allarmi, i timer (vedi sez. 9.3.4) ed i segnali pendenti (vedi sez. 9.3.1), che per il figlio
vengono cancellati.
• le operazioni di I/O asincrono in corso (vedi sez. 12.3.3) che non vengono ereditate dal
figlio;
• gli aggiustamenti fatti dal padre ai semafori con semop (vedi sez. 11.2.5).
• le notifiche sui cambiamenti delle directory con dnotify (vedi sez. 9.1.4), che non vengono
ereditate dal figlio;
• le mappature di memoria marcate come MADV_DONTFORK (vedi sez. 12.4.1) che non vengono
ereditate dal figlio;
• l’impostazione con prctl (vedi sez. 3.5.2) che notifica al figlio la terminazione del padre
viene cancellata;
• il segnale di terminazione del figlio è sempre SIGCHLD anche qualora nel padre fosse stato
modificato (vedi sez. 3.5.1).
Una seconda funzione storica usata per la creazione di un nuovo processo è vfork, che è
esattamente identica a fork ed ha la stessa semantica e gli stessi errori; la sola differenza è che
non viene creata la tabella delle pagine né la struttura dei task per il nuovo processo. Il processo
padre è posto in attesa fintanto che il figlio non ha eseguito una execve o non è uscito con una
_exit. Il figlio condivide la memoria del padre (e modifiche possono avere effetti imprevedibili)
e non deve ritornare o uscire con exit ma usare esplicitamente _exit.
11
a parte le ultime quattro, relative a funzionalità specifiche di Linux, le altre sono esplicitamente menzionate
dallo standard POSIX.1-2001.

Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una fork comportava anche
la copia completa del segmento dati del processo padre, che costituiva un inutile appesantimento
in tutti quei casi in cui la fork veniva fatta solo per poi eseguire una exec. La funzione venne
introdotta in BSD per migliorare le prestazioni.
Dato che Linux supporta il copy on write la perdita di prestazioni è assolutamente trascura-
bile, e l’uso di questa funzione, che resta un caso speciale della system call clone (che tratteremo
in dettaglio in sez. 3.5.1) è deprecato; per questo eviteremo di trattarla ulteriormente.
3.2.3 La conclusione di un processo
In sez. 2.1.2 abbiamo già affrontato le modalità con cui chiudere un programma, ma dall’in-
terno del programma stesso; avendo a che fare con un sistema multitasking resta da affrontare
l’argomento dal punto di vista di come il sistema gestisce la conclusione dei processi.
Abbiamo visto in sez. 2.1.2 le tre modalità con cui un programma viene terminato in maniera
normale: la chiamata di exit (che esegue le funzioni registrate per l’uscita e chiude gli stream),
il ritorno dalla funzione main (equivalente alla chiamata di exit), e la chiamata ad _exit (che
passa direttamente alle operazioni di terminazione del processo da parte del kernel).
Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle modalità di
conclusione anomala; queste sono in sostanza due: il programma può chiamare la funzione abort
per invocare una chiusura anomala, o essere terminato da un segnale (torneremo sui segnali in
cap. 9). In realtà anche la prima modalità si riconduce alla seconda, dato che abort si limita a
generare il segnale SIGABRT.
Qualunque sia la modalità di conclusione di un processo, il kernel esegue comunque una serie
di operazioni: chiude tutti i file aperti, rilascia la memoria che stava usando, e cos`ı via; l’elenco
completo delle operazioni eseguite alla chiusura di un processo è il seguente:
• tutti i file descriptor sono chiusi;
• viene memorizzato lo stato di terminazione del processo;
• ad ogni processo figlio viene assegnato un nuovo padre (in genere init);
• viene inviato il segnale SIGCHLD al processo padre (vedi sez. 9.3.6);
• se il processo è un leader di sessione ed il suo terminale di controllo è quello della sessione
viene mandato un segnale di SIGHUP a tutti i processi del gruppo di foreground e il terminale
di controllo viene disconnesso (vedi sez. 10.1.3);
• se la conclusione di un processo rende orfano un process group ciascun membro del gruppo
viene bloccato, e poi gli vengono inviati in successione i segnali SIGHUP e SIGCONT (vedi
ancora sez. 10.1.3).
Oltre queste operazioni è però necessario poter disporre di un meccanismo ulteriore che
consenta di sapere come la terminazione è avvenuta: dato che in un sistema unix-like tutto viene
gestito attraverso i processi, il meccanismo scelto consiste nel riportare lo stato di terminazione
(il cosiddetto termination status) al processo padre.
Nel caso di conclusione normale, abbiamo visto in sez. 2.1.2 che lo stato di uscita del processo
viene caratterizzato tramite il valore del cosiddetto exit status, cioè il valore passato alle funzioni
exit o _exit (o dal valore di ritorno per main). Ma se il processo viene concluso in maniera
anomala il programma non può specificare nessun exit status, ed è il kernel che deve generare
autonomamente il termination status per indicare le ragioni della conclusione anomala.
Si noti la distinzione fra exit status e termination status: quello che contraddistingue lo stato
di chiusura del processo e viene riportato attraverso le funzioni wait o waitpid (vedi sez. 3.2.4)
è sempre quest’ultimo; in caso di conclusione normale il kernel usa il primo (nel codice eseguito
da _exit) per produrre il secondo.
La scelta di riportare al padre lo stato di terminazione dei figli, pur essendo l’unica possibile,
comporta comunque alcune complicazioni: infatti se alla sua creazione è scontato che ogni nuovo

processo ha un padre, non è detto che sia cos`ı alla sua conclusione, dato che il padre potrebbe
essere già terminato; si potrebbe avere cioè quello che si chiama un processo orfano.
Questa complicazione viene superata facendo in modo che il processo orfano venga adottato
da init. Come già accennato quando un processo termina, il kernel controlla se è il padre di
altri processi in esecuzione: in caso positivo allora il ppid di tutti questi processi viene sostituito
con il pid di init (e cioè con 1); in questo modo ogni processo avrà sempre un padre (nel caso
possiamo parlare di un padre adottivo) cui riportare il suo stato di terminazione. Come verifica
di questo comportamento possiamo eseguire il nostro programma forktest imponendo a ciascun
processo figlio due secondi di attesa prima di uscire, il risultato è:
[piccardi@selidor sources]$ ./forktest -c2 3
Go to next child
Go to next child
Go to next child
[piccardi@selidor sources]$ Child 3, parent 1, exiting
come si può notare in questo caso il processo padre si conclude prima dei figli, tornando alla
shell, che stampa il prompt sul terminale: circa due secondi dopo viene stampato a video anche
l’output dei tre figli che terminano, e come si può notare in questo caso, al contrario di quanto
visto in precedenza, essi riportano 1 come ppid.
Altrettanto rilevante è il caso in cui il figlio termina prima del padre, perché non è detto che
il padre possa ricevere immediatamente lo stato di terminazione, quindi il kernel deve comunque
conservare una certa quantità di informazioni riguardo ai processi che sta terminando.
Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e memorizzando
alcuni dati essenziali, come il pid, i tempi di CPU usati dal processo (vedi sez. 8.4.1) e lo stato
di terminazione, mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
processi che sono terminati, ma il cui stato di terminazione non è stato ancora ricevuto dal padre
sono chiamati zombie, essi restano presenti nella tabella dei processi ed in genere possono essere
identificati dall’output di ps per la presenza di una Z nella colonna che ne indica lo stato (vedi
tab. 3.8). Quando il padre effettuerà la lettura dello stato di uscita anche questa informazione,
non più necessaria, verrà scartata e la terminazione potrà dirsi completamente conclusa.
Possiamo utilizzare il nostro programma di prova per analizzare anche questa condizione:
lanciamo il comando forktest in background (vedi sez. 10.1), indicando al processo padre di
aspettare 10 secondi prima di uscire; in questo caso, usando ps sullo stesso terminale (prima
dello scadere dei 10 secondi) otterremo:
[piccardi@selidor sources]$ ps T
PID TTY STAT TIME COMMAND
419 pts/0 S 0:00 bash
568 pts/0 S 0:00 ./forktest -e10 3
569 pts/0 Z 0:00 [forktest <defunct>]
572 pts/0 R 0:00 ps T
e come si vede, dato che non si è fatto nulla per riceverne lo stato di terminazione, i tre processi
figli sono ancora presenti pur essendosi conclusi, con lo stato di zombie e l’indicazione che sono
stati terminati.

La possibilità di avere degli zombie deve essere tenuta sempre presente quando si scrive un
programma che deve essere mantenuto in esecuzione a lungo e creare molti figli. In questo caso si
deve sempre avere cura di far leggere l’eventuale stato di uscita di tutti i figli (in genere questo si
fa attraverso un apposito signal handler, che chiama la funzione wait, vedi sez. 9.3.6 e sez. 3.2.4).
Questa operazione è necessaria perché anche se gli zombie non consumano risorse di memoria o
processore, occupano comunque una voce nella tabella dei processi, che a lungo andare potrebbe
esaurirsi.
Si noti che quando un processo adottato da init termina, esso non diviene uno zombie;
questo perché una delle funzioni di init è appunto quella di chiamare la funzione wait per i
processi cui fa da padre, completandone la terminazione. Questo è quanto avviene anche quando,
come nel caso del precedente esempio con forktest, il padre termina con dei figli in stato di
zombie: alla sua terminazione infatti tutti i suoi figli (compresi gli zombie) verranno adottati da
init, il quale provvederà a completarne la terminazione.
Si tenga presente infine che siccome gli zombie sono processi già usciti, non c’è modo di
eliminarli con il comando kill; l’unica possibilità di cancellarli dalla tabella dei processi è
quella di terminare il processo che li ha generati, in modo che init possa adottarli e provvedere
a concluderne la terminazione.
3.2.4 Le funzioni di attesa e ricezione degli stati di uscita
Uno degli usi più comuni delle capacità multitasking di un sistema unix-like consiste nella crea-
zione di programmi di tipo server, in cui un processo principale attende le richieste che vengono
poi soddisfatte da una serie di processi figli. Si è già sottolineato al paragrafo precedente come in
questo caso diventi necessario gestire esplicitamente la conclusione dei figli onde evitare di riem-
pire di zombie la tabella dei processi; le funzioni deputate a questo compito sono principalmente
due, la prima è wait ed il suo prototipo è:
#include <sys/wait.h>
pid_t wait(int *status)
Sospende il processo corrente finché un figlio non è uscito, o finché un segnale termina il
processo o chiama una funzione di gestione.
La funzione restituisce il pid del figlio in caso di successo e -1 in caso di errore; errno può assumere
i valori:
EINTR la funzione è stata interrotta da un segnale.
Questa funzione è presente fin dalle prime versioni di Unix; essa ritorna non appena un
qualunque processo figlio termina. Se un figlio è già terminato prima della chiamata la funzione
ritorna immediatamente, se più di un figlio è già terminato occorre continuare chiamare la
funzione più volte se si vuole recuperare lo stato di terminazione di tutti quanti.
Al ritorno della funzione lo stato di terminazione del figlio viene salvato nella variabile punta-
ta da status e tutte le risorse del kernel relative al processo (vedi sez. 3.2.3) vengono rilasciate.
Nel caso un processo abbia più figli il valore di ritorno della funzione sarà impostato al pid del
processo di cui si è ricevuto lo stato di terminazione, cosa che permette di identificare qual è il
figlio che è terminato.
Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna all’uscita di un
qualunque processo figlio. Nelle occasioni in cui è necessario attendere la conclusione di un
processo specifico occorrerebbe predisporre un meccanismo che tenga conto dei processi già
terminati, e provvedere a ripetere la chiamata alla funzione nel caso il processo cercato sia
ancora attivo.
Per questo motivo lo standard POSIX.1 ha introdotto una seconda funzione che effettua lo
stesso servizio, ma dispone di una serie di funzionalità più ampie, legate anche al controllo di

sessione (si veda sez. 10.1). Dato che è possibile ottenere lo stesso comportamento di wait12 si
consiglia di utilizzare sempre questa nuova funzione, waitpid, il cui prototipo è:
pid_t waitpid(pid_t pid, int *status, int options)
Attende la conclusione di un processo figlio.
La funzione restituisce il pid del processo che è uscito, 0 se è stata specificata l’opzione WNOHANG
e il processo non è uscito e -1 per un errore, nel qual caso errno assumerà i valori:
EINTR non è stata specificata l’opzione WNOHANG e la funzione è stata interrotta da un segnale.
ECHILD il processo specificato da pid non esiste o non è figlio del processo chiamante.
EINVAL si è specificato un valore non valido per l’argomento options.
La prima differenza fra le due funzioni è che con waitpid si può specificare in maniera
flessibile quale processo attendere, sulla base del valore fornito dall’argomento pid, questo può
assumere diversi valori, secondo lo specchietto riportato in tab. 3.1, dove si sono riportate anche
le costanti definite per indicare alcuni di essi.
Valore Costante Significato
< −1 – Attende per un figlio il cui process group (vedi sez. 10.1.2)
è uguale al valore assoluto di pid.
−1 WAIT_ANY Attende per un figlio qualsiasi, usata in questa maniera
senza specificare nessuna opzione è equivalente a wait.
0 WAIT_MYPGRP Attende per un figlio il cui process group (vedi sez. 10.1.2)
è uguale a quello del processo chiamante.
> 0 – Attende per un figlio il cui pid è uguale al valore di pid.
Tabella 3.1: Significato dei valori dell’argomento pid della funzione waitpid.
Il comportamento di waitpid può inoltre essere modificato passando alla funzione delle
opportune opzioni tramite l’argomento options; questo deve essere specificato come maschera
binaria dei flag riportati nella prima parte in tab. 3.2 che possono essere combinati fra loro con
un OR aritmetico. Nella seconda parte della stessa tabella si sono riportati anche alcuni valori
non standard specifici di Linux, che consentono un controllo più dettagliato per i processi creati
con la system call generica clone (vedi sez. 3.5.1) usati principalmente per la gestione della
terminazione dei thread (vedi sez. ??).
Macro Descrizione
WNOHANG La funzione ritorna immediatamente anche se non è
terminato nessun processo figlio.
WUNTRACED Ritorna anche se un processo figlio è stato fermato.
WCONTINUED Ritorna anche quando un processo figlio che era stato
fermato ha ripreso l’esecuzione.13
__WCLONE Attende solo per i figli creati con clone (vedi sez. 3.5.1),
vale a dire processi che non emettono nessun segna-
le o emettono un segnale diverso da SIGCHLD alla
terminazione.
__WALL Attende per qualunque processo figlio.
__WNOTHREAD Non attende per i figli di altri thread dello stesso gruppo.
Tabella 3.2: Costanti che identificano i bit dell’argomento options della funzione waitpid.
12
in effetti il codice wait(&status) è del tutto equivalente a waitpid(WAIT_ANY, &status, 0).
13
disponibile solo a partire dal kernel 2.6.10.

L’uso dell’opzione WNOHANG consente di prevenire il blocco della funzione qualora nessun figlio
sia uscito (o non si siano verificate le altre condizioni per l’uscita della funzione); in tal caso la
funzione ritornerà un valore nullo anziché positivo.14
Le altre due opzioni WUNTRACED e WCONTINUED consentono rispettivamente di tracciare non
la terminazione di un processo, ma il fatto che esso sia stato fermato, o fatto ripartire, e sono
utilizzate per la gestione del controllo di sessione (vedi sez. 10.1).
Nel caso di WUNTRACED la funzione ritorna, restituendone il pid, quando un processo figlio
entra nello stato stopped15 (vedi tab. 3.8), mentre con WCONTINUED la funzione ritorna quando
un processo in stato stopped riprende l’esecuzione per la ricezione del segnale SIGCONT (l’uso di
questi segnali per il controllo di sessione è dettagliato in sez. 10.1.3).
La terminazione di un processo figlio (cos`ı come gli altri eventi osservabili con waitpid)
è chiaramente un evento asincrono rispetto all’esecuzione di un programma e può avvenire in
un qualunque momento. Per questo motivo, come accennato nella sezione precedente, una delle
azioni prese dal kernel alla conclusione di un processo è quella di mandare un segnale di SIGCHLD
al padre. L’azione predefinita (si veda sez. 9.1.1) per questo segnale è di essere ignorato, ma la
sua generazione costituisce il meccanismo di comunicazione asincrona con cui il kernel avverte
il processo padre che uno dei suoi figli è terminato.
Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4 al kernel 2.6,
quest’ultimo infatti si è adeguato alle prescrizioni dello standard POSIX.1-2001,16 e come da
esso richiesto se SIGCHLD viene ignorato, o se si imposta il flag di SA_NOCLDSTOP nella ricezione
dello stesso (si veda sez. 9.4.3) i processi figli che terminano non diventano zombie e sia wait che
waitpid si bloccano fintanto che tutti i processi figli non sono terminati, dopo di che falliscono
con un errore di ENOCHLD.17
Con i kernel della serie 2.4 e tutti i kernel delle serie precedenti entrambe le funzioni di attesa
ignorano questa prescrizione18 e si comportano sempre nello stesso modo, indipendentemente dal
fatto SIGCHLD sia ignorato o meno: attendono la terminazione di un processo figlio e ritornano
il relativo pid e lo stato di terminazione nell’argomento status.
In generale in un programma non si vuole essere forzati ad attendere la conclusione di un
processo figlio per proseguire l’esecuzione, specie se tutto questo serve solo per leggerne lo stato
di chiusura (ed evitare eventualmente la presenza di zombie).
Per questo la modalità più comune di chiamare queste funzioni è quella di utilizzarle al-
l’interno di un signal handler (vedremo un esempio di come gestire SIGCHLD con i segnali in
sez. 9.4.1). In questo caso infatti, dato che il segnale è generato dalla terminazione di un figlio,
avremo la certezza che la chiamata a waitpid non si bloccherà.
Come accennato sia wait che waitpid restituiscono lo stato di terminazione del processo
tramite il puntatore status (se non interessa memorizzare lo stato si può passare un puntatore
nullo). Il valore restituito da entrambe le funzioni dipende dall’implementazione, ma tradizio-
nalmente alcuni bit (in genere 8) sono riservati per memorizzare lo stato di uscita, e altri per
14
anche in questo caso un valore positivo indicherà il pid del processo di cui si è ricevuto lo stato ed un valore
negativo un errore.
15
in realtà viene notificato soltanto il caso in cui il processo è stato fermato da un segnale di stop (vedi sez. 10.1.3),
e non quello in cui lo stato stopped è dovuto all’uso di ptrace (vedi sez. 3.5.3).
16
una revisione del 2001 dello standard POSIX.1 che ha aggiunto dei requisiti e delle nuove funzioni, come
waitid.
17
questo è anche il motivo per cui le opzioni WUNTRACED e WCONTINUED sono utilizzabili soltanto qualora non si
sia impostato il flag di SA_NOCLDSTOP per il segnale SIGCHLD.
18
lo standard POSIX.1 originale infatti lascia indefinito il comportamento di queste funzioni quando SIGCHLD
viene ignorato.
20
questa macro non è definita dallo standard POSIX.1-2001, ma è presente come estensione sia in Linux che
in altri Unix, deve essere pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un blocco #ifdef
WCOREDUMP ... #endif.
20
è presente solo a partire dal kernel 2.6.10.

Macro Descrizione
WIFEXITED(s) Condizione vera (valore non nullo) per un processo figlio che sia
terminato normalmente.
WEXITSTATUS(s) Restituisce gli otto bit meno significativi dello stato di uscita del pro-
cesso (passato attraverso _exit, exit o come valore di ritorno di main);
può essere valutata solo se WIFEXITED ha restituito un valore non nullo.
WIFSIGNALED(s) Condizione vera se il processo figlio è terminato in maniera anomala a
causa di un segnale che non è stato catturato (vedi sez. 9.1.4).
WTERMSIG(s) Restituisce il numero del segnale che ha causato la terminazione ano-
mala del processo; può essere valutata solo se WIFSIGNALED ha restituito
un valore non nullo.
WCOREDUMP(s) Vera se il processo terminato ha generato un file di core dump; può
essere valutata solo se WIFSIGNALED ha restituito un valore non nullo.19
WIFSTOPPED(s) Vera se il processo che ha causato il ritorno di waitpid è bloccato; l’uso
è possibile solo con waitpid avendo specificato l’opzione WUNTRACED.
WSTOPSIG(s) Restituisce il numero del segnale che ha bloccato il processo; può essere
valutata solo se WIFSTOPPED ha restituito un valore non nullo.
WIFCONTINUED(s) Vera se il processo che ha causato il ritorno è stato riavviato da un
SIGCONT.20
Tabella 3.3: Descrizione delle varie macro di preprocessore utilizzabili per verificare lo stato di terminazione s
di un processo.
indicare il segnale che ha causato la terminazione (in caso di conclusione anomala), uno per
indicare se è stato generato un core dump, ecc.21
Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per analizzare
lo stato di uscita. Esse sono definite sempre in <sys/wait.h> ed elencate in tab. 3.3; si tenga
presente che queste macro prevedono che gli si passi come parametro la variabile di tipo int
puntata dall’argomento status restituito da wait o waitpid.
Si tenga conto che nel caso di conclusione anomala il valore restituito da WTERMSIG può essere
confrontato con le costanti che identificano i segnali definite in signal.h ed elencate in tab. 9.3,
e stampato usando le apposite funzioni trattate in sez. 9.2.9.
A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è stata in-
trodotta una nuova funzione di attesa che consente di avere un controllo molto più preciso sui
possibili cambiamenti di stato dei processi figli e più dettagli sullo stato di uscita; la funzione è
waitid ed il suo prototipo è:
int waitid(idtype_t idtype, id_t id, siginfo_t *infop, int options)
Attende la conclusione di un processo figlio.
La funzione restituisce 0 in caso di successo e -1 per un errore, nel qual caso errno assumerà i
valori:
EINTR se non è stata specificata l’opzione WNOHANG e la funzione è stata interrotta da un
segnale.
ECHILD il processo specificato da pid non esiste o non è figlio del processo chiamante.
EINVAL si è specificato un valore non valido per l’argomento options.
La funzione prevede che si specifichi quali processi si intendono osservare usando i due ar-
gomenti idtype ed id; il primo indica se ci si vuole porre in attesa su un singolo processo, un
gruppo di processi o un processo qualsiasi, e deve essere specificato secondo uno dei valori di
tab. 3.4; il secondo indica, a seconda del valore del primo, quale processo o quale gruppo di
processi selezionare.
21
le definizioni esatte si possono trovare in <bits/waitstatus.h> ma questo file non deve mai essere usato
direttamente, esso viene incluso attraverso <sys/wait.h>.

Macro Descrizione
P_PID Indica la richiesta di attendere per un processo figlio il
cui pid corrisponda al valore dell’argomento id.
P_PGID Indica la richiesta di attendere per un processo figlio ap-
partenente al process group (vedi sez. 10.1.2) il cui pgid
corrisponda al valore dell’argomento id.
P_ALL Indica la richiesta di attendere per un processo figlio
generico, il valore dell’argomento id viene ignorato.
Tabella 3.4: Costanti per i valori dell’argomento idtype della funzione waitid.
Come per waitpid anche il comportamento di waitid viene controllato dall’argomento
options, da specificare come maschera binaria dei valori riportati in tab. 3.5. Benché alcuni
di questi siano identici come significato ed effetto ai precedenti di tab. 3.2, ci sono delle diffe-
renze significative: in questo caso si dovrà specificare esplicitamente l’attesa della terminazione
di un processo impostando l’opzione WEXITED, mentre il precedente WUNTRACED è sostituito da
WSTOPPED. Infine è stata aggiunta l’opzione WNOWAIT che consente una lettura dello stato mante-
nendo il processo in attesa di ricezione, cos`ı che una successiva chiamata possa di nuovo riceverne
lo stato.
Macro Descrizione
WEXITED Ritorna quando un processo figlio è terminato.
WNOHANG Ritorna immediatamente anche se non c’è niente da
notificare.
WSTOPPED Ritorna quando un processo figlio è stato fermato.
WCONTINUED Ritorna quando un processo figlio che era stato fermato
ha ripreso l’esecuzione.
WNOWAIT Lascia il processo ancora in attesa di ricezione, cos`ı che
una successiva chiamata possa di nuovo riceverne lo stato.
Tabella 3.5: Costanti che identificano i bit dell’argomento options della funzione waitid.
La funzione waitid restituisce un valore nullo in caso di successo, e −1 in caso di errore; viene
restituito un valore nullo anche se è stata specificata l’opzione WNOHANG e la funzione è ritornata
immediatamente senza che nessun figlio sia terminato. Pertanto per verificare il motivo del
ritorno della funzione occorre analizzare le informazioni che essa restituisce; queste, al contrario
delle precedenti wait e waitpid che usavano un semplice valore numerico, sono ritornate in una
struttura di tipo siginfo_t (vedi fig. 9.9) all’indirizzo puntato dall’argomento infop.
Tratteremo nei dettagli la struttura siginfo_t ed il significato dei suoi vari campi in
sez. 9.4.3, per quanto ci interessa qui basta dire che al ritorno di waitid verranno avvalorati i
seguenti campi:
si_pid con il pid del figlio.
si_uid con l’user-ID reale (vedi sez. 3.3) del figlio.
si_signo con SIGCHLD.
si_status con lo stato di uscita del figlio o con il segnale che lo ha terminato, fermato o
riavviato.
si_code con uno fra CLD_EXITED, CLD_KILLED, CLD_STOPPED, CLD_CONTINUED, CLD_TRAPPED
e CLD_DUMPED a indicare la ragione del ritorno della funzione, il cui significato è,
nell’ordine: uscita normale, terminazione da segnale, processo fermato, processo
riavviato, processo terminato in core dump.

Infine Linux, seguendo un’estensione di BSD, supporta altre due funzioni per la lettura dello
stato di terminazione di un processo, analoghe alle precedenti ma che prevedono un ulteriore
argomento attraverso il quale il kernel può restituire al padre informazioni sulle risorse (vedi
sez. 8.3) usate dal processo terminato e dai vari figli. Le due funzioni sono wait3 e wait4, che
diventano accessibili definendo la macro _USE_BSD; i loro prototipi sono:
#include <sys/times.h>
#include <sys/resource.h>
pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage)
È identica a waitpid sia per comportamento che per i valori degli argomenti, ma restituisce
in rusage un sommario delle risorse usate dal processo.
pid_t wait3(int *status, int options, struct rusage *rusage)
Prima versione, equivalente a wait4(-1, &status, opt, rusage) è ormai deprecata in
favore di wait4.
la struttura rusage è definita in sys/resource.h, e viene utilizzata anche dalla funzione getrusage
(vedi sez. 8.3.1) per ottenere le risorse di sistema usate da un processo; la sua definizione è
riportata in fig. 8.6.
3.2.5 La funzione exec e le funzioni di esecuzione dei programmi
Abbiamo già detto che una delle modalità principali con cui si utilizzano i processi in Unix è
quella di usarli per lanciare nuovi programmi: questo viene fatto attraverso una delle funzioni
della famiglia exec. Quando un processo chiama una di queste funzioni esso viene completamente
sostituito dal nuovo programma; il pid del processo non cambia, dato che non viene creato un
nuovo processo, la funzione semplicemente rimpiazza lo stack, lo heap, i dati ed il testo del
processo corrente con un nuovo programma letto da disco.
Ci sono sei diverse versioni di exec (per questo la si è chiamata famiglia di funzioni) che
possono essere usate per questo compito, in realtà (come mostrato in fig. 3.4), sono tutte un
front-end a execve. Il prototipo di quest’ultima è:
#include <unistd.h>
int execve(const char *filename, char *const argv[], char *const envp[])
Esegue il programma contenuto nel file filename.
La funzione ritorna solo in caso di errore, restituendo -1; nel qual caso errno può assumere i valori:
EACCES il file non è eseguibile, oppure il filesystem è montato in noexec, oppure non è un file
regolare o un interprete.
EPERM il file ha i bit suid o sgid, l’utente non è root, il processo viene tracciato, o il filesystem
è montato con l’opzione nosuid.
ENOEXEC il file è in un formato non eseguibile o non riconosciuto come tale, o compilato per
un’altra architettura.
ENOENT il file o una delle librerie dinamiche o l’interprete necessari per eseguirlo non esistono.
ETXTBSY l’eseguibile è aperto in scrittura da uno o più processi.
EINVAL l’eseguibile ELF ha più di un segmento PF_INTERP, cioè chiede di essere eseguito da
più di un interprete.
ELIBBAD un interprete ELF non è in un formato riconoscibile.
E2BIG la lista degli argomenti è troppo grande.
ed inoltre anche EFAULT, ENOMEM, EIO, ENAMETOOLONG, ELOOP, ENOTDIR, ENFILE, EMFILE.
La funzione exec esegue il file o lo script indicato da filename, passandogli la lista di
argomenti indicata da argv e come ambiente la lista di stringhe indicata da envp; entrambe le
liste devono essere terminate da un puntatore nullo. I vettori degli argomenti e dell’ambiente

possono essere acceduti dal nuovo programma quando la sua funzione main è dichiarata nella
forma main(int argc, char *argv[], char *envp[]).
Le altre funzioni della famiglia servono per fornire all’utente una serie di possibili diverse
interfacce per la creazione di un nuovo processo. I loro prototipi sono:
#include <unistd.h>
int execl(const char *path, const char *arg, ...)
int execv(const char *path, char *const argv[])
int execle(const char *path, const char *arg, ..., char * const envp[])
int execlp(const char *file, const char *arg, ...)
int execvp(const char *file, char *const argv[])
Sostituiscono l’immagine corrente del processo con quella indicata nel primo argomento. Gli
argomenti successivi consentono di specificare gli argomenti a linea di comando e l’ambiente
ricevuti dal nuovo processo.
Queste funzioni ritornano solo in caso di errore, restituendo -1; nel qual caso errno assumerà i
valori visti in precedenza per execve.
Per capire meglio le differenze fra le funzioni della famiglia si può fare riferimento allo spec-
chietto riportato in tab. 3.6. La prima differenza riguarda le modalità di passaggio dei valori che
poi andranno a costituire gli argomenti a linea di comando (cioè i valori di argv e argc visti
dalla funzione main del programma chiamato).
Queste modalità sono due e sono riassunte dagli mnemonici v e l che stanno rispettivamente
per vector e list. Nel primo caso gli argomenti sono passati tramite il vettore di puntatori argv[]
a stringhe terminate con zero che costituiranno gli argomenti a riga di comando, questo vettore
deve essere terminato da un puntatore nullo.
Nel secondo caso le stringhe degli argomenti sono passate alla funzione come lista di puntatori,
nella forma:
char *arg0 , char *arg1 , ..., char *argn , NULL
che deve essere terminata da un puntatore nullo. In entrambi i casi vale la convenzione che
il primo argomento (arg0 o argv[0]) viene usato per indicare il nome del file che contiene il
programma che verrà eseguito.
Caratteristiche Funzioni
execl execlp execle execv execvp execve
argomenti a lista • • •
argomenti a vettore • • •
filename completo • • • •
ricerca su PATH • •
ambiente a vettore • •
uso di environ • • • •
Tabella 3.6: Confronto delle caratteristiche delle varie funzioni della famiglia exec.
La seconda differenza fra le funzioni riguarda le modalità con cui si specifica il programma che
si vuole eseguire. Con lo mnemonico p si indicano le due funzioni che replicano il comportamento
della shell nello specificare il comando da eseguire; quando l’argomento file non contiene una
“/” esso viene considerato come un nome di programma, e viene eseguita automaticamente una
ricerca fra i file presenti nella lista di directory specificate dalla variabile di ambiente PATH. Il file
che viene posto in esecuzione è il primo che viene trovato. Se si ha un errore relativo a permessi
di accesso insufficienti (cioè l’esecuzione della sottostante execve ritorna un EACCES), la ricerca
viene proseguita nelle eventuali ulteriori directory indicate in PATH; solo se non viene trovato
nessun altro file viene finalmente restituito EACCES.
Le altre quattro funzioni si limitano invece a cercare di eseguire il file indicato dall’argomento
path, che viene interpretato come il pathname del programma.

Figura 3.4: La interrelazione fra le sei funzioni della famiglia exec.
La terza differenza è come viene passata la lista delle variabili di ambiente. Con lo mnemonico
e vengono indicate quelle funzioni che necessitano di un vettore di parametri envp[] analogo a
quello usato per gli argomenti a riga di comando (terminato quindi da un NULL), le altre usano il
valore della variabile environ (vedi sez. 2.3.3) del processo di partenza per costruire l’ambiente.
Oltre a mantenere lo stesso pid, il nuovo programma fatto partire da exec mantiene la gran
parte delle proprietà del processo chiamante; una lista delle più significative è la seguente:
• il process id (pid) ed il parent process id (ppid);
• l’user-ID reale, il group-ID reale ed i group-ID supplementari (vedi sez. 3.3.1);
• il session ID (sid) ed il process group ID (pgid), vedi sez. 10.1.2;
• il terminale di controllo (vedi sez. 10.1.3);
• il tempo restante ad un allarme (vedi sez. 9.3.4);
• la directory radice e la directory di lavoro corrente (vedi sez. 5.1.7);
• la maschera di creazione dei file (umask, vedi sez. 5.3.3) ed i lock sui file (vedi sez. 12.1);
• i limiti sulle risorse (vedi sez. 8.3.2);
• i valori delle variabili tms_utime, tms_stime; tms_cutime, tms_ustime (vedi sez. 8.4.2);
• la maschera dei segnali (si veda sez. 9.4.4).
Una serie di proprietà del processo originale, che non avrebbe senso mantenere in un pro-
gramma che esegue un codice completamente diverso in uno spazio di indirizzi totalmente indi-
pendente e ricreato da zero, vengono perse con l’esecuzione di exec; lo standard POSIX.1-2001
prevede che le seguenti proprietà non vengano preservate:
• l’insieme dei segnali pendenti (vedi sez. 9.3.1), che viene cancellato;
• gli eventuali stack alternativi per i segnali (vedi sez. 9.5.3);
• i directory stream (vedi sez. 5.1.6), che vengono chiusi;
• le mappature dei file in memoria (vedi sez. 12.4.1);
• i segmenti di memoria condivisa SysV (vedi sez. 11.2.6) e POSIX (vedi sez. 11.4.3);
• i blocchi sulla memoria (vedi sez. 2.2.4);
• le funzioni registrate all’uscita (vedi sez. 2.1.4);
• i semafori e le code di messaggi POSIX (vedi sez. 11.4.4 e sez. 11.4.2);
• i timer POSIX (vedi sez. 9.5.2).
I segnali che sono stati impostati per essere ignorati nel processo chiamante mantengono
la stessa impostazione pure nel nuovo programma, ma tutti gli altri segnali, ed in particolare
quelli per i quali è stato installato un gestore vengono impostati alla loro azione predefinita (vedi
sez. 9.3.1). Un caso speciale è il segnale SIGCHLD che, quando impostato a SIG_IGN, potrebbe
anche essere reimpostato a SIG_DFL, anche se questo con Linux non avviene.22
22
lo standard POSIX.1-2001 prevede che questo comportamento sia deciso dalla singola implementazione, quella
di Linux è di non modificare l’impostazione precedente.

Oltre alle precedenti che sono completamente generali e disponibili anche su altri sistemi
unix-like, esistono altre proprietà dei processi, attinenti caratteristiche specifiche di Linux, che
non vengono preservate nell’esecuzione della funzione exec, queste sono:
• le operazione di I/O asincrono (vedi sez. 12.3.3) pendenti vengono cancellate;
• le capabilities vengono modificate come illustrato in sez. 5.4.4;
• tutti i thread tranne il chiamante (vedi sez. ??) sono cancellati e tutti gli oggetti ad essi
relativi (vedi sez. ??) rimossi;
• viene impostato il flag PR_SET_DUMPABLE di prctl (vedi sez. 3.5.2) a meno che il program-
ma da eseguire non sia suid o sgid (vedi sez. 3.3.1);
• il flag PR_SET_KEEPCAPS di prctl (vedi sez. 3.5.2) viene cancellato;
• il nome del processo viene impostato al nome del file contenente il programma messo in
esecuzione;
• il segnale di terminazione viene reimpostato a SIGCHLD;
• l’ambiente viene reinizializzato impostando le variabili attinenti alla localizzazione al valore
di default POSIX.
La gestione dei file aperti nel passaggio al nuovo programma lanciato con exec dipende dal
valore che ha il flag di close-on-exec (vedi anche sez. 6.3.6) per ciascun file descriptor. I file per
cui è impostato vengono chiusi, tutti gli altri file restano aperti. Questo significa che il com-
portamento predefinito è che i file restano aperti attraverso una exec, a meno di una chiamata
esplicita a fcntl che imposti il suddetto flag. Per le directory, lo standard POSIX.1 richiede che
esse vengano chiuse attraverso una exec, in genere questo è fatto dalla funzione opendir (vedi
sez. 5.1.6) che effettua da sola l’impostazione del flag di close-on-exec sulle directory che apre,
in maniera trasparente all’utente.
Il comportamento della funzione in relazione agli identificatori relativi al controllo di accesso
verrà trattato in dettaglio in sez. 3.3, qui è sufficiente anticipare (si faccia riferimento a sez. 3.3.1
per la definizione di questi identificatori) come l’user-ID reale ed il group-ID reale restano sempre
gli stessi, mentre l’user-ID salvato ed il group-ID salvato vengono impostati rispettivamente
all’user-ID effettivo ed il group-ID effettivo, questi ultimi normalmente non vengono modificati,
a meno che il file di cui viene chiesta l’esecuzione non abbia o il suid bit o lo sgid bit impostato,
in questo caso l’user-ID effettivo ed il group-ID effettivo vengono impostati rispettivamente
all’utente o al gruppo cui il file appartiene.
Se il file da eseguire è in formato a.out e necessita di librerie condivise, viene lanciato il
linker dinamico /lib/ld.so prima del programma per caricare le librerie necessarie ed effettuare
il link dell’eseguibile.23 Se il programma è in formato ELF per caricare le librerie dinamiche
viene usato l’interprete indicato nel segmento PT_INTERP previsto dal formato stesso, in genere
questo è /lib/ld-linux.so.1 per programmi collegati con le libc5, e /lib/ld-linux.so.2 per
programmi collegati con le glibc.
Infine nel caso il file sia uno script esso deve iniziare con una linea nella forma #!/path/to/interpreter
[argomenti] dove l’interprete indicato deve essere un programma valido (binario, non un al-
tro script) che verrà chiamato come se si fosse eseguito il comando interpreter [argomenti]
filename.24
Con la famiglia delle exec si chiude il novero delle funzioni su cui è basata la gestione dei
processi in Unix: con fork si crea un nuovo processo, con exec si lancia un nuovo programma,
23
il formato è ormai in completo disuso, per cui è molto probabile che non il relativo supporto non sia disponibile.
24
si tenga presente che con Linux quanto viene scritto come argomenti viene passato all’interprete co-
me un unico argomento con una unica stringa di lunghezza massima di 127 caratteri e se questa di-
mensione viene ecceduta la stringa viene troncata; altri Unix hanno dimensioni massime diverse, e diver-
si comportamenti, ad esempio FreeBSD esegue la scansione della riga e la divide nei vari argomenti e se
è troppo lunga restituisce un errore di ENAMETOOLONG, una comparazione dei vari comportamenti si trova su
http://www.in-ulm.de/˜mascheck/various/shebang/.

con exit e wait si effettua e verifica la conclusione dei processi. Tutte le altre funzioni sono
ausiliarie e servono per la lettura e l’impostazione dei vari parametri connessi ai processi.
3.3 Il controllo di accesso
In questa sezione esamineremo le problematiche relative al controllo di accesso dal punto di vista
dei processi; vedremo quali sono gli identificatori usati, come questi possono essere modificati
nella creazione e nel lancio di nuovi processi, le varie funzioni per la loro manipolazione diretta
e tutte le problematiche connesse ad una gestione accorta dei privilegi.
3.3.1 Gli identificatori del controllo di accesso
Come accennato in sez. 1.1.4 il modello base25 di sicurezza di un sistema unix-like è fondato sui
concetti di utente e gruppo, e sulla separazione fra l’amministratore (root, detto spesso anche
superuser) che non è sottoposto a restrizioni, ed il resto degli utenti, per i quali invece vengono
effettuati i vari controlli di accesso.
Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due identificatori
univoci, lo user-ID ed il group-ID; questi servono al kernel per identificare uno specifico utente o
un gruppo di utenti, per poi poter controllare che essi siano autorizzati a compiere le operazioni
richieste. Ad esempio in sez. 5.3 vedremo come ad ogni file vengano associati un utente ed un
gruppo (i suoi proprietari, indicati appunto tramite un uid ed un gid) che vengono controllati
dal kernel nella gestione dei permessi di accesso.
Dato che tutte le operazioni del sistema vengono compiute dai processi, è evidente che per
poter implementare un controllo sulle operazioni occorre anche poter identificare chi è che ha
lanciato un certo programma, e pertanto anche a ciascun processo dovrà essere associato un
utente e un gruppo.
Un semplice controllo di una corrispondenza fra identificativi non garantisce però sufficiente
flessibilità per tutti quei casi in cui è necessario poter disporre di privilegi diversi, o dover
impersonare un altro utente per un limitato insieme di operazioni. Per questo motivo in generale
tutti gli Unix prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
rispettivamente real ed effective (cioè reali ed effettivi). Nel caso di Linux si aggiungono poi
altri due gruppi, il saved (salvati) ed il filesystem (di filesystem), secondo la situazione illustrata
in tab. 3.7.
Suffisso Gruppo Denominazione Significato
uid real user-ID reale Indica l’utente che ha lanciato il programma.
gid ” group-ID reale Indica il gruppo principale dell’utente che ha
lanciato il programma.
euid effective user-ID effettivo Indica l’utente usato nel controllo di accesso.
egid ” group-ID effettivo Indica il gruppo usato nel controllo di accesso.
– – group-ID supplementari Indicano gli ulteriori gruppi cui l’utente appartiene.
– saved user-ID salvato È una copia dell’euid iniziale.
– ” group-ID salvato È una copia dell’egid iniziale.
fsuid filesystem user-ID di filesystem Indica l’utente effettivo per l’accesso al filesystem.
fsgid ” group-ID di filesystem Indica il gruppo effettivo per l’accesso al filesystem.
Tabella 3.7: Identificatori di utente e gruppo associati a ciascun processo con indicazione dei suffissi usati dalle
varie funzioni di manipolazione.
25
in realtà già esistono estensioni di questo modello base, che lo rendono più flessibile e controllabile, come le
capabilities illustrate in sez. 5.4.4, le ACL per i file (vedi sez. 5.4.2) o il Mandatory Access Control di SELinux;
inoltre basandosi sul lavoro effettuato con SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
infrastruttura di sicurezza, i Linux Security Modules, o LSM, in grado di fornire diversi agganci a livello del kernel
per modularizzare tutti i possibili controlli di accesso.

3.3. IL CONTROLLO DI ACCESSO 69
Al primo gruppo appartengono l’user-ID reale ed il group-ID reale: questi vengono impo-
stati al login ai valori corrispondenti all’utente con cui si accede al sistema (e relativo gruppo
principale). Servono per l’identificazione dell’utente e normalmente non vengono mai cambiati.
In realtà vedremo (in sez. 3.3.2) che è possibile modificarli, ma solo ad un processo che abbia
i privilegi di amministratore; questa possibilità è usata proprio dal programma login che, una
volta completata la procedura di autenticazione, lancia una shell per la quale imposta questi
identificatori ai valori corrispondenti all’utente che entra nel sistema.
Al secondo gruppo appartengono lo user-ID effettivo ed il group-ID effettivo (a cui si aggiun-
gono gli eventuali group-ID supplementari dei gruppi dei quali l’utente fa parte). Questi sono
invece gli identificatori usati nelle verifiche dei permessi del processo e per il controllo di accesso
ai file (argomento affrontato in dettaglio in sez. 5.3.1).
Questi identificatori normalmente sono identici ai corrispondenti del gruppo real tranne nel
caso in cui, come accennato in sez. 3.2.5, il programma che si è posto in esecuzione abbia i
bit suid o sgid impostati (il significato di questi bit è affrontato in dettaglio in sez. 5.3.2). In
questo caso essi saranno impostati all’utente e al gruppo proprietari del file. Questo consente,
per programmi in cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
di un altro (o dell’amministratore).
Come nel caso del pid e del ppid, anche tutti questi identificatori possono essere letti
attraverso le rispettive funzioni: getuid, geteuid, getgid e getegid, i loro prototipi sono:
#include <unistd.h>
uid_t getuid(void)
Restituisce l’user-ID reale del processo corrente.
uid_t geteuid(void)
Restituisce l’user-ID effettivo del processo corrente.
gid_t getgid(void)
Restituisce il group-ID reale del processo corrente.
gid_t getegid(void)
Restituisce il group-ID effettivo del processo corrente.
Queste funzioni non riportano condizioni di errore.
In generale l’uso di privilegi superiori deve essere limitato il più possibile, per evitare abusi e
problemi di sicurezza, per questo occorre anche un meccanismo che consenta ad un programma di
rilasciare gli eventuali maggiori privilegi necessari, una volta che si siano effettuate le operazioni
per i quali erano richiesti, e a poterli eventualmente recuperare in caso servano di nuovo.
Questo in Linux viene fatto usando altri due gruppi di identificatori, il saved ed il filesystem.
Il primo gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è definita la
costante _POSIX_SAVED_IDS,26 il secondo gruppo è specifico di Linux e viene usato per migliorare
la sicurezza con NFS.
L’user-ID salvato ed il group-ID salvato sono copie dell’user-ID effettivo e del group-ID
effettivo del processo padre, e vengono impostati dalla funzione exec all’avvio del processo,
come copie dell’user-ID effettivo e del group-ID effettivo dopo che questi sono stati impostati
tenendo conto di eventuali suid o sgid. Essi quindi consentono di tenere traccia di quale fossero
utente e gruppo effettivi all’inizio dell’esecuzione di un nuovo programma.
L’user-ID di filesystem e il group-ID di filesystem sono un’estensione introdotta in Linux per
rendere più sicuro l’uso di NFS (torneremo sull’argomento in sez. 3.3.2). Essi sono una replica dei
corrispondenti identificatori del gruppo effective, ai quali si sostituiscono per tutte le operazioni
di verifica dei permessi relativi ai file (trattate in sez. 5.3.1). Ogni cambiamento effettuato sugli
identificatori effettivi viene automaticamente riportato su di essi, per cui in condizioni normali si
può tranquillamente ignorarne l’esistenza, in quanto saranno del tutto equivalenti ai precedenti.
26
in caso si abbia a cuore la portabilità del programma su altri Unix è buona norma controllare sempre la
disponibilità di queste funzioni controllando se questa costante è definita.

3.3.2 Le funzioni di gestione degli identificatori dei processi
Le due funzioni più comuni che vengono usate per cambiare identità (cioè utente e gruppo
di appartenenza) ad un processo sono rispettivamente setuid e setgid; come accennato in
sez. 3.3.1 in Linux esse seguono la semantica POSIX che prevede l’esistenza dell’user-ID salvato
e del group-ID salvato; i loro prototipi sono:
#include <unistd.h>
int setuid(uid_t uid)
Imposta l’user-ID del processo corrente.
int setgid(gid_t gid)
Imposta il group-ID del processo corrente.
Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento: l’unico errore possibile è
EPERM.
Il funzionamento di queste due funzioni è analogo, per cui considereremo solo la prima; la
seconda si comporta esattamente allo stesso modo facendo riferimento al group-ID invece che
all’user-ID. Gli eventuali group-ID supplementari non vengono modificati.
L’effetto della chiamata è diverso a seconda dei privilegi del processo; se l’user-ID effettivo è
zero (cioè è quello dell’amministratore di sistema) allora tutti gli identificatori (real, effective e
saved) vengono impostati al valore specificato da uid, altrimenti viene impostato solo l’user-ID
effettivo, e soltanto se il valore specificato corrisponde o all’user-ID reale o all’user-ID salvato.
Negli altri casi viene segnalato un errore (con EPERM).
Come accennato l’uso principale di queste funzioni è quello di poter consentire ad un pro-
gramma con i bit suid o sgid impostati (vedi sez. 5.3.2) di riportare l’user-ID effettivo a quel-
lo dell’utente che ha lanciato il programma, effettuare il lavoro che non necessita di privilegi
aggiuntivi, ed eventualmente tornare indietro.
Come esempio per chiarire l’uso di queste funzioni prendiamo quello con cui viene gestito
l’accesso al file /var/log/utmp. In questo file viene registrato chi sta usando il sistema al mo-
mento corrente; chiaramente non può essere lasciato aperto in scrittura a qualunque utente, che
potrebbe falsificare la registrazione. Per questo motivo questo file (e l’analogo /var/log/wtmp
su cui vengono registrati login e logout) appartengono ad un gruppo dedicato (utmp) ed i pro-
grammi che devono accedervi (ad esempio tutti i programmi di terminale in X, o il programma
screen che crea terminali multipli su una console) appartengono a questo gruppo ed hanno il
bit sgid impostato.
Quando uno di questi programmi (ad esempio xterm) viene lanciato, la situazione degli
identificatori è la seguente:
group-ID reale = gid (del chiamante)
group-ID effettivo = utmp
group-ID salvato = utmp
in questo modo, dato che il group-ID effettivo è quello giusto, il programma può accedere a
/var/log/utmp in scrittura ed aggiornarlo. A questo punto il programma può eseguire una
setgid(getgid()) per impostare il group-ID effettivo a quello dell’utente (e dato che il group-
ID reale corrisponde la funzione avrà successo), in questo modo non sarà possibile lanciare dal
terminale programmi che modificano detto file, in tal caso infatti la situazione degli identificatori
sarebbe:
group-ID reale = gid (invariato)
group-ID effettivo = gid
group-ID salvato = utmp (invariato)

e ogni processo lanciato dal terminale avrebbe comunque gid come group-ID effettivo. All’uscita
dal terminale, per poter di nuovo aggiornare lo stato di /var/log/utmp il programma esegui-
rà una setgid(utmp) (dove utmp è il valore numerico associato al gruppo utmp, ottenuto ad
esempio con una precedente getegid), dato che in questo caso il valore richiesto corrisponde al
group-ID salvato la funzione avrà successo e riporterà la situazione a:
group-ID reale = gid (invariato)
group-ID effettivo = utmp
group-ID salvato = utmp (invariato)
consentendo l’accesso a /var/log/utmp.
Occorre però tenere conto che tutto questo non è possibile con un processo con i privilegi
di amministratore, in tal caso infatti l’esecuzione di una setuid comporta il cambiamento di
tutti gli identificatori associati al processo, rendendo impossibile riguadagnare i privilegi di
amministratore. Questo comportamento è corretto per l’uso che ne fa login una volta che crea
una nuova shell per l’utente; ma quando si vuole cambiare soltanto l’user-ID effettivo del processo
per cedere i privilegi occorre ricorrere ad altre funzioni.
Le due funzioni setreuid e setregid derivano da BSD che, non supportando27 gli iden-
tificatori del gruppo saved, le usa per poter scambiare fra di loro effective e real. I rispettivi
prototipi sono:
#include <unistd.h>
int setreuid(uid_t ruid, uid_t euid)
Imposta l’user-ID reale e l’user-ID effettivo del processo corrente ai valori specificati da
ruid e euid.
int setregid(gid_t rgid, gid_t egid)
Imposta il group-ID reale ed il group-ID effettivo del processo corrente ai valori specificati
da rgid e egid.
EPERM.
La due funzioni sono analoghe ed il loro comportamento è identico; quanto detto per la
prima riguardo l’user-ID, si applica immediatamente alla seconda per il group-ID. I processi
non privilegiati possono impostare solo i valori del loro user-ID effettivo o reale; valori diver-
si comportano il fallimento della chiamata; l’amministratore invece può specificare un valore
qualunque. Specificando un argomento di valore -1 l’identificatore corrispondente verrà lasciato
inalterato.
Con queste funzioni si possono scambiare fra loro gli user-ID reale e effettivo, e pertanto
è possibile implementare un comportamento simile a quello visto in precedenza per setgid,
cedendo i privilegi con un primo scambio, e recuperandoli, eseguito il lavoro non privilegiato,
con un secondo scambio.
In questo caso però occorre porre molta attenzione quando si creano nuovi processi nella
fase intermedia in cui si sono scambiati gli identificatori, in questo caso infatti essi avranno un
user-ID reale privilegiato, che dovrà essere esplicitamente eliminato prima di porre in esecuzione
un nuovo programma (occorrerà cioè eseguire un’altra chiamata dopo la fork e prima della exec
per uniformare l’user-ID reale a quello effettivo) in caso contrario il nuovo programma potrebbe
a sua volta effettuare uno scambio e riottenere privilegi non previsti.
Lo stesso problema di propagazione dei privilegi ad eventuali processi figli si pone per l’user-
ID salvato: questa funzione deriva da un’implementazione che non ne prevede la presenza, e
quindi non è possibile usarla per correggere la situazione come nel caso precedente. Per questo
27
almeno fino alla versione 4.3+BSD.

motivo in Linux tutte le volte che si imposta un qualunque valore diverso da quello dall’user-
ID reale corrente, l’user-ID salvato viene automaticamente uniformato al valore dell’user-ID
effettivo.
Altre due funzioni, seteuid e setegid, sono un’estensione dello standard POSIX.1, ma
sono comunque supportate dalla maggior parte degli Unix; esse vengono usate per cambiare gli
identificatori del gruppo effective ed i loro prototipi sono:
#include <unistd.h>
int seteuid(uid_t uid)
Imposta l’user-ID effettivo del processo corrente a uid.
int setegid(gid_t gid)
Imposta il group-ID effettivo del processo corrente a gid.
Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento: l’unico errore è EPERM.
Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo la prima. Gli
utenti normali possono impostare l’user-ID effettivo solo al valore dell’user-ID reale o dell’user-
ID salvato, l’amministratore può specificare qualunque valore. Queste funzioni sono usate per
permettere all’amministratore di impostare solo l’user-ID effettivo, dato che l’uso normale di
setuid comporta l’impostazione di tutti gli identificatori.
Le due funzioni setresuid e setresgid sono invece un’estensione introdotta in Linux,28 e
permettono un completo controllo su tutti e tre i gruppi di identificatori (real, effective e saved),
i loro prototipi sono:
#include <unistd.h>
int setresuid(uid_t ruid, uid_t euid, uid_t suid)
Imposta l’user-ID reale, l’user-ID effettivo e l’user-ID salvato del processo corrente ai valori
specificati rispettivamente da ruid, euid e suid.
int setresgid(gid_t rgid, gid_t egid, gid_t sgid)
Imposta il group-ID reale, il group-ID effettivo ed il group-ID salvato del processo corrente
ai valori specificati rispettivamente da rgid, egid e sgid.
Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento: l’unico errore è EPERM.
Le due funzioni sono identiche, quanto detto per la prima riguardo gli user-ID si applica
alla seconda per i group-ID. I processi non privilegiati possono cambiare uno qualunque degli
user-ID solo ad un valore corrispondente o all’user-ID reale, o a quello effettivo o a quello salvato,
l’amministratore può specificare i valori che vuole; un valore di -1 per un qualunque argomento
lascia inalterato l’identificatore corrispondente.
Per queste funzioni esistono anche due controparti che permettono di leggere in blocco i vari
identificatori: getresuid e getresgid; i loro prototipi sono:
#include <unistd.h>
int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid)
Legge l’user-ID reale, l’user-ID effettivo e l’user-ID salvato del processo corrente.
int getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid)
Legge il group-ID reale, il group-ID effettivo e il group-ID salvato del processo corrente.
EFAULT se gli indirizzi delle variabili di ritorno non sono validi.
Anche queste funzioni sono un’estensione specifica di Linux, e non richiedono nessun privi-
legio. I valori sono restituiti negli argomenti, che vanno specificati come puntatori (è un altro
esempio di value result argument). Si noti che queste funzioni sono le uniche in grado di leggere
gli identificatori del gruppo saved.
28
per essere precisi a partire dal kernel 2.1.44.

Infine le funzioni setfsuid e setfsgid servono per impostare gli identificatori del gruppo
filesystem che sono usati da Linux per il controllo dell’accesso ai file. Come già accennato in
sez. 3.3.1 Linux definisce questo ulteriore gruppo di identificatori, che in circostanze normali
sono assolutamente equivalenti a quelli del gruppo effective, dato che ogni cambiamento di questi
ultimi viene immediatamente riportato su di essi.
C’è un solo caso in cui si ha necessità di introdurre una differenza fra gli identificatori dei
gruppi effective e filesystem, ed è per ovviare ad un problema di sicurezza che si presenta quando
si deve implementare un server NFS.
Il server NFS infatti deve poter cambiare l’identificatore con cui accede ai file per assumere
l’identità del singolo utente remoto, ma se questo viene fatto cambiando l’user-ID effettivo o
l’user-ID reale il server si espone alla ricezione di eventuali segnali ostili da parte dell’utente di
cui ha temporaneamente assunto l’identità. Cambiando solo l’user-ID di filesystem si ottengono
i privilegi necessari per accedere ai file, mantenendo quelli originari per quanto riguarda tutti
gli altri controlli di accesso, cos`ı che l’utente non possa inviare segnali al server NFS.
Le due funzioni usate per cambiare questi identificatori sono setfsuid e setfsgid, ovvia-
mente sono specifiche di Linux e non devono essere usate se si intendono scrivere programmi
portabili; i loro prototipi sono:
#include <sys/fsuid.h>
int setfsuid(uid_t fsuid)
Imposta l’user-ID di filesystem del processo corrente a fsuid.
int setfsgid(gid_t fsgid)
Imposta il group-ID di filesystem del processo corrente a fsgid.
EPERM.
queste funzioni hanno successo solo se il processo chiamante ha i privilegi di amministratore o,
per gli altri utenti, se il valore specificato coincide con uno dei di quelli del gruppo real, effective
o saved.
3.3.3 Le funzioni per la gestione dei gruppi associati a un processo
Le ultime funzioni che esamineremo sono quelle che permettono di operare sui gruppi supple-
mentari cui un utente può appartenere. Ogni processo può avere almeno NGROUPS_MAX gruppi
supplementari29 in aggiunta al gruppo primario; questi vengono ereditati dal processo padre e
possono essere cambiati con queste funzioni.
La funzione che permette di leggere i gruppi supplementari associati ad un processo è
getgroups; questa funzione è definita nello standard POSIX.1, ed il suo prototipo è:
#include <unistd.h>
int getgroups(int size, gid_t list[])
Legge gli identificatori dei gruppi supplementari.
La funzione restituisce il numero di gruppi letti in caso di successo e -1 in caso di fallimento, nel
qual caso errno assumerà i valori:
EFAULT list non ha un indirizzo valido.
EINVAL il valore di size è diverso da zero ma minore del numero di gruppi supplementari del
processo.
La funzione legge gli identificatori dei gruppi supplementari del processo sul vettore list
di dimensione size. Non è specificato se la funzione inserisca o meno nella lista il group-ID
29
il numero massimo di gruppi secondari può essere ottenuto con sysconf (vedi sez. 8.1.2), leggendo il parametro
_SC_NGROUPS_MAX.

effettivo del processo. Se si specifica un valore di size uguale a 0 list non viene modificato, ma
si ottiene il numero di gruppi supplementari.
Una seconda funzione, getgrouplist, può invece essere usata per ottenere tutti i gruppi a
cui appartiene un certo utente; il suo prototipo è:
#include <grp.h>
int getgrouplist(const char *user, gid_t group, gid_t *groups, int *ngroups)
Legge i gruppi supplementari.
La funzione legge fino ad un massimo di ngroups valori, restituisce 0 in caso di successo e -1 in
caso di fallimento.
La funzione legge i gruppi supplementari dell’utente specificato da user, eseguendo una
scansione del database dei gruppi (si veda sez. 8.2.3). Ritorna poi in groups la lista di quelli a
cui l’utente appartiene. Si noti che ngroups è passato come puntatore perché, qualora il valore
specificato sia troppo piccolo, la funzione ritorna -1, passando indietro il numero dei gruppi
trovati.
Per impostare i gruppi supplementari di un processo ci sono due funzioni, che possono essere
usate solo se si hanno i privilegi di amministratore. La prima delle due è setgroups, ed il suo
prototipo è:
#include <grp.h>
int setgroups(size_t size, gid_t *list)
Imposta i gruppi supplementari del processo.
La funzione restituisce 0 in caso di successo e -1 in caso di fallimento, nel qual caso errno assumerà
i valori:
EFAULT list non ha un indirizzo valido.
EPERM il processo non ha i privilegi di amministratore.
EINVAL il valore di size è maggiore del valore massimo consentito.
La funzione imposta i gruppi supplementari del processo corrente ai valori specificati nel
vettore passato con l’argomento list, di dimensioni date dall’argomento size. Il numero mas-
simo di gruppi supplementari è un parametro di sistema, che può essere ricavato con le modalità
spiegate in sez. 8.1.
Se invece si vogliono impostare i gruppi supplementari del processo a quelli di un utente
specifico, si può usare initgroups il cui prototipo è:
#include <grp.h>
int initgroups(const char *user, gid_t group)
Inizializza la lista dei gruppi supplementari.
La funzione restituisce 0 in caso di successo e -1 in caso di fallimento, nel qual caso errno assumerà
gli stessi valori di setgroups più ENOMEM quando non c’è memoria sufficiente per allocare lo spazio
per informazioni dei gruppi.
La funzione esegue la scansione del database dei gruppi (usualmente /etc/group) cercando i
gruppi di cui è membro l’utente user con cui costruisce una lista di gruppi supplementari, a cui
aggiunge anche group, infine imposta questa lista per il processo corrente usando setgroups.
Si tenga presente che sia setgroups che initgroups non sono definite nello standard POSIX.1
e che pertanto non è possibile utilizzarle quando si definisce _POSIX_SOURCE o si compila con il
flag -ansi, è pertanto meglio evitarle se si vuole scrivere codice portabile.

3.4. LA GESTIONE DELLA PRIORITÀ DEI PROCESSI 75
3.4 La gestione della priorità dei processi
In questa sezione tratteremo più approfonditamente i meccanismi con il quale lo scheduler as-
segna la CPU ai vari processi attivi. In particolare prenderemo in esame i vari meccanismi con
cui viene gestita l’assegnazione del tempo di CPU, ed illustreremo le varie funzioni di gestione.
Tratteremo infine anche le altre priorità dei processi (come quelle per l’accesso a disco) divenute
disponibili con i kernel più recenti.
3.4.1 I meccanismi di scheduling
La scelta di un meccanismo che sia in grado di distribuire in maniera efficace il tempo di CPU
per l’esecuzione dei processi è sempre una questione delicata, ed oggetto di numerose ricerche;
in generale essa dipende in maniera essenziale anche dal tipo di utilizzo che deve essere fatto del
sistema, per cui non esiste un meccanismo che sia valido per tutti gli usi.
La caratteristica specifica di un sistema multitasking come Linux è quella del cosiddetto
preemptive multitasking: questo significa che al contrario di altri sistemi (che usano invece il
cosiddetto cooperative multitasking) non sono i singoli processi, ma il kernel stesso a decidere
quando la CPU deve essere passata ad un altro processo. Come accennato in sez. 3.1.1 questa
scelta viene eseguita da una sezione apposita del kernel, lo scheduler, il cui scopo è quello di
distribuire al meglio il tempo di CPU fra i vari processi.
La cosa è resa ancora più complicata dal fatto che con le architetture multi-processore si
deve anche scegliere quale sia la CPU più opportuna da utilizzare.30 Tutto questo comunque
appartiene alle sottigliezze dell’implementazione del kernel; dal punto di vista dei programmi
che girano in user space, anche quando si hanno più processori (e dei processi che sono eseguiti
davvero in contemporanea), le politiche di scheduling riguardano semplicemente l’allocazione
della risorsa tempo di esecuzione, la cui assegnazione sarà governata dai meccanismi di scelta
delle priorità che restano gli stessi indipendentemente dal numero di processori.
Si tenga conto poi che i processi non devono solo eseguire del codice: ad esempio molto spesso
saranno impegnati in operazioni di I/O, o potranno venire bloccati da un comando dal terminale,
o sospesi per un certo periodo di tempo. In tutti questi casi la CPU diventa disponibile ed è
compito dello kernel provvedere a mettere in esecuzione un altro processo.
Tutte queste possibilità sono caratterizzate da un diverso stato del processo, in Linux un
processo può trovarsi in uno degli stati riportati in tab. 3.8; ma soltanto i processi che sono
nello stato Runnable concorrono per l’esecuzione. Questo vuol dire che, qualunque sia la sua
priorità, un processo non potrà mai essere messo in esecuzione fintanto che esso si trova in uno
qualunque degli altri stati.
Si deve quindi tenere presente che l’utilizzo della CPU è soltanto una delle risorse che sono
necessarie per l’esecuzione di un programma, e a seconda dello scopo del programma non è detto
neanche che sia la più importante (molti programmi dipendono in maniera molto più critica
dall’I/O). Per questo motivo non è affatto detto che dare ad un programma la massima priorità
di esecuzione abbia risultati significativi in termini di prestazioni.
Il meccanismo tradizionale di scheduling di Unix (che tratteremo in sez. 3.4.2) è sempre
stato basato su delle priorità dinamiche, in modo da assicurare che tutti i processi, anche i meno
importanti, possano ricevere un po’ di tempo di CPU. In sostanza quando un processo ottiene
la CPU la sua priorità viene diminuita. In questo modo alla fine, anche un processo con priorità
iniziale molto bassa, finisce per avere una priorità sufficiente per essere eseguito.
Lo standard POSIX.1b però ha introdotto il concetto di priorità assoluta, (chiamata anche
priorità statica, in contrapposizione alla normale priorità dinamica), per tenere conto dei sistemi
30
nei processori moderni la presenza di ampie cache può rendere poco efficiente trasferire l’esecuzione di un
processo da una CPU ad un’altra, per cui effettuare la migliore scelta fra le diverse CPU non è banale.

Stato STAT Descrizione
Runnable R Il processo è in esecuzione o è pronto ad essere eseguito (cioè è
in attesa che gli venga assegnata la CPU).
Sleep S Il processo è in attesa di un risposta dal sistema, ma può essere
interrotto da un segnale.
Uninterrutible
Sleep
D Il processo è in attesa di un risposta dal sistema (in genere per
I/O), e non può essere interrotto in nessuna circostanza.
Stopped T Il processo è stato fermato con un SIGSTOP, o è tracciato.
Zombie Z Il processo è terminato ma il suo stato di terminazione non è
ancora stato letto dal padre.
Killable D Un nuovo stato introdotto con il kernel 2.6.25, sostanzialmente
identico all’Uninterrutible Sleep con la sola differenza che il
processo può terminato con SIGKILL (usato per lo più per NFS).
Tabella 3.8: Elenco dei possibili stati di un processo in Linux, nella colonna STAT si è riportata la corrispondente
lettera usata dal comando ps nell’omonimo campo.
real-time,31 in cui è vitale che i processi che devono essere eseguiti in un determinato momento
non debbano aspettare la conclusione di altri che non hanno questa necessità.
Il concetto di priorità assoluta dice che quando due processi si contendono l’esecuzione, vince
sempre quello con la priorità assoluta più alta. Ovviamente questo avviene solo per i processi che
sono pronti per essere eseguiti (cioè nello stato runnable). La priorità assoluta viene in genere
indicata con un numero intero, ed un valore più alto comporta una priorità maggiore. Su questa
politica di scheduling torneremo in sez. 3.4.3.
In generale quello che succede in tutti gli Unix moderni è che ai processi normali viene sempre
data una priorità assoluta pari a zero, e la decisione di assegnazione della CPU è fatta solo con
il meccanismo tradizionale della priorità dinamica. In Linux tuttavia è possibile assegnare anche
una priorità assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di priorità
inferiore, che saranno eseguiti solo quando quest’ultimo non avrà bisogno della CPU.
3.4.2 Il meccanismo di scheduling standard
A meno che non si abbiano esigenze specifiche,32 l’unico meccanismo di scheduling con il quale
si avrà a che fare è quello tradizionale, che prevede solo priorità dinamiche. È di questo che,
di norma, ci si dovrà preoccupare nella programmazione. Come accennato in Linux i processi
ordinari hanno tutti una priorità assoluta nulla; quello che determina quale, fra tutti i processi in
attesa di esecuzione, sarà eseguito per primo, è la cosiddetta priorità dinamica,33 che è chiamata
cos`ı proprio perché varia nel corso dell’esecuzione di un processo.
Il meccanismo usato da Linux è in realtà piuttosto complesso,34 ma a grandi linee si può dire
che ad ogni processo è assegnata una time-slice, cioè un intervallo di tempo (letteralmente una
fetta) per il quale, a meno di eventi esterni, esso viene eseguito senza essere interrotto. Inoltre
la priorità dinamica viene calcolata dallo scheduler a partire da un valore iniziale che viene
31
per sistema real-time si intende un sistema in grado di eseguire operazioni in un tempo ben determinato; in
genere si tende a distinguere fra l’hard real-time in cui è necessario che i tempi di esecuzione di un programma siano
determinabili con certezza assoluta (come nel caso di meccanismi di controllo di macchine, dove uno sforamento
dei tempi avrebbe conseguenze disastrose), e soft-real-time in cui un occasionale sforamento è ritenuto accettabile.
32
per alcune delle quali sono state introdotte delle varianti specifiche.
33
quella che viene mostrata nella colonna PR del comando top.
34
e dipende strettamente dalla versione di kernel; in particolare a partire dalla serie 2.6.x lo scheduler è stato
riscritto completamente, con molte modifiche susseguitesi per migliorarne le prestazioni, per un certo periodo ed
è stata anche introdotta la possibilità di usare diversi algoritmi, selezionabili sia in fase di compilazione, che,
nelle versioni più recenti, all’avvio (addirittura è stato ideato un sistema modulare che permette di cambiare lo
scheduler a sistema attivo).

diminuito tutte le volte che un processo è in stato Runnable ma non viene posto in esecuzione.35
Lo scheduler infatti mette sempre in esecuzione, fra tutti i processi in stato Runnable, quello
che ha il valore di priorità dinamica più basso.36 Il fatto che questo valore venga diminuito
quando un processo non viene posto in esecuzione pur essendo pronto, significa che la priorità
dei processi che non ottengono l’uso del processore viene progressivamente incrementata, cos`ı
che anche questi alla fine hanno la possibilità di essere eseguiti.
Sia la dimensione della time-slice che il valore di partenza della priorità dinamica sono
determinate dalla cosiddetta nice (o niceness) del processo.37 L’origine del nome di questo
parametro sta nel fatto che generalmente questo viene usato per diminuire la priorità di un
processo, come misura di cortesia nei confronti degli altri. I processi infatti vengono creati dal
sistema con un valore di nice nullo e nessuno è privilegiato rispetto agli altri; specificando un
valore positivo si avrà una time-slice più breve ed un valore di priorità dinamica iniziale più
alto, mentre un valore negativo darà una time-slice più lunga ed un valore di priorità dinamica
iniziale più basso.
Esistono diverse funzioni che consentono di modificare la niceness di un processo; la più
semplice è funzione nice, che opera sul processo corrente, il suo prototipo è:
#include <unistd.h>
int nice(int inc)
Aumenta il valore di nice per il processo corrente.
La funzione ritorna zero o il nuovo valore di nice in caso di successo e -1 in caso di errore, nel
qual caso errno può assumere i valori:
EPERM non si ha il permesso di specificare un valore di inc negativo.
L’argomento inc indica l’incremento da effettuare rispetto al valore di nice corrente: que-
st’ultimo può assumere valori compresi fra PRIO_MIN e PRIO_MAX; nel caso di Linux sono fra
−20 e 19,38 ma per inc si può specificare un valore qualunque, positivo o negativo, ed il sistema
provvederà a troncare il risultato nell’intervallo consentito. Valori positivi comportano maggiore
cortesia e cioè una diminuzione della priorità, valori negativi comportano invece un aumento
della priorità. Con i kernel precedenti il 2.6.12 solo l’amministratore39 può specificare valori
negativi di inc che permettono di aumentare la priorità di un processo, a partire da questa
versione è consentito anche agli utenti normali alzare (entro certi limiti, che vedremo più avanti)
la priorità dei propri processi.
Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore di nice del
processo; tuttavia la system call di Linux non segue questa convenzione e restituisce sempre 0 in
caso di successo e −1 in caso di errore; questo perché −1 è un valore di nice legittimo e questo
comporta una confusione con una eventuale condizione di errore. La system call originaria inoltre
non consente, se non dotati di adeguati privilegi, di diminuire un valore di nice precedentemente
innalzato.
35
in realtà il calcolo della priorità dinamica e la conseguente scelta di quale processo mettere in esecuzione
avviene con un algoritmo molto più complicato, che tiene conto anche della interattività del processo, utilizzando
diversi fattori, questa è una brutale semplificazione per rendere l’idea del funzionamento, per una trattazione
più dettagliata, anche se non aggiornatissima, dei meccanismi di funzionamento dello scheduler si legga il quarto
capitolo di [6].
36
con le priorità dinamiche il significato del valore numerico ad esse associato è infatti invertito, un valore più
basso significa una priorità maggiore.
37
questa è una delle tante proprietà che ciascun processo si porta dietro, essa viene ereditata dai processi figli e
mantenuta attraverso una exec; fino alla serie 2.4 essa era mantenuta nell’omonimo campo nice della task_struct,
con la riscrittura dello scheduler eseguita nel 2.6 viene mantenuta nel campo static_prio come per le priorità
statiche.
38
in realtà l’intervallo varia a seconda delle versioni di kernel, ed è questo a partire dal kernel 1.3.43, anche se
oggi si può avere anche l’intervallo fra −20 e 20.
39
o un processo con la capability CAP_SYS_NICE, vedi sez. 5.4.4.

Fino alle glibc 2.2.4 la funzione di libreria riportava direttamente il risultato dalla system
call, violando lo standard, per cui per ottenere il nuovo valore occorreva una successiva chiamata
alla funzione getpriority. A partire dalla glibc 2.2.4 nice è stata reimplementata e non viene
più chiamata la omonima system call, con questa versione viene restituito come valore di ritorno
il valore di nice, come richiesto dallo standard.40 In questo caso l’unico modo per rilevare in
maniera affidabile una condizione di errore è quello di azzerare errno prima della chiamata della
funzione e verificarne il valore quando nice restituisce −1.
Per leggere il valore di nice di un processo occorre usare la funzione getpriority, derivata
da BSD; il suo prototipo è:
int getpriority(int which, int who)
Restituisce il valore di nice per l’insieme dei processi specificati.
La funzione ritorna la priorità in caso di successo e -1 in caso di errore, nel qual caso errno può
assumere i valori:
ESRCH non c’è nessun processo che corrisponda ai valori di which e who.
EINVAL il valore di which non è valido.
nelle vecchie versioni può essere necessario includere anche <sys/time.h>, questo non è più
necessario con versioni recenti delle librerie, ma è comunque utile per portabilità.
La funzione permette, a seconda del valore di which, di leggere la priorità di un processo, di
un gruppo di processi (vedi sez. 10.1.2) o di un utente, specificando un corrispondente valore per
who secondo la legenda di tab. 3.9; un valore nullo di quest’ultimo indica il processo, il gruppo
di processi o l’utente correnti.
which who Significato
PRIO_PROCESS pid_t processo
PRIO_PRGR pid_t process group
PRIO_USER uid_t utente
Tabella 3.9: Legenda del valore dell’argomento which e del tipo dell’argomento who delle funzioni getpriority
e setpriority per le tre possibili scelte.
La funzione restituisce la priorità più alta (cioè il valore più basso) fra quelle dei processi
specificati; di nuovo, dato che −1 è un valore possibile, per poter rilevare una condizione di errore
è necessario cancellare sempre errno prima della chiamata alla funzione per verificare che essa
resti uguale a zero.
Analoga a getpriority è la funzione setpriority che permette di impostare la priorità di
uno o più processi; il suo prototipo è:
int setpriority(int which, int who, int prio)
Imposta la priorità per l’insieme dei processi specificati.
La funzione ritorna 0 in caso di successo e -1 in caso di errore, nel qual caso errno può assumere
i valori:
ESRCH non c’è nessun processo che corrisponda ai valori di which e who.
EINVAL il valore di which non è valido.
EACCES si è richiesto un aumento di priorità senza avere sufficienti privilegi.
EPERM un processo senza i privilegi di amministratore ha cercato di modificare la priorità di
un processo di un altro utente.
La funzione imposta la priorità al valore specificato da prio per tutti i processi indicati dagli
argomenti which e who. In questo caso come valore di prio deve essere specificato il valore di
40
questo viene fatto chiamando al suo interno setpriority, che tratteremo a breve.

nice da assegnare, e non un incremento (positivo o negativo) come nel caso di nice. La funzione
restituisce il valore di nice assegnato in caso di successo e −1 in caso di errore, e come per
nice anche in questo caso per rilevare un errore occorre sempre porre a zero errno prima della
chiamata della funzione, essendo −1 un valore di nice valido.
Si tenga presente che solo l’amministratore41 ha la possibilità di modificare arbitrariamente
le priorità di qualunque processo. Un utente normale infatti può modificare solo la priorità dei
suoi processi ed in genere soltanto diminuirla. Fino alla versione di kernel 2.6.12 Linux ha seguito
le specifiche dello standard SUSv3, e come per tutti i sistemi derivati da SysV veniva richiesto
che l’user-ID reale o quello effettivo del processo chiamante corrispondessero all’user-ID reale (e
solo a quello) del processo di cui si intendeva cambiare la priorità. A partire dalla versione 2.6.12
è stata adottata la semantica in uso presso i sistemi derivati da BSD (SunOS, Ultrix, *BSD), in
cui la corrispondenza può essere anche con l’user-ID effettivo.
Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti ordinari poter
aumentare la priorità dei propri processi specificando un valore di prio negativo. Questa opera-
zione non è possibile però in maniera indiscriminata, ed in particolare può essere effettuata solo
nell’intervallo consentito dal valore del limite RLIMIT_NICE (torneremo su questo in sez. 8.3.2).
3.4.3 Il meccanismo di scheduling real-time
Come spiegato in sez. 3.4.1 lo standard POSIX.1b ha introdotto le priorità assolute per permet-
tere la gestione di processi real-time. In realtà nel caso di Linux non si tratta di un vero hard
real-time, in quanto in presenza di eventuali interrupt il kernel interrompe l’esecuzione di un
processo qualsiasi sia la sua priorità,42 mentre con l’incorrere in un page fault si possono avere
ritardi non previsti. Se l’ultimo problema può essere aggirato attraverso l’uso delle funzioni di
controllo della memoria virtuale (vedi sez. 2.2.4), il primo non è superabile e può comportare
ritardi non prevedibili riguardo ai tempi di esecuzione di qualunque processo.
Nonostante questo, ed in particolare con una serie di miglioramenti che sono stati introdotti
nello sviluppo del kernel,43 si può arrivare ad una ottima approssimazione di sistema real-time
usando le priorità assolute; occorre farlo però con molta attenzione: se si dà ad un processo una
priorità assoluta e questo finisce in un loop infinito, nessun altro processo potrà essere eseguito,
ed esso sarà mantenuto in esecuzione permanentemente assorbendo tutta la CPU e senza nessuna
possibilità di riottenere l’accesso al sistema. Per questo motivo è sempre opportuno, quando si
lavora con processi che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
massima priorità assoluta, in modo da poter essere comunque in grado di rientrare nel sistema.
Quando c’è un processo con priorità assoluta lo scheduler lo metterà in esecuzione prima di
ogni processo normale. In caso di più processi sarà eseguito per primo quello con priorità assoluta
più alta. Quando ci sono più processi con la stessa priorità assoluta questi vengono tenuti in una
coda e tocca al kernel decidere quale deve essere eseguito. Il meccanismo con cui vengono gestiti
questi processi dipende dalla politica di scheduling che si è scelta; lo standard ne prevede due:
FIFO First In First Out. Il processo viene eseguito fintanto che non cede volontariamente la
CPU (con sched_yield), si blocca, finisce o viene interrotto da un processo a priorità
più alta. Se il processo viene interrotto da uno a priorità più alta esso resterà in cima alla
41
o più precisamente un processo con la capability CAP_SYS_NICE, vedi sez. 5.4.4.
42
questo a meno che non si siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile ottenere
un sistema effettivamente hard real-time. In tal caso infatti gli interrupt vengono intercettati dall’interfaccia real-
time (o nel caso di Adeos gestiti dalle code del nano-kernel), in modo da poterli controllare direttamente qualora
ci sia la necessità di avere un processo con priorità più elevata di un interrupt handler.
43
in particolare a partire dalla versione 2.6.18 sono stati inserite nel kernel una serie di modifiche che consentono
di avvicinarsi sempre di più ad un vero e proprio sistema real-time estendendo il concetto di preemption alle
operazioni dello stesso kernel; esistono vari livelli a cui questo può essere fatto, ottenibili attivando in fase di
compilazione una fra le opzioni CONFIG_PREEMPT_NONE, CONFIG_PREEMPT_VOLUNTARY e CONFIG_PREEMPT_DESKTOP.

lista e sarà il primo ad essere eseguito quando i processi a priorità più alta diverranno
inattivi. Se invece lo si blocca volontariamente sarà posto in coda alla lista (ed altri
processi con la stessa priorità potranno essere eseguiti).
RR Round Robin. Il comportamento è del tutto analogo a quello precedente, con la sola
differenza che ciascun processo viene eseguito al massimo per un certo periodo di tempo
(la cosiddetta time-slice) dopo di che viene automaticamente posto in fondo alla coda
dei processi con la stessa priorità. In questo modo si ha comunque una esecuzione a turno
di tutti i processi, da cui il nome della politica. Solo i processi con la stessa priorità ed
in stato Runnable entrano nel girotondo.
Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare le politiche di
scheduling, passando da real-time a ordinarie o viceversa, che di specificare, in caso di politiche
real-time, la eventuale priorità statica; la funzione è sched_setscheduler ed il suo prototipo è:
#include <sched.h>
int sched_setscheduler(pid_t pid, int policy, const struct sched_param *p)
Imposta priorità e politica di scheduling.
La funzione ritorna 0 in caso di successo e −1 in caso di errore, nel qual caso errno può assumere
i valori:
ESRCH il processo pid non esiste.
EINVAL il valore di policy non esiste o il relativo valore di p non è valido.
EPERM il processo non ha i privilegi per attivare la politica richiesta.
La funzione esegue l’impostazione per il processo specificato dall’argomento pid; un valore
nullo di questo argomento esegue l’impostazione per il processo corrente. La politica di scheduling
è specificata dall’argomento policy i cui possibili valori sono riportati in tab. 3.10; la parte alta
della tabella indica le politiche real-time, quella bassa le politiche ordinarie. Un valore negativo
per policy mantiene la politica di scheduling corrente.
Policy Significato
SCHED_FIFO Scheduling real-time con politica FIFO.
SCHED_RR Scheduling real-time con politica Round Robin.
SCHED_OTHER Scheduling ordinario.
SCHED_BATCH Scheduling ordinario con l’assunzione ulteriore di lavoro CPU intensive.44
SCHED_IDLE Scheduling di priorità estremamente bassa.45
Tabella 3.10: Valori dell’argomento policy per la funzione sched_setscheduler.
Con le versioni più recenti del kernel sono state introdotte anche delle varianti sulla politica
di scheduling tradizionale per alcuni carichi di lavoro specifici, queste due nuove politiche sono
specifiche di Linux e non devono essere usate se si vogliono scrivere programmi portabili.
La politica SCHED_BATCH è una variante della politica ordinaria con la sola differenza che
i processi ad essa soggetti non ottengono, nel calcolo delle priorità dinamiche fatto dallo sche-
duler, il cosiddetto bonus di interattività che mira a favorire i processi che si svegliano dallo
stato di Sleep.46 La si usa pertanto, come indica il nome, per processi che usano molta CPU
(come programmi di calcolo) che in questo modo sono leggermente sfavoriti rispetto ai processi
interattivi che devono rispondere a dei dati in ingresso, pur non perdendo il loro valore di nice.
La politica SCHED_IDLE invece è una politica dedicata ai processi che si desidera siano eseguiti
con la più bassa priorità possibile, ancora più bassa di un processo con il minimo valore di nice.
44
introdotto con il kernel 2.6.16.
45
46
cosa che accade con grande frequenza per i processi interattivi, dato che essi sono per la maggior parte del
tempo in attesa di dati in ingresso da parte dell’utente.

In sostanza la si può utilizzare per processi che devono essere eseguiti se non c’è niente altro
da fare. Va comunque sottolineato che anche un processo SCHED_IDLE avrà comunque una sua
possibilità di utilizzo della CPU, sia pure in percentuale molto bassa.
Qualora si sia richiesta una politica real-time il valore della priorità statica viene impostato
attraverso la struttura sched_param, riportata in fig. 3.5, il cui solo campo attualmente definito è
sched_priority. Il campo deve contenere il valore della priorità statica da assegnare al processo;
lo standard prevede che questo debba essere assegnato all’interno di un intervallo fra un massimo
ed un minimo che nel caso di Linux sono rispettivamente 1 e 99.
struct sched_param {
int sched_priority;
};
Figura 3.5: La struttura sched_param.
I processi con politica di scheduling ordinaria devono sempre specificare un valore nullo di
sched_priority altrimenti si avrà un errore EINVAL, questo valore infatti non ha niente a che
vedere con la priorità dinamica determinata dal valore di nice, che deve essere impostato con le
funzioni viste in precedenza.
Lo standard POSIX.1b prevede comunque che i due valori della massima e minima priorità
statica possano essere ottenuti, per ciascuna delle politiche di scheduling real-time, tramite le
due funzioni sched_get_priority_max e sched_get_priority_min, i cui prototipi sono:
#include <sched.h>
int sched_get_priority_max(int policy)
Legge il valore massimo della priorità statica per la politica di scheduling policy.
int sched_get_priority_min(int policy)
Legge il valore minimo della priorità statica per la politica di scheduling policy.
La funzioni ritornano il valore della priorità in caso di successo e −1 in caso di errore, nel qual
caso errno può assumere i valori:
EINVAL il valore di policy non è valido.
Si tenga presente che quando si imposta una politica di scheduling real-time per un processo
o se ne cambia la priorità statica questo viene messo in cima alla lista dei processi con la stessa
priorità; questo comporta che verrà eseguito subito, interrompendo eventuali altri processi con
la stessa priorità in quel momento in esecuzione.
Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed esegue sempre il
primo della lista, mentre un nuovo processo che torna in stato Runnable viene sempre inserito
in coda alla lista. Se la politica scelta è SCHED_FIFO quando il processo viene eseguito viene
automaticamente rimesso in coda alla lista, e la sua esecuzione continua fintanto che non viene
bloccato da una richiesta di I/O, o non rilascia volontariamente la CPU (in tal caso, tornando
nello stato Runnable sarà reinserito in coda alla lista); l’esecuzione viene ripresa subito solo
nel caso che esso sia stato interrotto da un processo a priorità più alta.
Solo un processo con i privilegi di amministratore47 può impostare senza restrizioni priorità
assolute diverse da zero o politiche SCHED_FIFO e SCHED_RR. Un utente normale può modificare
solo le priorità di processi che gli appartengono; è cioè richiesto che l’user-ID effettivo del processo
chiamante corrisponda all’user-ID reale o effettivo del processo indicato con pid.
Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche real-time o modi-
ficare la eventuale priorità statica di un loro processo. A partire da questa versione è divenuto
possibile anche per gli utenti normali usare politiche real-time fintanto che la priorità assoluta
47
più precisamente con la capacità CAP_SYS_NICE, vedi sez. 5.4.4.

che si vuole impostare è inferiore al limite RLIMIT_RTPRIO (vedi sez. 8.3.2) ad essi assegnato.
Unica eccezione a questa possibilità sono i processi SCHED_IDLE, che non possono cambiare po-
litica di scheduling indipendentemente dal valore di RLIMIT_RTPRIO. Inoltre, in caso di processo
già sottoposto ad una politica real-time, un utente può sempre, indipendentemente dal valore di
RLIMIT_RTPRIO, diminuirne la priorità o portarlo ad una politica ordinaria.
Se si intende operare solo sulla priorità statica di un processo si possono usare le due funzioni
sched_setparam e sched_getparam che consentono rispettivamente di impostarne e leggerne il
valore, i loro prototipi sono:
#include <sched.h>
int sched_setparam(pid_t pid, const struct sched_param *param)
Imposta la priorità statica del processo pid.
int sched_getparam(pid_t pid, struct sched_param *param)
Legge la priorità statica del processo pid.
Entrambe le funzioni ritornano 0 in caso di successo e −1 in caso di errore, nel qual caso errno
può assumere i valori:
EINVAL il valore di param non ha senso per la politica usata dal processo.
EPERM non si hanno privilegi sufficienti per eseguire l’operazione.
L’uso di sched_setparam, compresi i controlli di accesso che vi si applicano, è del tutto
equivalente a quello di sched_setscheduler con argomento policy uguale a -1. Come per
sched_setscheduler specificando 0 come valore dell’argomento pid si opera sul processo cor-
rente. Benché la funzione sia utilizzabile anche con processi sottoposti a politica ordinaria essa
ha senso soltanto per quelli real-time, dato che per i primi la priorità statica può essere sol-
tanto nulla. La disponibilità di entrambe le funzioni può essere verificata controllando la macro
_POSIX_PRIORITY_SCHEDULING che è definita nell’header sched.h.
Se invece si vuole sapere quale è politica di scheduling di un processo si può usare la funzione
sched_getscheduler, il cui prototipo è:
#include <sched.h>
int sched_getscheduler(pid_t pid)
Legge la politica di scheduling per il processo pid.
La funzione ritorna la politica di scheduling in caso di successo e −1 in caso di errore, nel qual
caso errno può assumere i valori:
EPERM non si hanno privilegi sufficienti per eseguire l’operazione.
La funzione restituisce il valore, secondo quanto elencato in tab. 3.10, della politica di sche-
duling per il processo specificato; se l’argomento pid è nullo viene restituito il valore relativo al
processo chiamante.
L’ultima funzione che permette di leggere le informazioni relative ai processi real-time è
sched_rr_get_interval, che permette di ottenere la lunghezza della time-slice usata dalla
politica round robin; il suo prototipo è:
#include <sched.h>
int sched_rr_get_interval(pid_t pid, struct timespec *tp)
Legge in tp la durata della time-slice per il processo pid.
i valori:
ENOSYS la system call non è stata implementata.

La funzione restituisce il valore dell’intervallo di tempo usato per la politica round robin in
una struttura timespec, (la cui definizione si può trovare in fig. 5.7). In realtà dato che in Linux
questo intervallo di tempo è prefissato e non modificabile, questa funzione ritorna sempre un
valore di 150 millisecondi, e non importa specificare il PID di un processo reale.
Come accennato ogni processo può rilasciare volontariamente la CPU in modo da consentire
agli altri processi di essere eseguiti; la funzione che consente di fare tutto ciò è sched_yield, il
cui prototipo è:
#include <sched.h>
int sched_yield(void)
Rilascia volontariamente l’esecuzione.
La funzione ritorna 0 in caso di successo e -1 in caso di errore, nel qual caso errno viene impostata
opportunamente.
Questa funzione ha un utilizzo effettivo soltanto quando si usa lo scheduling real-time, e serve
a far s`ı che il processo corrente rilasci la CPU, in modo da essere rimesso in coda alla lista dei
processi con la stessa priorità per permettere ad un altro di essere eseguito; se però il processo
è l’unico ad essere presente sulla coda l’esecuzione non sarà interrotta. In genere usano questa
funzione i processi con politica SCHED_FIFO, per permettere l’esecuzione degli altri processi con
pari priorità quando la sezione più urgente è finita.
La funzione può essere utilizzata anche con processi che usano lo scheduling ordinario, ma in
questo caso il comportamento non è ben definito, e dipende dall’implementazione. Fino al kernel
2.6.23 questo comportava che i processi venissero messi in fondo alla coda di quelli attivi, con la
possibilità di essere rimessi in esecuzione entro breve tempo, con l’introduzione del Completely
Fair Scheduler questo comportamento è cambiato ed un processo che chiama la funzione viene
inserito nella lista dei processi inattivo, con un tempo molto maggiore.48
3.4.4 Il controllo dello scheduler per i sistemi multiprocessore
Infine con il supporto dei sistemi multiprocessore sono state introdotte delle funzioni che permet-
tono di controllare in maniera più dettagliata la scelta di quale processore utilizzare per eseguire
un certo programma. Uno dei problemi che si pongono nei sistemi multiprocessore è infatti quello
del cosiddetto effetto ping-pong. Può accadere cioè che lo scheduler, quando riavvia un processo
precedentemente interrotto scegliendo il primo processore disponibile, lo faccia eseguire da un
processore diverso rispetto a quello su cui era stato eseguito in precedenza. Se il processo passa
da un processore all’altro in questo modo (cosa che avveniva abbastanza di frequente con i kernel
della seria 2.4.x) si ha l’effetto ping-pong.
Questo tipo di comportamento può generare dei seri problemi di prestazioni; infatti tutti i
processori moderni utilizzano una memoria interna (la cache) contenente i dati più usati, che
permette di evitare di eseguire un accesso (molto più lento) alla memoria principale sulla scheda
madre. Chiaramente un processo sarà favorito se i suoi dati sono nella cache del processore, ma è
ovvio che questo può essere vero solo per un processore alla volta, perché in presenza di più copie
degli stessi dati su più processori, non si potrebbe determinare quale di questi ha la versione dei
dati aggiornata rispetto alla memoria principale.
Questo comporta che quando un processore inserisce un dato nella sua cache, tutti gli altri
processori che hanno lo stesso dato devono invalidarlo, e questa operazione è molto costosa in
termini di prestazioni. Il problema diventa serio quando si verifica l’effetto ping-pong, in tal
caso infatti un processo rimbalza continuamente da un processore all’altro e si ha una continua
invalidazione della cache, che non diventa mai disponibile.
48
è comunque possibile ripristinare un comportamento analogo al precedente scrivendo il valore 1 nel file
/proc/sys/kernel/sched_compat_yield.

Per ovviare a questo tipo di problemi è nato il concetto di affinità di processore (o CPU
affinity); la possibilità cioè di far s`ı che un processo possa essere assegnato per l’esecuzione
sempre allo stesso processore. Lo scheduler dei kernel della serie 2.4.x aveva una scarsa CPU
affinity, e l’effetto ping-pong era comune; con il nuovo scheduler dei kernel della 2.6.x questo
problema è stato risolto ed esso cerca di mantenere il più possibile ciascun processo sullo stesso
processore.
In certi casi però resta l’esigenza di poter essere sicuri che un processo sia sempre eseguito
dallo stesso processore,49 e per poter risolvere questo tipo di problematiche nei nuovi kernel50 è
stata introdotta l’opportuna infrastruttura ed una nuova system call che permette di impostare
su quali processori far eseguire un determinato processo attraverso una maschera di affinità. La
corrispondente funzione di libreria è sched_setaffinity ed il suo prototipo è:
#include <sched.h>
int sched_setaffinity (pid_t pid, unsigned int cpusetsize, const cpu_set_t
*cpuset)
Imposta la maschera di affinità del processo pid.
i valori:
EINVAL il valore di cpuset contiene riferimenti a processori non esistenti nel sistema.
EPERM il processo non ha i privilegi sufficienti per eseguire l’operazione.
ed inoltre anche EFAULT.
Questa funzione e la corrispondente sched_setaffinity hanno una storia abbastanza com-
plessa, la system call prevede l’uso di due ulteriori argomenti di tipo unsigned int len e
unsigned long *mask, che corrispondono al fatto che la implementazione effettiva usa una
semplice maschera binaria. Quando le funzioni vennero incluse nelle glibc assunsero invece il
prototipo appena mostrato. A complicare la cosa si aggiunge il fatto che nella versione 2.3.3
delle glibc l’argomento cpusetsize è stato eliminato, per poi essere ripristinato nella versione
2.3.4.51
La funzione imposta, con l’uso del valore contenuto all’indirizzo cpuset, l’insieme dei pro-
cessori sui quali deve essere eseguito il processo identificato tramite il valore passato in pid.
Come in precedenza il valore nullo di pid indica il processo corrente. Per poter utilizzare questa
funzione sono richiesti i privilegi di amministratore (è necessaria la capacità CAP_SYS_NICE) al-
trimenti essa fallirà con un errore di EPERM. Una volta impostata una maschera di affinità, questa
viene ereditata attraverso una fork, in questo modo diventa possibile legare automaticamente
un gruppo di processi ad un singolo processore.
Nell’uso comune, almeno con i kernel della serie 2.6.x, l’uso di questa funzione non è neces-
sario, in quanto è lo scheduler stesso che provvede a mantenere al meglio l’affinità di processore.
Esistono però esigenze particolari, ad esempio quando un processo (o un gruppo di processi) è
utilizzato per un compito importante (ad esempio per applicazioni real-time o la cui risposta è
critica) e si vuole la massima velocità, con questa interfaccia diventa possibile selezionare gruppi
di processori utilizzabili in maniera esclusiva. Lo stesso dicasi quando l’accesso a certe risorse
(memoria o periferiche) può avere un costo diverso a seconda del processore, come avviene nelle
architetture NUMA (Non-Uniform Memory Access).
49
quella che viene detta hard CPU affinity, in contrasto con quella fornita dallo scheduler, detta soft CPU
affinity, che di norma indica solo una preferenza, non un requisito assoluto.
50
le due system call per la gestione della CPU affinity sono state introdotte nel kernel 2.5.8, e le funzioni di
libreria nelle glibc 2.3.
51
pertanto se la vostra pagina di manuale non è aggiornata, o usate quella particolare versione delle glibc,
potrete trovare indicazioni diverse, il prototipo illustrato è quello riportato nella versione corrente (maggio 2008)
delle pagine di manuale e corrispondente alla definizione presente in sched.h.

Infine se un gruppo di processi accede alle stesse risorse condivise (ad esempio una applica-
zione con più thread) può avere senso usare lo stesso processore in modo da sfruttare meglio l’uso
della sua cache; questo ovviamente riduce i benefici di un sistema multiprocessore nell’esecuzio-
ne contemporanea dei thread, ma in certi casi (quando i thread sono inerentemente serializzati
nell’accesso ad una risorsa) possono esserci sufficienti vantaggi nell’evitare la perdita della cache
da rendere conveniente l’uso dell’affinità di processore.
Per facilitare l’uso dell’argomento cpuset le glibc hanno introdotto un apposito dato di
tipo, cpu_set_t,52 che permette di identificare un insieme di processori. Il dato è una maschera
binaria: in generale è un intero a 32 bit in cui ogni bit corrisponde ad un processore, ma dato
che per architetture particolari il numero di bit di un intero può non essere sufficiente, è stata
creata questa che è una interfaccia generica che permette di usare a basso livello un tipo di dato
qualunque rendendosi indipendenti dal numero di bit e dalla loro disposizione.
Questa interfaccia, oltre alla definizione del tipo di dato apposito, prevede anche una serie di
macro di preprocessore per la manipolazione dello stesso, che consentono di svuotare un insieme,
aggiungere o togliere un processore da esso o verificare se vi è già presente:
#include <sched.h>
void CPU_ZERO(cpu_set_t *set)
Inizializza l’insieme (vuoto).
void CPU_SET(int cpu, cpu_set_t *set)
Inserisce il processore cpu nell’insieme.
void CPU_CLR(int cpu, cpu_set_t *set)
Rimuove il processore cpu nell’insieme.
int CPU_ISSET(int cpu, cpu_set_t *set)
Controlla se il processore cpu è nell’insieme.
Oltre a queste macro, simili alle analoghe usate per gli insiemi di file descriptor (vedi
sez. 12.2.2) è definita la costante CPU_SETSIZE che indica il numero massimo di processori che
possono far parte dell’insieme, e che costituisce un limite massimo al valore dell’argomento cpu.
In generale la maschera di affinità è preimpostata in modo che un processo possa essere
eseguito su qualunque processore, se può comunque leggere il valore per un processo specifico
usando la funzione sched_getaffinity, il suo prototipo è:
#include <sched.h>
int sched_getaffinity (pid_t pid, unsigned int cpusetsize, const cpu_set_t
*cpuset)
Legge la maschera di affinità del processo pid.
i valori:
EFAULT il valore di cpuset non è un indirizzo valido.
La funzione restituirà all’indirizzo specificato da cpuset il valore della maschera di affinità
del processo, cos`ı da poterla riutilizzare per una successiva reimpostazione. In questo caso non
sono necessari privilegi particolari.
È chiaro che queste funzioni per la gestione dell’affinità hanno significato soltanto su un
sistema multiprocessore, esse possono comunque essere utilizzate anche in un sistema con un
processore singolo, nel qual caso però non avranno alcun risultato effettivo.
3.4.5 Le priorità per le operazioni di I/O
A lungo l’unica priorità usata per i processi è stata quella relativa all’assegnazione dell’uso del
processore. Ma il processore non è l’unica risorsa che i processi devono contendersi, un’altra,
52
questa è una estensione specifica delle glibc, da attivare definendo la macro _GNU_SOURCE, non esiste infatti
una standardizzazione per questo tipo di interfaccia e POSIX al momento non prevede nulla al riguardo.

altrettanto importante per le prestazioni, è quella dell’accesso a disco. Per questo motivo sono
stati introdotti diversi I/O scheduler in grado di distribuire in maniera opportuna questa risorsa
ai vari processi. Fino al kernel 2.6.17 era possibile soltanto differenziare le politiche generali
di gestione, scegliendo di usare un diverso I/O scheduler; a partire da questa versione, con
l’introduzione dello scheduler CFQ (Completely Fair Queuing) è divenuto possibile, qualora si
usi questo scheduler, impostare anche delle diverse priorità di accesso per i singoli processi.53
La scelta dello scheduler di I/O si può fare in maniera generica a livello di avvio del kernel
assegnando il nome dello stesso al parametro elevator, mentre se ne può indicare uno per
l’accesso al singolo disco scrivendo nel file /sys/block/dev /queue/scheduler (dove dev è il
nome del dispositivo associato al disco); gli scheduler disponibili sono mostrati dal contenuto
dello stesso file che riporta fra parentesi quadre quello attivo, il default in tutti i kernel recenti
è proprio il cfq,54 che supporta le priorità. Per i dettagli sulle caratteristiche specifiche degli
altri scheduler, la cui discussione attiene a problematiche di ambito sistemistico, si consulti la
documentazione nella directory Documentation/block/ dei sorgenti del kernel.
Una volta che si sia impostato lo scheduler CFQ ci sono due specifiche system call, specifiche
di Linux, che consentono di leggere ed impostare le priorità di I/O.55 Dato che non esiste una
interfaccia diretta nelle glibc per queste due funzioni occorrerà invocarle tramite la funzione
syscall (come illustrato in sez. 1.1.3). Le due funzioni sono ioprio_get ed ioprio_set; i
rispettivi prototipi sono:
#include <linux/ioprio.h>
int ioprio_get(int which, int who)
int ioprio_set(int which, int who, int ioprio)
Rileva o imposta la priorità di I/O di un processo.
Le funzioni ritornano rispettivamente un intero positivo (indicante la priorità) o 0 in caso di
successo e −1 in caso di errore, nel qual caso errno può assumere i valori:
ESRCH non esiste il processo indicato.
EINVAL i valori di which e who non sono validi.
EPERM non si hanno i privilegi per eseguire l’impostazione (solo per ioprio_set).
Le funzioni leggono o impostano la priorità di I/O sulla base dell’indicazione dei due ar-
gomenti which e who che hanno lo stesso significato già visto per gli omonimi argomenti di
getpriority e setpriority. Anche in questo caso si deve specificare il valore di which tramite
le opportune costanti riportate in tab. 3.11 che consentono di indicare un singolo processo, i
processi di un process group (tratteremo questo argomento in sez. 10.1.2) o tutti o processi di
un utente.
which who Significato
IPRIO_WHO_PROCESS pid_t processo
IPRIO_WHO_PRGR pid_t process group
IPRIO_WHO_USER uid_t utente
Tabella 3.11: Legenda del valore dell’argomento which e del tipo dell’argomento who delle funzioni ioprio_get
e ioprio_set per le tre possibili scelte.
In caso di successo ioprio_get restituisce un intero positivo che esprime il valore della priori-
tà di I/O, questo valore è una maschera binaria composta da due parti, una che esprime la classe
di scheduling di I/O del processo, l’altra che esprime, quando la classe di scheduling lo prevede,
la priorità del processo all’interno della classe stessa. Questo stesso formato viene utilizzato per
indicare il valore della priorità da impostare con l’argomento ioprio di ioprio_set.
53
al momento (kernel 2.6.31), le priorità di I/O sono disponibili soltanto per questo scheduler.
54
nome con cui si indica appunto lo scheduler Completely Fair Queuing.
55
se usate in corrispondenza ad uno scheduler diverso il loro utilizzo non avrà alcun effetto.

Per la gestione dei valori che esprimono le priorità di I/O sono state definite delle opportune
macro di preprocessore, riportate in tab. 3.12. I valori delle priorità si ottengono o si impostano
usando queste macro. Le prime due si usano con il valore restituito da ioprio_get e per ottenere
rispettivamente la classe di scheduling56 e l’eventuale valore della priorità. La terza macro viene
invece usata per creare un valore di priorità da usare come argomento di ioprio_set per eseguire
una impostazione.
Macro Significato
IOPRIO_PRIO_CLASS(value ) dato il valore di una priorità come restituito da
ioprio_get estrae il valore della classe.
IOPRIO_PRIO_DATA(value ) dato il valore di una priorità come restituito da
ioprio_get estrae il valore della priorità.
IOPRIO_PRIO_VALUE(class,prio ) dato un valore di priorità ed una classe ottiene il valore
numerico da passare a ioprio_set.
Tabella 3.12: Le macro per la gestione dei valori numerici .
Le classi di scheduling previste dallo scheduler CFQ sono tre, e ricalcano tre diverse modalità
di distribuzione delle risorse analoghe a quelle già adottate anche nel funzionamento dello sche-
duler del processore. Ciascuna di esse è identificata tramite una opportuna costante, secondo
quanto riportato in tab. 3.13.
La classe di priorità più bassa è IOPRIO_CLASS_IDLE; i processi in questa classe riescono ad
accedere a disco soltanto quando nessun altro processo richiede l’accesso. Occorre pertanto usarla
con molta attenzione, perché un processo in questa classe può venire completamente bloccato
quando ci sono altri processi in una qualunque delle altre due classi che stanno accedendo al
disco. Quando si usa questa classe non ha senso indicare un valore di priorità, dato che in questo
caso non esiste nessuna gerarchia e la priorità è identica, la minima possibile, per tutti i processi.
Classe Significato
IOPRIO_CLASS_RT Scheduling di I/O real time.
IOPRIO_CLASS_BE Scheduling di I/O ordinario.
IOPRIO_CLASS_IDLE Scheduling di I/O di priorità minima.
Tabella 3.13: Costanti che identificano le classi di scheduling di I/O.
La seconda classe di priorità di I/O è IOPRIO_CLASS_BE (il nome sta per best-effort) che
è quella usata ordinariamente da tutti processi. In questo caso esistono priorità diverse che
consentono di assegnazione di una maggiore banda passante nell’accesso a disco ad un processo
rispetto agli altri, con meccanismo simile a quello dei valori di nice in cui si evita che un processo
a priorità più alta possa bloccare indefinitamente quelli a priorità più bassa. In questo caso però
le diverse priorità sono soltanto otto, indicate da un valore numerico fra 0 e 7 e come per nice
anche in questo caso un valore più basso indica una priorità maggiore.
Infine la classe di priorità di I/O real-time IOPRIO_CLASS_RT ricalca le omonime priorità di
processore: un processo in questa classe ha sempre la precedenza nell’accesso a disco rispetto
a tutti i processi delle altre classi e di un processo nella stessa classe ma con priorità inferiore,
ed è pertanto in grado di bloccare completamente tutti gli altri. Anche in questo caso ci sono
8 priorità diverse con un valore numerico fra 0 e 7, con una priorità più elevata per valori più
bassi.
In generale nel funzionamento ordinario la priorità di I/O di un processo viene impostata
in maniera automatica nella classe IOPRIO_CLASS_BE con un valore ottenuto a partire dal cor-
rispondente valore di nice tramite la formula: prio = (nice + 20)/5. Un utente ordinario può
56
restituita dalla macro con i valori di tab. 3.13.

modificare con ioprio_set soltanto le priorità dei processi che gli appartengono,57 cioè quelli
il cui user-ID reale corrisponde all’user-ID reale o effettivo del chiamante. Data la possibilità
di ottenere un blocco totale del sistema, solo l’amministratore58 può impostare un processo ad
una priorità di I/O nella classe IOPRIO_CLASS_RT, lo stesso privilegio era richiesto anche per la
classe IOPRIO_CLASS_IDLE fino al kernel 2.6.24, ma dato che in questo caso non ci sono effetti
sugli altri processi questo limite è stato rimosso a partire dal kernel 2.6.25.
3.5 Funzioni di gestione avanzata
Nelle precedenti sezioni si sono trattate la gran parte delle funzioni che attengono alla gestione
ordinaria dei processi e delle loro proprietà più comuni. Tratteremo qui alcune system call dedi-
cate alla gestione di funzionalità dei processi molto specifiche ed avanzate, il cui uso è in genere
piuttosto ridotto. Trattandosi di problematiche abbastanza complesse, che spesso presuppongo-
no la conoscenza di altri argomenti trattati nel seguito della guida, si può saltare questa sezione
in una prima lettura, tornando su di essa in un secondo tempo.
3.5.1 La system call clone
La funzione tradizionale con cui creare un nuovo processo in un sistema Unix-like, come illustrato
in sez. 3.2.2, è fork, ma con l’introduzione del supporto del kernel per i thread (vedi cap. 13),
si è avuta la necessità di una interfaccia che consentisse un maggiore controllo sulla modalità
con cui vengono creati nuovi processi, che poi è stata utilizzata anche per fornire supporto per
le tecnologie di virtualizzazione dei processi (i cosiddetti container).
Per questo l’interfaccia per la creazione di un nuovo processo è stata delegata ad una nuova
system call, sys_clone, che consente di reimplementare anche la tradizionale fork. In realtà in
questo caso più che di nuovi processi si può parlare della creazioni di nuovi “task” del kernel
che possono assumere la veste sia di un processo classico come quelli trattati finora, che di un
thread, come quelli che vedremo in sez. 13.1.2, in cui la memoria viene condivisa fra il processo
chiamante ed il nuovo processo creato. Per evitare confusione fra thread e processi ordinari,
abbiamo deciso di usare la nomenclatura task per indicare la unità di esecuzione generica messa
a disposizione del kernel che sys_clone permette di creare.
Oltre a questo la funzione consente, ad uso delle nuove funzionalità di virtualizzazione dei
processi, di creare nuovi namespace per una serie di proprietà generali dei processi (come l’elenco
dei PID, l’albero dei file, dei mount point, della rete, ecc.), che consentono di creare gruppi di
processi che vivono in una sorta di spazio separato dagli altri, che costituisce poi quello che viene
chiamato un container.
La system call richiede soltanto due argomenti: il primo, flags, consente di controllare le
modalità di creazione del nuovo task, il secondo, child_stack, imposta l’indirizzo dello stack
per il nuovo task, e deve essere indicato quando si intende creare un thread. L’esecuzione del
programma creato da sys_clone riprende, come per fork, da dopo l’esecuzione della stessa.
La necessità di avere uno stack alternativo c’è solo quando si intende creare un thread, in
tal caso infatti il nuovo task vede esattamente la stessa memoria del task “padre”,59 e nella sua
esecuzione alla prima chiamata di una funzione andrebbe a scrivere sullo stack usato anche dal
padre (si ricordi quanto visto in sez. 2.2.2 riguardo all’uso dello stack).
Per evitare di doversi garantire contro la evidente possibilità di race condition che questa
situazione comporta (vedi sez. 3.6.2 per una spiegazione della problematica) è necessario che il
57
per la modifica delle priorità di altri processi occorrono privilegi amministrativi, ed in particolare la capacità
CAP_SYS_NICE (vedi sez. 5.4.4).
58
o un processo con la capacità CAP_SYS_ADMIN (vedi sez. 5.4.4).
59
in questo caso per padre si intende semplicemente il task che ha eseguito sys_clone rispetto al task da essa
creato, senza nessuna delle implicazioni che il concetto ha per i processi.

3.5. FUNZIONI DI GESTIONE AVANZATA 89
chiamante allochi preventivamente un’area di memoria. In genere lo si fa con una malloc che
allochi un buffer che la funzione imposterà come stack del nuovo processo, avendo ovviamente
cura di non utilizzarlo direttamente nel processo chiamante. In questo modo i due task avranno
degli stack indipendenti e non si dovranno affrontare problematiche di race condition. Si tenga
presente inoltre che in molte architetture di processore lo stack cresce verso il basso, pertanto
in tal caso non si dovrà specificare per child_stack il puntatore restituito da malloc, ma un
puntatore alla fine del buffer da essa allocato.
Dato che tutto ciò è necessario solo per i thread che condividono la memoria, la system
call, a differenza della funzione di libreria che vedremo a breve, consente anche di passare per
child_stack il valore NULL, che non imposta un nuovo stack. Se infatti si crea un processo,
questo ottiene un suo nuovo spazio degli indirizzi,60 ed in questo caso si applica la semantica
del copy on write illustrata in sez. 3.2.2, per cui le pagine dello stack verranno automaticamente
copiate come le altre e il nuovo processo avrà un suo stack totalmente indipendente da quello
del padre.
Dato che l’uso principale della nuova system call è quello relativo alla creazione dei thread,
le glibc definiscono una funzione di libreria con una sintassi diversa, orientata a questo scopo,
e la system call resta accessibile solo se invocata esplicitamente come visto in sez. 1.1.3.61 La
funzione di libreria si chiama semplicemente clone ed il suo prototipo è:
#include <sys/sched.h>
int clone(int (*fn)(void *), void *child_stack, int flags, void *arg, ...
/* pid_t *ptid, struct user_desc *tls, pid_t *ctid */)
Crea un nuovo processo o thread eseguendo la funzione fn.
La funzione ritorna al chiamante il Thread ID assegnato al nuovo processo in caso di successo e
−1 in caso di errore, nel qual caso errno può assumere i valori:
EAGAIN sono già in esecuzione troppi processi.
EINVAL si è usata una combinazione non valida di flag o un valore nullo per child_stack.
ENOMEM non c’è memoria sufficiente per creare una nuova task_struct o per copiare le parti
del contesto del chiamante necessarie al nuovo task.
EPERM non si hanno i privilegi di amministratore richiesti dai flag indicati.
La funzione prende come primo argomento il puntatore alla funzione che verrà messa in
esecuzione nel nuovo processo, che può avere un unico argomento di tipo puntatore a void,
il cui valore viene passato dal terzo argomento arg; per quanto il precedente prototipo possa
intimidire nella sua espressione, in realtà l’uso è molto semplice basterà definire una qualunque
funzione fn del tipo indicato, e fn(arg) sarà eseguita in un nuovo processo.
Il nuovo processo resterà in esecuzione fintanto che la funzione fn non ritorna, o esegue exit
o viene terminata da un segnale. Il valore di ritorno della funzione (o quello specificato con exit)
verrà utilizzato come stato di uscita della funzione.
I tre argomenti ptid, tls e ctid sono opzionali e sono presenti solo a partire dal kernel 2.6.
Il comportamento di clone, che si riflette sulle caratteristiche del nuovo processo da essa
creato, è controllato dall’argomento flags,
CLONE_CHILD_CLEARTID
CLONE_CHILD_SETTID
CLONE_FILES
CLONE_FS
60
è sottinteso cioè che non si stia usando il flag CLONE_VM.
61
ed inoltre per questa system call non è disponibile la chiamata veloce con vsyscall.

CLONE_IO
CLONE_NEWIPC
CLONE_NEWNET
CLONE_NEWNS
CLONE_NEWPID
CLONE_NEWUTS
CLONE_PARENT
CLONE_PARENT_SETTID
CLONE_PID
CLONE_PTRACE
CLONE_SETTLS
CLONE_SIGHAND
CLONE_STOPPED
CLONE_SYSVSEM
CLONE_THREAD
CLONE_UNTRACED
CLONE_VFORK
CLONE_VM
3.5.2 La funzione prctl
Benché la gestione ordinaria possa essere effettuata attraverso le funzioni che abbiamo già esa-
minato nelle sezioni precedenti, esistono una serie di proprietà e caratteristiche particolari dei
processi non coperte da esse, per la cui gestione è stata predisposta una apposita system call
che fornisce una interfaccia generica per tutte le operazioni specialistiche. La funzione è prctl
ed il suo prototipo è:62
#include <sys/prctl.h>
int prctl(int option, unsigned long arg2, unsigned long arg3, unsigned long arg4,
unsigned long arg5)
Esegue una operazione speciale sul processo corrente.
La funzione ritorna 0 o un valore positivo dipendente dall’operazione in caso di successo e −1
in caso di errore, nel qual caso errno assumerà valori diversi a seconda del tipo di operazione
richiesta (in genere EINVAL o EPERM).
La funzione ritorna un valore nullo o positivo in caso di successo e −1 in caso di errore;
il significato degli argomenti della funzione successivi al primo, il valore di ritorno in caso di
successo, il tipo di errore restituito in errno dipendono dall’operazione eseguita, indicata tramite
il primo argomento, option. Questo è un valore intero che identifica l’operazione, e deve essere
specificato con l’uso di una delle costanti predefinite del seguente elenco, che illustra quelle
disponibili al momento:
62
la funzione non è standardizzata ed è specifica di Linux, anche se ne esiste una analoga in IRIX; è stata
introdotta con il kernel 2.1.57.

PR_CAPBSET_READ Controlla la disponibilità di una delle capabilities (vedi sez. 5.4.4). La funzione
ritorna 1 se la capacità specificata nell’argomento arg2 (con una delle costanti di tab. 5.20)
è presente nel capabilities bounding set del processo e zero altrimenti, se arg2 non è un
valore valido si avrà un errore di EINVAL. Introdotta a partire dal kernel 2.6.25.
PR_CAPBSET_DROP Rimuove permanentemente una delle capabilities (vedi sez. 5.4.4) dal proces-
so e da tutti i suoi discendenti. La funzione cancella la capacità specificata nell’argomento
arg2 con una delle costanti di tab. 5.20 dal capabilities bounding set del processo. L’o-
perazione richiede i privilegi di amministratore (la capacità CAP_SETPCAP), altrimenti la
chiamata fallirà con un errore di EPERM; se il valore di arg2 non è valido o se il supporto
per le file capabilities non è stato compilato nel kernel la chiamata fallirà con un errore di
EINVAL. Introdotta a partire dal kernel 2.6.25.
PR_SET_DUMPABLE Imposta il flag che determina se la terminazione di un processo a causa di
un segnale per il quale è prevista la generazione di un file di core dump (vedi sez. 9.2.1)
lo genera effettivamente. In genere questo flag viene attivato automaticamente, ma per
evitare problemi di sicurezza (la generazione di un file da parte di processi privilegiati
può essere usata per sovrascriverne altri) viene cancellato quando si mette in esecuzione
un programma con i bit suid e sgid attivi (vedi sez. 5.3.2) o con l’uso delle funzioni per
la modifica degli user-ID dei processi (vedi sez. 3.3.2). L’operazione è stata introdotta a
partire dal kernel 2.3.20, fino al kernel 2.6.12 e per i kernel successivi al 2.6.17 era possibile
usare solo un valore 0 di arg2 per disattivare il flag ed un valore 1 per attivarlo, nei kernel
dal 2.6.13 al 2.6.17 è stato supportato anche il valore 2, che causava la generazione di un
core dump leggibile solo dall’amministratore.63
PR_GET_DUMPABLE Ottiene come valore di ritorno della funzione lo stato corrente del flag che
controlla la effettiva generazione dei core dump. Introdotta a partire dal kernel 2.3.20.
PR_SET_ENDIAN Imposta la endianess del processo chiamante secondo il valore fornito in arg2. I
valori possibili sono sono: PR_ENDIAN_BIG (big endian), PR_ENDIAN_LITTLE (little endian),
e PR_ENDIAN_PPC_LITTLE (lo pseudo little endian del PowerPC). Introdotta a partire dal
kernel 2.6.18, solo per architettura PowerPC.
PR_GET_ENDIAN Ottiene il valore della endianess del processo chiamante, salvato sulla variabile
puntata da arg2 che deve essere passata come di tipo (int *). Introdotta a partire dal
kernel 2.6.18, solo su PowerPC.
PR_SET_FPEMU Imposta i bit di controllo per l’emulazione della virgola mobile su architettura
ia64, secondo il valore di arg2, si deve passare PR_FPEMU_NOPRINT per emulare in maniera
trasparente l’accesso alle operazioni in virgola mobile, o PR_FPEMU_SIGFPE per non emularle
ed inviare il segnale SIGFPE (vedi sez. 9.2.2). Introdotta a partire dal kernel 2.4.18, solo su
ia64.
PR_GET_FPEMU Ottiene il valore dei flag di controllo dell’emulazione della virgola mobile, salvato
all’indirizzo puntato da arg2, che deve essere di tipo (int *). Introdotta a partire dal
kernel 2.4.18, solo su ia64.
PR_SET_FPEXC Imposta la modalità delle eccezioni in virgola mobile (floating-point exception
mode) al valore di arg2. I valori possibili sono: PR_FP_EXC_SW_ENABLE per usare FPEXC
per le eccezioni, PR_FP_EXC_DIV per la divisione per zero in virgola mobile, PR_FP_EXC_OVF
per gli overflow, PR_FP_EXC_UND per gli underflow, PR_FP_EXC_RES per risultati non esatti,
63
la funzionalità è stata rimossa per motivi di sicurezza, in quanto consentiva ad un utente normale di creare un
file di core dump appartenente all’amministratore in directory dove l’utente avrebbe avuto permessi di accesso.

PR_FP_EXC_INV per operazioni invalide, PR_FP_EXC_DISABLED per disabilitare le eccezio-
ni, PR_FP_EXC_NONRECOV per utilizzare la modalità di eccezione asincrona non recupe-
rabile, PR_FP_EXC_ASYNC per utilizzare la modalità di eccezione asincrona recuperabile,
PR_FP_EXC_PRECISE per la modalità precisa di eccezione.64 Introdotta a partire dal kernel
2.4.21, solo su PowerPC.
PR_GET_FPEXC Ottiene il valore della modalità delle eccezioni delle operazioni in virgola mobile,
salvata all’indirizzo puntato arg2, che deve essere di tipo (int *). Introdotta a partire
dal kernel 2.4.21, solo su PowerPC.
PR_SET_KEEPCAPS Consente di controllare quali capabilities vengono cancellate quando si esegue
un cambiamento di user-ID del processo (per i dettagli si veda sez. 5.4.4, in particolare
quanto illustrato a pag. 169). Un valore nullo (il default) per arg2 comporta che venga-
no cancellate, il valore 1 che vengano mantenute, questo valore viene sempre cancellato
attraverso una exec. L’uso di questo flag è stato sostituito, a partire dal kernel 2.6.26,
dal flag SECURE_KEEP_CAPS dei securebits (vedi l’uso di PR_SET_SECUREBITS più avanti).
Introdotta a partire dal kernel 2.2.18.
PR_GET_KEEPCAPS Ottiene come valore di ritorno della funzione il valore del flag di controllo
impostato con PR_SET_KEEPCAPS. Introdotta a partire dal kernel 2.2.18.
PR_SET_NAME Imposta il nome del processo chiamante alla stringa puntata da arg2, che deve
essere di tipo (char *). Il nome può essere lungo al massimo 16 caratteri, e la stringa
deve essere terminata da NUL se più corta. Introdotta a partire dal kernel 2.6.9.
PR_GET_NAME Ottiene il nome del processo chiamante nella stringa puntata da arg2, che deve
essere di tipo (char *); si devono allocare per questo almeno 16 byte, e il nome sarà
terminato da NUL se più corto. Introdotta a partire dal kernel 2.6.9.
PR_SET_PDEATHSIG Consente di richiedere l’emissione di un segnale, che sarà ricevuto dal pro-
cesso chiamante, in occorrenza della terminazione del proprio processo padre; in sostanza
consente di invertire il ruolo di SIGCHLD. Il valore di arg2 deve indicare il numero del
segnale, o 0 per disabilitare l’emissione. Il valore viene automaticamente cancellato per un
processo figlio creato con fork. Introdotta a partire dal kernel 2.1.57.
PR_GET_PDEATHSIG Ottiene il valore dell’eventuale segnale emesso alla terminazione del padre,
salvato all’indirizzo puntato arg2, che deve essere di tipo (int *). Introdotta a partire
dal kernel 2.3.15.
PR_SET_SECCOMP Imposta il cosiddetto secure computing mode per il processo corrente. Prevede
come unica possibilità che arg2 sia impostato ad 1. Una volta abilitato il secure computing
mode il processo potrà utilizzare soltanto un insieme estremamente limitato di system
call: read, write, _exit e sigreturn, ogni altra system call porterà all’emissione di un
SIGKILL (vedi sez. 9.2.3). Il secure computing mode è stato ideato per fornire un supporto
per l’esecuzione di codice esterno non fidato e non verificabile a scopo di calcolo;65 in
genere i dati vengono letti o scritti grazie ad un socket o una pipe, e per evitare problemi
di sicurezza non sono possibili altre operazioni se non quelle citate. Introdotta a partire dal
kernel 2.6.23, disponibile solo se si è abilitato il supporto nel kernel con CONFIG_SECCOMP.
64
trattasi di gestione specialistica della gestione delle eccezioni dei calcoli in virgola mobile che, i cui dettagli al
momento vanno al di là dello scopo di questo testo.
65
lo scopo è quello di poter vendere la capacità di calcolo della proprio macchina ad un qualche servizio di
calcolo distribuito senza comprometterne la sicurezza eseguendo codice non sotto il proprio controllo.

PR_GET_SECCOMP Ottiene come valore di ritorno della funzione lo stato corrente del secure com-
puting mode, al momento attuale la funzione è totalmente inutile in quanto l’unico valore
ottenibile è 0, dato che la chiamata di questa funzione in secure computing mode compor-
terebbe l’emissione di SIGKILL, è stata comunque definita per eventuali estensioni future.
PR_SET_SECUREBITS Imposta i securebits per il processo chiamante al valore indicato da arg2;
per i dettagli sul significato dei securebits si veda sez. 5.4.4, ed in particolare i valori di
tab. 5.19 e la relativa trattazione. L’operazione richiede i privilegi di amministratore (la
capacità CAP_SETPCAP), altrimenti la chiamata fallirà con un errore di EPERM. Introdotta
a partire dal kernel 2.6.26.
PR_GET_SECUREBITS Ottiene come valore di ritorno della funzione l’impostazione corrente per i
securebits. Introdotta a partire dal kernel 2.6.26.
PR_SET_TIMING Imposta il metodo di temporizzazione del processo da indicare con il valo-
re di arg2, con PR_TIMING_STATISTICAL si usa il metodo statistico tradizionale, con
PR_TIMING_TIMESTAMP il più accurato basato su dei timestamp, quest’ultimo però non
è ancora implementato ed il suo uso comporta la restituzione di un errore di EINVAL.
Introdotta a partire dal kernel 2.6.0-test4.
PR_GET_TIMING Ottiene come valore di ritorno della funzione il metodo di temporizzazione del
processo attualmente in uso. Introdotta a partire dal kernel 2.6.0-test4.
PR_SET_TSC Imposta il flag che indica se il processo chiamante può leggere il registro di pro-
cessore contenente il contatore dei timestamp (TSC, o Time Stamp Counter) da indi-
care con il valore di arg2. Si deve specificare PR_TSC_ENABLE per abilitare la lettura
o PR_TSC_SIGSEGV per disabilitarla con la generazione di un segnale di SIGSEGV (vedi
sez. 9.2.2). La lettura viene automaticamente disabilitata se si attiva il secure computing
mode. Introdotta a partire dal kernel 2.6.26, solo su x86.
PR_GET_TSC Ottiene il valore del flag che controlla la lettura del contattore dei timestamp,
salvato all’indirizzo puntato arg2, che deve essere di tipo (int *). Introdotta a partire
dal kernel 2.6.26, solo su x86.
PR_SET_UNALIGN Imposta la modalità di controllo per l’accesso a indirizzi di memoria non alli-
neati, che in varie architetture risultano illegali, da indicare con il valore di arg2. Si deve
specificare il valore PR_UNALIGN_NOPRINT per ignorare gli accessi non allineati, ed il valore
PR_UNALIGN_SIGBUS per generare un segnale di SIGBUS (vedi sez. 9.2.2) in caso di accesso
non allineato. Introdotta con diverse versioni su diverse architetture.
PR_GET_UNALIGN Ottiene il valore della modalità di controllo per l’accesso a indirizzi di memoria
non allineati, salvato all’indirizzo puntato arg2, che deve essere di tipo (int *). Introdotta
con diverse versioni su diverse architetture.
PR_MCE_KILL Imposta la politica di gestione degli errori dovuti a corruzione della memoria
per problemi hardware. Questo tipo di errori vengono riportati dall’hardware di controllo
della RAM e vengono gestiti dal kernel,66 ma devono essere opportunamente riportati
ai processi che usano quella parte di RAM che presenta errori; nel caso specifico questo
avviene attraverso l’emissione di un segnale di SIGBUS (vedi sez. 9.2.2).67
66
la funzionalità è disponibile solo sulle piattaforme più avanzate che hanno il supporto hardware per questo
tipo di controlli.
67
in particolare viene anche impostato il valore di si_code in siginfo_t a BUS_MCEERR_AO; per il significato di
tutto questo si faccia riferimento alla trattazione di sez. 9.4.3.

Il comportamento di default prevede che per tutti i processi si applichi la politica generale
di sistema definita nel file /proc/sys/vm/memory_failure_early_kill, ma specificando
per arg2 il valore PR_MCE_KILL_SET è possibile impostare con il contenuto di arg3 una
politica specifica del processo chiamante. Si può tornare alla politica di default del sistema
utilizzando invece per arg2 il valore PR_MCE_KILL_CLEAR. In tutti i casi, per compatibilità
con eventuali estensioni future, tutti i valori degli argomenti non utilizzati devono essere
esplicitamente posti a zero, pena il fallimento della chiamata con un errore di EINVAL.
In caso di impostazione di una politica specifica del processo con PR_MCE_KILL_SET i valori
di arg3 possono essere soltanto due, che corrispondono anche al valore che si trova nell’im-
postazione generale di sistema di memory_failure_early_kill, con PR_MCE_KILL_EARLY
si richiede l’emissione immediata di SIGBUS non appena viene rilevato un errore, men-
tre con PR_MCE_KILL_LATE il segnale verrà inviato solo quando il processo tenterà un
accesso alla memoria corrotta. Questi due valori corrispondono rispettivamente ai valo-
ri 1 e 0 di memory_failure_early_kill.68 Si può usare per arg3 anche un terzo valore,
PR_MCE_KILL_DEFAULT, che corrisponde a impostare per il processo la politica di default.69
PR_MCE_KILL_GET Ottiene come valore di ritorno della funzione la politica di gestione degli
errori dovuti a corruzione della memoria. Tutti gli argomenti non utilizzati (al momento
tutti) devono essere nulli pena la ricezione di un errore di EINVAL. Introdotta a partire dal
kernel 2.6.32.
3.5.3 La funzione ptrace
Da fare
3.5.4 L’accesso alle porte di I/O
Da fare
3.6 Problematiche di programmazione multitasking
Benché i processi siano strutturati in modo da apparire il più possibile come indipendenti l’uno
dall’altro, nella programmazione in un sistema multitasking occorre tenere conto di una serie di
problematiche che normalmente non esistono quando si ha a che fare con un sistema in cui viene
eseguito un solo programma alla volta.
Pur essendo questo argomento di carattere generale, ci è parso opportuno introdurre sinte-
ticamente queste problematiche, che ritroveremo a più riprese in capitoli successivi, in questa
sezione conclusiva del capitolo in cui abbiamo affrontato la gestione dei processi.
3.6.1 Le operazioni atomiche
La nozione di operazione atomica deriva dal significato greco della parola atomo, cioè indivisibile;
si dice infatti che un’operazione è atomica quando si ha la certezza che, qualora essa venga
effettuata, tutti i passaggi che devono essere compiuti per realizzarla verranno eseguiti senza
possibilità di interruzione in una fase intermedia.
68
in sostanza nel primo caso viene immediatamente inviato il segnale a tutti i processi che hanno la memoria
corrotta mappata all’interno del loro spazio degli indirizzi, nel secondo caso prima la pagina di memoria viene
tolta dallo spazio degli indirizzi di ciascun processo, mentre il segnale viene inviato solo quei processi che tentano
di accedervi.
69
si presume la politica di default corrente, in modo da non essere influenzati da un eventuale successivo
cambiamento della stessa.

3.6. PROBLEMATICHE DI PROGRAMMAZIONE MULTITASKING 95
In un ambiente multitasking il concetto è essenziale, dato che un processo può essere interrot-
to in qualunque momento dal kernel che mette in esecuzione un altro processo o dalla ricezione
di un segnale; occorre pertanto essere accorti nei confronti delle possibili race condition (vedi
sez. 3.6.2) derivanti da operazioni interrotte in una fase in cui non erano ancora state completate.
Nel caso dell’interazione fra processi la situazione è molto più semplice, ed occorre preoc-
cuparsi della atomicità delle operazioni solo quando si ha a che fare con meccanismi di inter-
comunicazione (che esamineremo in dettaglio in cap. 11) o nelle operazioni con i file (vedremo
alcuni esempi in sez. 6.3.2). In questi casi in genere l’uso delle appropriate funzioni di libreria
per compiere le operazioni necessarie è garanzia sufficiente di atomicità in quanto le system call
con cui esse sono realizzate non possono essere interrotte (o subire interferenze pericolose) da
altri processi.
Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo stesso processo, e
pure alcune system call, possono essere interrotti in qualunque momento, e le operazioni di un
eventuale signal handler sono compiute nello stesso spazio di indirizzi del processo. Per questo,
anche il solo accesso o l’assegnazione di una variabile possono non essere più operazioni atomiche
(torneremo su questi aspetti in sez. 9.4).
In questo caso il sistema provvede un tipo di dato, il sig_atomic_t, il cui accesso è assicurato
essere atomico. In pratica comunque si può assumere che, in ogni piattaforma su cui è imple-
mentato Linux, il tipo int, gli altri interi di dimensione inferiore ed i puntatori sono atomici.
Non è affatto detto che lo stesso valga per interi di dimensioni maggiori (in cui l’accesso può
comportare più istruzioni in assembler) o per le strutture. In tutti questi casi è anche opportuno
marcare come volatile le variabili che possono essere interessate ad accesso condiviso, onde
evitare problemi con le ottimizzazioni del codice.
3.6.2 Le race condition ed i deadlock
Si definiscono race condition tutte quelle situazioni in cui processi diversi operano su una risorsa
comune, ed in cui il risultato viene a dipendere dall’ordine in cui essi effettuano le loro operazioni.
Il caso tipico è quello di un’operazione che viene eseguita da un processo in più passi, e può essere
compromessa dall’intervento di un altro processo che accede alla stessa risorsa quando ancora
non tutti i passi sono stati completati.
Dato che in un sistema multitasking ogni processo può essere interrotto in qualunque mo-
mento per farne subentrare un altro in esecuzione, niente può assicurare un preciso ordine di
esecuzione fra processi diversi o che una sezione di un programma possa essere eseguita senza
interruzioni da parte di altri. Queste situazioni comportano pertanto errori estremamente sub-
doli e difficili da tracciare, in quanto nella maggior parte dei casi tutto funzionerà regolarmente,
e solo occasionalmente si avranno degli errori.
Per questo occorre essere ben consapevoli di queste problematiche, e del fatto che l’unico
modo per evitarle è quello di riconoscerle come tali e prendere gli adeguati provvedimenti per
far s`ı che non si verifichino. Casi tipici di race condition si hanno quando diversi processi accedono
allo stesso file, o nell’accesso a meccanismi di intercomunicazione come la memoria condivisa. In
questi casi, se non si dispone della possibilità di eseguire atomicamente le operazioni necessarie,
occorre che quelle parti di codice in cui si compiono le operazioni sulle risorse condivise (le
cosiddette sezioni critiche) del programma, siano opportunamente protette da meccanismi di
sincronizzazione (torneremo su queste problematiche di questo tipo in cap. 11).
Un caso particolare di race condition sono poi i cosiddetti deadlock (traducibile in condizioni
di stallo), particolarmente gravi in quanto comportano spesso il blocco completo di un servizio,
e non il fallimento di una singola operazione. Per definizione un deadlock è una situazione in cui
due o più processi non sono più in grado di proseguire perché ciascuno aspetta il risultato di
una operazione che dovrebbe essere eseguita dall’altro.

L’esempio tipico di una situazione che può condurre ad un deadlock è quello in cui un flag di
“occupazione” viene rilasciato da un evento asincrono (come un segnale o un altro processo) fra
il momento in cui lo si è controllato (trovandolo occupato) e la successiva operazione di attesa
per lo sblocco. In questo caso, dato che l’evento di sblocco del flag è avvenuto senza che ce ne
accorgessimo proprio fra il controllo e la messa in attesa, quest’ultima diventerà perpetua (da
cui il nome di deadlock).
In tutti questi casi è di fondamentale importanza il concetto di atomicità visto in sez. 3.6.1;
questi problemi infatti possono essere risolti soltanto assicurandosi, quando essa sia richiesta,
che sia possibile eseguire in maniera atomica le operazioni necessarie.
3.6.3 Le funzioni rientranti
Si dice rientrante una funzione che può essere interrotta in qualunque punto della sua esecuzione
ed essere chiamata una seconda volta da un altro thread di esecuzione senza che questo comporti
nessun problema nell’esecuzione della stessa. La problematica è comune nella programmazione
multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare delle funzioni all’interno
dei gestori dei segnali.
Fintanto che una funzione opera soltanto con le variabili locali è rientrante; queste infatti
vengono allocate nello stack, ed un’altra invocazione non fa altro che allocarne un’altra copia.
Una funzione può non essere rientrante quando opera su memoria che non è nello stack. Ad
esempio una funzione non è mai rientrante se usa una variabile globale o statica.
Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la cosa viene a
dipendere da come avvengono le operazioni: se l’oggetto è creato ogni volta e ritornato indietro
la funzione può essere rientrante, se invece esso viene individuato dalla funzione stessa due
chiamate alla stessa funzione potranno interferire quando entrambe faranno riferimento allo
stesso oggetto. Allo stesso modo una funzione può non essere rientrante se usa e modifica un
oggetto che le viene fornito dal chiamante: due chiamate possono interferire se viene passato lo
stesso oggetto; in tutti questi casi occorre molta cura da parte del programmatore.
In genere le funzioni di libreria non sono rientranti, molte di esse ad esempio utilizzano
variabili statiche, le glibc però mettono a disposizione due macro di compilatore,70 _REENTRANT
e _THREAD_SAFE, la cui definizione attiva le versioni rientranti di varie funzioni di libreria, che
sono identificate aggiungendo il suffisso _r al nome della versione normale.
70
si ricordi quanto illustrato in sez. 1.2.7.

Capitolo 4
L’architettura dei file
Uno dei concetti fondamentali dell’architettura di un sistema Unix è il cosiddetto everything is
a file, cioè il fatto che l’accesso ai vari dispositivi di input/output del computer viene effettuato
attraverso un’interfaccia astratta che tratta le periferiche allo stesso modo dei normali file di
dati.
Questo significa che si può accedere a qualunque periferica del computer, dalla seriale, alla
parallela, alla console, e agli stessi dischi attraverso i cosiddetti file di dispositivo (i cosiddetti
device file). Questi sono dei file speciali agendo sui quali i programmi possono leggere, scrivere
e compiere operazioni direttamente sulle periferiche, usando le stesse funzioni che si usano per i
normali file di dati.
In questo capitolo forniremo una descrizione dell’architettura dei file in Linux, iniziando da
una panoramica sulle caratteristiche principali delle interfacce con cui i processi accedono ai
file (che tratteremo in dettaglio nei capitoli seguenti), per poi passare ad una descrizione più
dettagliata delle modalità con cui detto accesso viene realizzato dal sistema.
4.1 L’architettura generale
Per poter accedere ai file, il kernel deve mettere a disposizione dei programmi le opportune
interfacce che consentano di leggerne il contenuto; il sistema cioè deve provvedere ad organizzare
e rendere accessibile in maniera opportuna l’informazione tenuta sullo spazio grezzo disponibile
sui dischi. Questo viene fatto strutturando l’informazione sul disco attraverso quello che si chiama
un filesystem (vedi sez. 4.2), essa poi viene resa disponibile ai processi attraverso quello che viene
chiamato il montaggio del filesystem.
In questa sezione faremo una panoramica generica su come il sistema presenta i file ai processi,
trattando l’organizzazione di file e directory, i tipi di file ed introducendo le interfacce disponibili
e le loro caratteristiche.
4.1.1 L’organizzazione di file e directory
In Unix, a differenza di quanto avviene in altri sistemi operativi, tutti i file vengono tenuti all’in-
terno di un unico albero la cui radice (quella che viene chiamata root directory) viene montata
all’avvio. Un file viene identificato dall’utente usando quello che viene chiamato pathname1, cioè
il percorso che si deve fare per accedere al file a partire dalla root directory, che è composto da
una serie di nomi separati da una “/”.
1
il manuale della glibc depreca questa nomenclatura, che genererebbe confusione poiché path indica anche un
insieme di directory su cui effettuare una ricerca (come quello in cui si cercano i comandi). Al suo posto viene
proposto l’uso di filename e di componente per il nome del file all’interno della directory. Non seguiremo questa
scelta dato che l’uso della parola pathname è ormai cos`ı comune che mantenerne l’uso è senz’altro più chiaro
dell’alternativa proposta.
97

98 CAPITOLO 4. L’ARCHITETTURA DEI FILE
All’avvio del sistema, completata la fase di inizializzazione, il kernel riceve dal bootloader
l’indicazione di quale dispositivo contiene il filesystem da usare come punto di partenza e que-
sto viene montato come radice dell’albero (cioè nella directory /); tutti gli ulteriori filesystem
che possono essere su altri dispositivi dovranno poi essere inseriti nell’albero montandoli su
opportune directory del filesystem montato come radice.
Alcuni filesystem speciali (come /proc che contiene un’interfaccia ad alcune strutture interne
del kernel) sono generati automaticamente dal kernel stesso, ma anche essi devono essere montati
all’interno dell’albero dei file.
Una directory, come vedremo in maggior dettaglio in sez. 4.2.2, è anch’essa un file, solo che
è un file particolare che il kernel riconosce come tale. Il suo scopo è quello di contenere una lista
di nomi di file e le informazioni che associano ciascun nome al contenuto. Dato che questi nomi
possono corrispondere ad un qualunque oggetto del filesystem, compresa un’altra directory, si
ottiene naturalmente un’organizzazione ad albero inserendo nomi di directory in altre directory.
Un file può essere indicato rispetto alla directory corrente semplicemente specificandone il
nome2 da essa contenuto. All’interno dello stesso albero si potranno poi inserire anche tutti gli
altri oggetti visti attraverso l’interfaccia che manipola i file come le fifo, i link, i socket e gli stessi
file di dispositivo (questi ultimi, per convenzione, sono inseriti nella directory /dev).
Il nome completo di un file viene chiamato pathname ed il procedimento con cui si individua
il file a cui esso fa riferimento è chiamato risoluzione del nome (filename resolution o pathname
resolution). La risoluzione viene fatta esaminando il pathname da sinistra a destra e localizzando
ogni nome nella directory indicata dal nome precedente usando il carattere“/”come separatore3:
ovviamente, perché il procedimento funzioni, occorre che i nomi indicati come directory esistano
e siano effettivamente directory, inoltre i permessi (si veda sez. 5.3) devono consentire l’accesso
all’intero pathname.
Se il pathname comincia con il carattere“/”la ricerca parte dalla directory radice del processo;
questa, a meno di un chroot (su cui torneremo in sez. 5.4.5) è la stessa per tutti i processi ed
equivale alla directory radice dell’albero dei file: in questo caso si parla di un pathname assoluto .
Altrimenti la ricerca parte dalla directory corrente (su cui torneremo in sez. 5.1.7) ed il pathname
è detto pathname relativo.
I nomi “.” e “..” hanno un significato speciale e vengono inseriti in ogni directory: il primo
fa riferimento alla directory corrente e il secondo alla directory genitrice (o parent directory)
cioè la directory che contiene il riferimento alla directory corrente; nel caso la directory corrente
coincida con la directory radice, allora il riferimento è a se stessa.
4.1.2 I tipi di file
Come detto in precedenza, in Unix esistono vari tipi di file; in Linux questi sono implementati
come oggetti del Virtual File System (vedi sez. 4.2.2) e sono presenti in tutti i filesystem unix-like
utilizzabili con Linux. L’elenco dei vari tipi di file definiti dal Virtual File System è riportato in
tab. 4.1.
Si tenga ben presente che questa classificazione non ha nulla a che fare con la classificazione
dei file (che in questo caso sono sempre file di dati) in base al loro contenuto, o tipo di accesso.
Essa riguarda invece il tipo di oggetti; in particolare è da notare la presenza dei cosiddetti file
speciali. Alcuni di essi, come le fifo (che tratteremo in sez. 11.1.4) ed i socket (che tratteremo
in cap. 15) non sono altro che dei riferimenti per utilizzare delle funzionalità di comunicazione
fornite dal kernel. Gli altri sono i file di dispositivo (o device file) che costituiscono una interfaccia
diretta per leggere e scrivere sui dispositivi fisici; essi vengono suddivisi in due grandi categorie,
2
il manuale delle glibc chiama i nomi contenuti nelle directory componenti (in inglese file name components),
noi li chiameremo più semplicemente nomi o voci.
3
nel caso di nome vuoto, il costrutto // viene considerato equivalente a /.

4.1. L’ARCHITETTURA GENERALE 99
a blocchi e a caratteri a seconda delle modalità in cui il dispositivo sottostante effettua le
operazioni di I/O.4
Tipo di file Descrizione
regular file file regolare Un file che contiene dei dati (l’accezione normale
di file).
directory cartella o direttorio Un file che contiene una lista di nomi associati a
degli inode (vedi sez. 4.2.1).
symbolic link collegamento simbolico Un file che contiene un riferimento ad un altro
file/directory.
char device dispositivo a caratteri Un file che identifica una periferica ad accesso a
caratteri.
block device dispositivo a blocchi Un file che identifica una periferica ad accesso a
blocchi.
fifo “coda” Un file speciale che identifica una linea di comuni-
cazione software unidirezionale (vedi sez. 11.1.4).
socket “presa” Un file speciale che identifica una linea di comu-
nicazione software bidirezionale (vedi cap. 15).
Tabella 4.1: Tipologia dei file definiti nel VFS
Una delle differenze principali con altri sistemi operativi (come il VMS o Windows) è che
per Unix tutti i file di dati sono identici e contengono un flusso continuo di byte. Non esiste cioè
differenza per come vengono visti dal sistema file di diverso contenuto o formato (come nel caso
di quella fra file di testo e binari che c’è in Windows) né c’è una strutturazione a record per il
cosiddetto “accesso diretto” come nel caso del VMS.5
Una seconda differenza è nel formato dei file di testo: in Unix la fine riga è codificata in
maniera diversa da Windows o dal vecchio MacOS, in particolare il fine riga è il carattere LF
(o n) al posto del CR (r) del vecchio MacOS e del CR LF di Windows.6 Questo può causare
alcuni problemi qualora nei programmi si facciano assunzioni sul terminatore della riga.
Si ricordi infine che un kernel Unix non fornisce nessun supporto per la tipizzazione dei file
di dati e che non c’è nessun supporto del sistema per le estensioni come parte del filesystem.7
Ciò nonostante molti programmi adottano delle convenzioni per i nomi dei file, ad esempio il
codice C normalmente si mette in file con l’estensione .c; un’altra tecnica molto usata è quella
di utilizzare i primi 4 byte del file per memorizzare un magic number che classifichi il contenuto;
entrambe queste tecniche, per quanto usate ed accettate in maniera diffusa, restano solo delle
convenzioni il cui rispetto è demandato alle applicazioni stesse.
4.1.3 Le due interfacce ai file
In Linux le modalità di accesso ai file e le relative interfacce di programmazione sono due, basate
su due diversi meccanismi con cui è possibile accedere al loro contenuto.
4
in sostanza i dispositivi a blocchi (ad esempio i dischi) corrispondono a periferiche per le quali è richiesto che
l’I/O venga effettuato per blocchi di dati di dimensioni fissate (ad esempio le dimensioni di un settore), mentre
nei dispositivi a caratteri l’I/O viene effettuato senza nessuna particolare struttura.
5
questo vale anche per i dispositivi a blocchi: la strutturazione dell’I/O in blocchi di dimensione fissa avviene
solo all’interno del kernel, ed è completamente trasparente all’utente. Inoltre talvolta si parla di accesso diretto
riferendosi alla capacità, che non ha niente a che fare con tutto ciò, di effettuare, attraverso degli appositi file
di dispositivo, operazioni di I/O direttamente sui dischi senza passare attraverso un filesystem, il cosiddetto raw
access, introdotto coi kernel della serie 2.4.x ed in sostanziale disuso.
6
per questo esistono in Linux dei programmi come unix2dos e dos2unix che effettuano una conversione fra
questi due formati di testo.
7
non è cos`ı ad esempio nel filesystem HFS dei Mac, che supporta delle risorse associate ad ogni file, che
specificano fra l’altro il contenuto ed il programma da usare per leggerlo. In realtà per alcuni filesystem esiste
la possibilità di associare delle risorse ai file con gli extended attributes (vedi sez. 5.4.1), ma è una caratteristica
tutt’ora poco utilizzata, dato che non corrisponde al modello classico dei file in un sistema Unix.

La prima è l’interfaccia standard di Unix, quella che il manuale delle glibc chiama interfaccia
dei descrittori di file (o file descriptor). È un’interfaccia specifica dei sistemi unix-like e fornisce
un accesso non bufferizzato; la tratteremo in dettaglio in cap. 6.
L’interfaccia è primitiva ed essenziale, l’accesso viene detto non bufferizzato in quanto la
lettura e la scrittura vengono eseguite chiamando direttamente le system call del kernel (in realtà
il kernel effettua al suo interno alcune bufferizzazioni per aumentare l’efficienza nell’accesso ai
dispositivi); i file descriptor sono rappresentati da numeri interi (cioè semplici variabili di tipo
int). L’interfaccia è definita nell’header unistd.h.
La seconda interfaccia è quella che il manuale della glibc chiama degli stream.8 Essa fornisce
funzioni più evolute e un accesso bufferizzato (controllato dalla implementazione fatta dalle
glibc), la tratteremo in dettaglio nel cap. 7.
Questa è l’interfaccia standard specificata dall’ANSI C e perciò si trova anche su tutti i
sistemi non Unix. Gli stream sono oggetti complessi e sono rappresentati da puntatori ad un
opportuna struttura definita dalle librerie del C; si accede ad essi sempre in maniera indiretta
utilizzando il tipo FILE *. L’interfaccia è definita nell’header stdio.h.
Entrambe le interfacce possono essere usate per l’accesso ai file come agli altri oggetti del
VFS (fifo, socket, dispositivi, sui quali torneremo in dettaglio a tempo opportuno), ma per poter
accedere alle operazioni di controllo (descritte in sez. 6.3.6 e sez. 6.3.7) su un qualunque tipo
di oggetto del VFS occorre usare l’interfaccia standard di Unix con i file descriptor. Allo stesso
modo devono essere usati i file descriptor se si vuole ricorrere a modalità speciali di I/O come
il file locking o l’I/O non-bloccante (vedi cap. 12).
Gli stream forniscono un’interfaccia di alto livello costruita sopra quella dei file descriptor, che
permette di poter scegliere tra diversi stili di bufferizzazione. Il maggior vantaggio degli stream
è che l’interfaccia per le operazioni di input/output è enormemente più ricca di quella dei file
descriptor, che forniscono solo funzioni elementari per la lettura/scrittura diretta di blocchi di
byte. In particolare gli stream dispongono di tutte le funzioni di formattazione per l’input e
l’output adatte per manipolare anche i dati in forma di linee o singoli caratteri.
In ogni caso, dato che gli stream sono implementati sopra l’interfaccia standard di Unix, è
sempre possibile estrarre il file descriptor da uno stream ed eseguirvi operazioni di basso livello,
o associare in un secondo tempo uno stream ad un file descriptor.
In generale, se non necessitano specificatamente le funzionalità di basso livello, è opportuno
usare sempre gli stream per la loro maggiore portabilità, essendo questi ultimi definiti nello
standard ANSI C; l’interfaccia con i file descriptor infatti segue solo lo standard POSIX.1 dei
sistemi Unix, ed è pertanto di portabilità più limitata.
4.2 L’architettura della gestione dei file
In questa sezione esamineremo come viene implementato l’accesso ai file in Linux, come il kernel
può gestire diversi tipi di filesystem, descrivendo prima le caratteristiche generali di un filesystem
di un sistema unix-like, per poi trattare in maniera un po’ più dettagliata il filesystem più usato
con Linux, l’ext2 (e derivati).
4.2.1 Il Virtual File System di Linux
In Linux il concetto di everything is a file è stato implementato attraverso il Virtual File System
(da qui in avanti VFS) che è uno strato intermedio che il kernel usa per accedere ai più svariati
filesystem mantenendo la stessa interfaccia per i programmi in user space. Esso fornisce un livello
8
in realtà una interfaccia con lo stesso nome è stata introdotta a livello di kernel negli Unix derivati da System
V, come strato di astrazione per file e socket; in Linux questa interfaccia, che comunque ha avuto poco successo,
non esiste, per cui facendo riferimento agli stream useremo il significato adottato dal manuale delle glibc.

4.2. L’ARCHITETTURA DELLA GESTIONE DEI FILE 101
di indirezione che permette di collegare le operazioni di manipolazione sui file alle operazioni
di I/O, e gestisce l’organizzazione di queste ultime nei vari modi in cui i diversi filesystem le
effettuano, permettendo la coesistenza di filesystem differenti all’interno dello stesso albero delle
directory.
Quando un processo esegue una system call che opera su un file, il kernel chiama sempre una
funzione implementata nel VFS; la funzione eseguirà le manipolazioni sulle strutture generiche e
utilizzerà poi la chiamata alle opportune funzioni del filesystem specifico a cui si fa riferimento.
Saranno queste a chiamare le funzioni di più basso livello che eseguono le operazioni di I/O sul
dispositivo fisico, secondo lo schema riportato in fig. 4.1.
Figura 4.1: Schema delle operazioni del VFS.
Il VFS definisce un insieme di funzioni che tutti i filesystem devono implementare. L’inter-
faccia comprende tutte le funzioni che riguardano i file; le operazioni sono suddivise su tre tipi
di oggetti: filesystem, inode e file, corrispondenti a tre apposite strutture definite nel kernel.
Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun filesystem suppor-
tato: quando si vuole inserire il supporto di un nuovo filesystem tutto quello che occorre è chia-
mare la funzione register_filesystem passandole un’apposita struttura file_system_type
che contiene i dettagli per il riferimento all’implementazione del medesimo, che sarà aggiunta
alla citata tabella.
In questo modo quando viene effettuata la richiesta di montare un nuovo disco (o qualunque
altro block device che può contenere un filesystem), il VFS può ricavare dalla citata tabella il
puntatore alle funzioni da chiamare nelle operazioni di montaggio. Quest’ultima è responsabile
di leggere da disco il superblock (vedi sez. 4.2.4), inizializzare tutte le variabili interne e restituire
uno speciale descrittore dei filesystem montati al VFS; attraverso quest’ultimo diventa possibile
accedere alle funzioni specifiche per l’uso di quel filesystem.

Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad una apposita
struttura che contiene vari dati come le informazioni comuni ad ogni filesystem, i dati privati
relativi a quel filesystem specifico, e i puntatori alle funzioni del kernel relative al filesystem.
Il VFS può cos`ı usare le funzioni contenute nel filesystem descriptor per accedere alle funzioni
specifiche di quel filesystem.
Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti su cui è strutturata
l’interfaccia. Ciascuno di essi contiene le informazioni relative al file in uso, insieme ai puntatori
alle funzioni dello specifico filesystem usate per l’accesso dal VFS; in particolare il descrittore
dell’inode contiene i puntatori alle funzioni che possono essere usate su qualunque file (come
link, stat e open), mentre il descrittore di file contiene i puntatori alle funzioni che vengono
usate sui file già aperti.
4.2.2 Il funzionamento del Virtual File System
La funzione più importante implementata dal VFS è la system call open che permette di aprire
un file. Dato un pathname viene eseguita una ricerca dentro la directory entry cache (in breve
dcache), una tabella che contiene tutte le directory entry (in breve dentry) che permette di
associare in maniera rapida ed efficiente il pathname a una specifica dentry.
Una singola dentry contiene in genere il puntatore ad un inode; quest’ultimo è la struttura
base che sta sul disco e che identifica un singolo oggetto del VFS sia esso un file ordinario, una
directory, un link simbolico, una FIFO, un file di dispositivo, o una qualsiasi altra cosa che possa
essere rappresentata dal VFS (i tipi di file riportati in tab. 4.1). A ciascuno di essi è associata
pure una struttura che sta in memoria, e che, oltre alle informazioni sullo specifico file, contiene
anche il riferimento alle funzioni (i metodi del VFS) da usare per poterlo manipolare.
Le dentry “vivono” in memoria e non vengono mai salvate su disco, vengono usate per motivi
di velocità, gli inode invece stanno su disco e vengono copiati in memoria quando serve, ed ogni
cambiamento viene copiato all’indietro sul disco (aggiornando i cosiddetti metadati del file), gli
inode che stanno in memoria sono inode del VFS ed è ad essi che puntano le singole dentry.
La dcache costituisce perciò una sorta di vista completa di tutto l’albero dei file, ovviamente
per non riempire tutta la memoria questa vista è parziale (la dcache cioè contiene solo le dentry
per i file per i quali è stato richiesto l’accesso), quando si vuole risolvere un nuovo pathname il
VFS deve creare una nuova dentry e caricare l’inode corrispondente in memoria.
Questo procedimento viene eseguito dal metodo lookup() dell’inode della directory che
contiene il file; questo viene installato nelle relative strutture in memoria quando si effettua il
montaggio lo specifico filesystem su cui l’inode va a vivere.
Una volta che il VFS ha a disposizione la dentry (ed il relativo inode) diventa possibile
accedere alle varie operazioni sul file come la open per aprire il file o la stat per leggere i dati
dell’inode e passarli in user space.
L’apertura di un file richiede comunque un’altra operazione, l’allocazione di una struttura
di tipo file in cui viene inserito un puntatore alla dentry e una struttura f_ops che contiene i
puntatori ai metodi che implementano le operazioni disponibili sul file. In questo modo i processi
in user space possono accedere alle operazioni attraverso detti metodi, che saranno diversi a
seconda del tipo di file (o dispositivo) aperto (su questo torneremo in dettaglio in sez. 6.1.1). Un
elenco delle operazioni previste dal kernel è riportato in tab. 4.2.
In questo modo per ciascun file diventano possibili una serie di operazioni (non è detto che
tutte siano disponibili), che costituiscono l’interfaccia astratta del VFS. Qualora se ne voglia
eseguire una, il kernel andrà ad utilizzare l’opportuna funzione dichiarata in f_ops appropriata
al tipo di file in questione.
Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un normale file
di dati; ovviamente certe operazioni (nel caso della seriale ad esempio la seek) non saranno

Funzione Operazione
open Apre il file (vedi sez. 6.2.1).
read Legge dal file (vedi sez. 6.2.4).
write Scrive sul file (vedi sez. 6.2.5).
llseek Sposta la posizione corrente sul file (vedi sez. 6.2.3).
ioctl Accede alle operazioni di controllo (vedi sez. 6.3.7).
readdir Legge il contenuto di una directory (vedi sez. 5.1.6).
poll Usata nell’I/O multiplexing (vedi sez. 12.2).
mmap Mappa il file in memoria (vedi sez. 12.4.1).
release Chiamata quando l’ultimo riferimento a un file aperto è
chiuso.
fsync Sincronizza il contenuto del file (vedi sez. 6.3.3).
fasync Abilita l’I/O asincrono (vedi sez. 12.3.3) sul file.
Tabella 4.2: Operazioni sui file definite nel VFS.
disponibili, però con questo sistema l’utilizzo di diversi filesystem (come quelli usati da Windows
o MacOS) è immediato e (relativamente) trasparente per l’utente ed il programmatore.
4.2.3 Il funzionamento di un filesystem Unix
Come già accennato in sez. 4.1.1 Linux (ed ogni sistema unix-like) organizza i dati che tiene su
disco attraverso l’uso di un filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix
è quella di poter supportare, grazie al VFS, una enorme quantità di filesystem diversi, ognuno
dei quali ha una sua particolare struttura e funzionalità proprie. Per questo per il momento non
entreremo nei dettagli di un filesystem specifico, ma daremo una descrizione a grandi linee che
si adatta alle caratteristiche comuni di qualunque filesystem di sistema unix-like.
Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni partizione può conte-
nere un filesystem. La strutturazione tipica dell’informazione su un disco è riportata in fig. 4.2;
in essa si fa riferimento alla struttura del filesystem ext2, che prevede una separazione dei dati in
block group che replicano il superblock (ma sulle caratteristiche di ext2 e derivati torneremo in
sez. 4.2.4). È comunque caratteristica comune di tutti i filesystem per Unix, indipendentemente
da come poi viene strutturata nei dettagli questa informazione, prevedere una divisione fra la
lista degli inode e lo spazio a disposizione per i dati e le directory.
Figura 4.2: Organizzazione dello spazio su un disco in partizioni e filesystem.
Se si va ad esaminare con maggiore dettaglio la strutturazione dell’informazione all’interno
del singolo filesystem (tralasciando i dettagli relativi al funzionamento del filesystem stesso
come la strutturazione in gruppi dei blocchi, il superblock e tutti i dati di gestione) possiamo
esemplificare la situazione con uno schema come quello esposto in fig. 4.3.

Figura 4.3: Strutturazione dei dati all’interno di un filesystem.
Da fig. 4.3 si evidenziano alcune delle caratteristiche di base di un filesystem, sulle quali è
bene porre attenzione visto che sono fondamentali per capire il funzionamento delle funzioni che
manipolano i file e le directory che tratteremo nel prossimo capitolo; in particolare è opportuno
ricordare sempre che:
1. L’inode contiene tutte le informazioni (i cosiddetti metadati) riguardanti il file: il tipo di
file, i permessi di accesso, le dimensioni, i puntatori ai blocchi fisici che contengono i dati e
cos`ı via. Le informazioni che la funzione stat fornisce provengono dall’inode; dentro una
directory si troverà solo il nome del file e il numero dell’inode ad esso associato, cioè quella
che da qui in poi chiameremo una voce (come traduzione dell’inglese directory entry, che
non useremo anche per evitare confusione con le dentry del kernel di cui si parlava in
sez. 4.2.1).
2. Come mostrato in fig. 4.3 si possono avere più voci che puntano allo stesso inode. Ogni
inode ha un contatore che contiene il numero di riferimenti che sono stati fatti ad esso
(il cosiddetto link count); solo quando questo contatore si annulla i dati del file vengono
effettivamente rimossi dal disco. Per questo la funzione per cancellare un file si chiama
unlink, ed in realtà non cancella affatto i dati del file, ma si limita ad eliminare la relativa
voce da una directory e decrementare il numero di riferimenti nell’inode.
3. Il numero di inode nella voce si riferisce ad un inode nello stesso filesystem e non ci può
essere una directory che contiene riferimenti ad inode relativi ad altri filesystem. Questo
limita l’uso del comando ln (che crea una nuova voce per un file esistente con la funzione
link) al filesystem corrente.

4. Quando si cambia nome ad un file senza cambiare filesystem, il contenuto del file non viene
spostato fisicamente, viene semplicemente creata una nuova voce per l’inode in questione e
rimossa la vecchia (questa è la modalità in cui opera normalmente il comando mv attraverso
la funzione rename). Questa operazione non modifica minimamente neanche l’inode del file
dato che non si opera su questo ma sulla directory che lo contiene.
5. Gli inode dei file, che contengono i metadati ed i blocchi di spazio disco, che contengono
i dati, sono risorse indipendenti ed in genere vengono gestite come tali anche dai diversi
filesystem; è pertanto possibile sia esaurire lo spazio disco (caso più comune) che lo spazio
per gli inode, nel primo caso non sarà possibile allocare ulteriore spazio, ma si potranno
creare file (vuoti), nel secondo non si potranno creare nuovi file, ma si potranno estendere
quelli che ci sono.
Infine si noti che, essendo file pure loro, il numero di riferimenti esiste anche per le directory;
per cui, se a partire dalla situazione mostrata in fig. 4.3 creiamo una nuova directory img nella
directory gapil, avremo una situazione come quella in fig. 4.4, dove per chiarezza abbiamo
aggiunto dei numeri di inode.
Figura 4.4: Organizzazione dei link per le directory.
La nuova directory avrà allora un numero di riferimenti pari a due, in quanto è referenziata
dalla directory da cui si era partiti (in cui è inserita la nuova voce che fa riferimento a img) e
dalla voce “.” che è sempre inserita in ogni directory; questo vale sempre per ogni directory che
non contenga a sua volta altre directory. Al contempo, la directory da cui si era partiti avrà un
numero di riferimenti di almeno tre, in quanto adesso sarà referenziata anche dalla voce “..” di
img.
4.2.4 I filesystem di uso comune
Il filesystem standard più usato con Linux è il cosiddetto third extended filesystem, identificato
dalla sigla ext3.9 Esso nasce come evoluzione del precedente second extended filesystem, o ext2,
di cui eredita gran parte delle caratteristiche di base, per questo motivo parleremo anzitutto di
questo, dato che molto di quanto diremo si applica anche ad ext3. A partire dal kernel 2.6.XX
9
si fa riferimento al momento della stesura di questo paragrafo, l’inizio del 2010.

è stato dichiarato stabile il nuovo filsesystem ext4, ulteriore evoluzione di ext3 dotato di molte
caratteristiche avanzate, che sta iniziando a sostituirlo gradualmente.
Il filesystem ext2 nasce come filesystem nativo di Linux a partire dalle prime versioni del
kernel e supporta tutte le caratteristiche di un filesystem standard Unix: è in grado di gestire
nomi di file lunghi (256 caratteri, estensibili a 1012) e supporta una dimensione massima dei file
fino a 4 Tb. I successivi filesystem ext3 ed ext4 sono evoluzioni di questo filesystem, e sia pure
con molti miglioramenti ed estensioni significative ne mantengono in sostanza le caratteristiche
fondamentali.
Oltre alle caratteristiche standard, ext2 fornisce alcune estensioni che non sono presenti su
un classico filesystem di tipo Unix; le principali sono le seguenti:
• i file attributes consentono di modificare il comportamento del kernel quando agisce su
gruppi di file. Possono essere impostati su file e directory e in quest’ultimo caso i nuovi file
creati nella directory ereditano i suoi attributi.
• sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di montaggio. La
semantica BSD comporta che i file in una directory sono creati con lo stesso identificatore
di gruppo della directory che li contiene. La semantica SVr4 comporta che i file vengono
creati con l’identificatore del gruppo primario del processo, eccetto il caso in cui la directory
ha il bit di sgid impostato (per una descrizione dettagliata del significato di questi termini
si veda sez. 5.3), nel qual caso file e subdirectory ereditano sia il gid che lo sgid.
• l’amministratore può scegliere la dimensione dei blocchi del filesystem in fase di creazione,
a seconda delle sue esigenze (blocchi più grandi permettono un accesso più veloce, ma
sprecano più spazio disco).
• il filesystem implementa link simbolici veloci, in cui il nome del file non è salvato su un
blocco, ma tenuto all’interno dell’inode (evitando letture multiple e spreco di spazio), non
tutti i nomi però possono essere gestiti cos`ı per limiti di spazio (il limite è 60 caratteri).
• vengono supportati i file immutabili (che possono solo essere letti) per la protezione di file
di configurazione sensibili, o file append-only che possono essere aperti in scrittura solo per
aggiungere dati (caratteristica utilizzabile per la protezione dei file di log).
La struttura di ext2 è stata ispirata a quella del filesystem di BSD: un filesystem è composto
da un insieme di blocchi, la struttura generale è quella riportata in fig. 4.3, in cui la partizione
è divisa in gruppi di blocchi.10
Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del filesystem
(superblock e descrittore del filesystem sono quindi ridondati) per una maggiore affidabilità e
possibilità di recupero in caso di corruzione del superblock principale. L’utilizzo di raggruppa-
menti di blocchi ha inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la distanza
fra i dati e la tabella degli inode.
Le directory sono implementate come una linked list con voci di dimensione variabile. Cia-
scuna voce della lista contiene il numero di inode , la sua lunghezza, il nome del file e la sua
lunghezza, secondo lo schema in fig. 4.5; in questo modo è possibile implementare nomi per i file
anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio disco.
Con l’introduzione del filesystem ext3 sono state introdotte anche alcune modifiche strut-
turali, la principale di queste è quella che ext3 è un filesystem jounrnaled, è cioè in grado di
eseguire una registrazione delle operazioni di scrittura su un giornale (uno speciale file interno)
10
non si confonda questa definizione con quella riportata in fig. 5.2; in quel caso si fa riferimento alla struttura
usata in user space per riportare i dati contenuti in una directory generica, questa fa riferimento alla struttura
usata dal kernel per un filesystem ext2, definita nel file ext2_fs.h nella directory include/linux dei sorgenti del
kernel.

Figura 4.5: Struttura delle directory nel second extented filesystem.
in modo da poter garantire il ripristino della coerenza dei dati del filesystem11 in brevissimo
tempo in caso di interruzione improvvisa della corrente o di crollo del sistema che abbia causato
una interruzione della scrittura dei dati sul disco.
Oltre a questo ext3 introduce ulteriori modifiche volte a migliorare sia le prestazioni che la
semplicità di gestione del filesystem, in particolare per le directory si è passato all’uso di alberi
binari con indicizzazione tramite hash al posto delle linked list, ottenendo un forte guadagno di
prestazioni in caso di directory contenenti un gran numero di file.
11
si noti bene che si è parlato di dati del filesystem, non di dati nel filesystem, quello di cui viene garantito un
veloce ripristino è relativo ai dati della struttura interna del filesystem, non di eventuali dati contenuti nei file che
potrebbero essere stati persi.

Capitolo 5
File e directory
In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono file e directory, inizian-
do dalle funzioni di libreria che si usano per copiarli, spostarli e cambiarne i nomi. Esamineremo
poi l’interfaccia che permette la manipolazione dei vari attributi di file e directory ed alla fine
prenderemo in esame la struttura di base del sistema delle protezioni e del controllo dell’acces-
so ai file e le successive estensioni (Extended Attributes, ACL, quote disco, capabilities). Tutto
quello che riguarda invece la manipolazione del contenuto dei file è lasciato ai capitoli successivi.
5.1 La gestione di file e directory
Come già accennato in sez. 4.2.3 in un sistema unix-like la gestione dei file ha delle caratteristiche
specifiche che derivano direttamente dall’architettura del sistema. In questa sezione esamineremo
le funzioni usate per la manipolazione di file e directory, per la creazione di link simbolici e diretti,
per la gestione e la lettura delle directory.
In particolare ci soffermeremo sulle conseguenze che derivano dall’architettura dei filesystem
illustrata nel capitolo precedente per quanto riguarda il comportamento e gli effetti delle varie
funzioni.
5.1.1 Le funzioni link e unlink
Una caratteristica comune a diversi sistemi operativi è quella di poter creare dei nomi fittizi
(come gli alias del vecchio MacOS o i collegamenti di Windows o i nomi logici del VMS) che
permettono di fare riferimento allo stesso file chiamandolo con nomi diversi o accedendovi da
directory diverse.
Questo è possibile anche in ambiente Unix, dove tali collegamenti sono usualmente chiamati
link; ma data l’architettura del sistema riguardo la gestione dei file (ed in particolare quanto
trattato in sez. 4.2) ci sono due metodi sostanzialmente diversi per fare questa operazione.
Come spiegato in sez. 4.2.3 l’accesso al contenuto di un file su disco avviene passando attra-
verso il suo inode, che è la struttura usata dal kernel che lo identifica univocamente all’interno di
un singolo filesystem. Il nome del file che si trova nella voce di una directory è solo un’etichetta,
mantenuta all’interno della directory, che viene associata ad un puntatore che fa riferimento al
suddetto inode.
Questo significa che, fintanto che si resta sullo stesso filesystem, la realizzazione di un link
è immediata, ed uno stesso file può avere tanti nomi diversi, dati da altrettante associazioni
diverse allo stesso inode effettuate tramite “etichette” diverse in directory diverse. Si noti anche
che nessuno di questi nomi viene ad assumere una particolare preferenza o originalità rispetto
agli altri, in quanto tutti fanno comunque riferimento allo stesso inode.
109

110 CAPITOLO 5. FILE E DIRECTORY
Per aggiungere ad una directory una voce che faccia riferimento ad un inode già esistente si
utilizza la funzione link; si suole chiamare questo tipo di associazione un collegamento diretto,
o hard link. Il prototipo della funzione è il seguente:
#include <unistd.h>
int link(const char *oldpath, const char *newpath)
Crea un nuovo collegamento diretto.
La funzione restituisce 0 in caso di successo e -1 in caso di errore nel qual caso errno viene
impostata ai valori:
EXDEV i file oldpath e newpath non fanno riferimento ad un filesystem montato sullo stesso
mount point.
EPERM il filesystem che contiene oldpath e newpath non supporta i link diretti o è una
directory.
EEXIST un file (o una directory) di nome newpath esiste già.
EMLINK ci sono troppi link al file oldpath (il numero massimo è specificato dalla variabile
LINK_MAX, vedi sez. 8.1.1).
ed inoltre EACCES, ENAMETOOLONG, ENOTDIR, EFAULT, ENOMEM, EROFS, ELOOP, ENOSPC, EIO.
La funzione crea sul pathname newpath un collegamento diretto al file indicato da oldpath.
Per quanto detto la creazione di un nuovo collegamento diretto non copia il contenuto del file,
ma si limita a creare una voce nella directory specificata da newpath e ad aumentare di uno il
numero di riferimenti al file (riportato nel campo st_nlink della struttura stat, vedi sez. 5.2.1)
aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può essere cos`ı chiamato con
vari nomi in diverse directory.
Per quanto dicevamo in sez. 4.2.3 la creazione di un collegamento diretto è possibile solo se
entrambi i pathname sono nello stesso filesystem; inoltre il filesystem deve supportare i collega-
menti diretti (il meccanismo non è disponibile ad esempio con il filesystem vfat di Windows). In
realtà la funzione ha un ulteriore requisito, e cioè che non solo che i due file siano sullo stesso
filesystem, ma anche che si faccia riferimento ad essi sullo stesso mount point.1
La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del filesystem, con l’ec-
cezione delle directory. In alcune versioni di Unix solo l’amministratore è in grado di creare un
collegamento diretto ad un’altra directory: questo viene fatto perché con una tale operazione è
possibile creare dei loop nel filesystem (vedi l’esempio mostrato in sez. 5.1.3, dove riprenderemo
il discorso) che molti programmi non sono in grado di gestire e la cui rimozione diventerebbe
estremamente complicata (in genere per questo tipo di errori occorre far girare il programma
fsck per riparare il filesystem).
Data la pericolosità di questa operazione e la disponibilità dei link simbolici che possono
fornire la stessa funzionalità senza questi problemi, nel caso di Linux questa capacità è stata
completamente disabilitata, e al tentativo di creare un link diretto ad una directory la funzione
link restituisce l’errore EPERM.
Un ulteriore comportamento peculiare di Linux è quello in cui si crea un hard link ad un
link simbolico. In questo caso lo standard POSIX prevederebbe che quest’ultimo venga risolto e
che il collegamento sia effettuato rispetto al file cui esso punta, e che venga riportato un errore
qualora questo non esista o non sia un file. Questo era anche il comportamento iniziale di Linux
ma a partire dai kernel della serie 2.0.x2 è stato adottato un comportamento che non segue più
lo standard per cui l’hard link viene creato rispetto al link simbolico, e non al file cui questo
punta.
1
si tenga presente infatti (vedi sez. 8.2.2) che a partire dal kernel 2.4 uno stesso filesystem può essere montato
più volte su directory diverse.
2
per la precisione il comportamento era quello previsto dallo standard POSIX fino al kernel di sviluppo 1.3.56, ed
è stato temporaneamente ripristinato anche durante lo sviluppo della serie 2.1.x, per poi tornare al comportamento
attuale fino ad oggi (per riferimento si veda http://lwn.net/Articles/293902).

5.1. LA GESTIONE DI FILE E DIRECTORY 111
La ragione di questa differenza rispetto allo standard, presente anche in altri sistemi unix-
like, sono dovute al fatto che un link simbolico può fare riferimento anche ad un file non esistente
o a una directory, per i quali l’hard link non può essere creato, per cui la scelta di seguire il link
simbolico è stata ritenuta una scelta scorretta nella progettazione dell’interfaccia. Infatti se non
ci fosse il comportamento adottato da Linux sarebbe impossibile creare un hard link ad un link
simbolico, perché la funzione lo risolverebbe e l’hard link verrebbe creato verso la destinazione.
Invece evitando di seguire lo standard l’operazione diventa possibile, ed anche il comportamento
della funzione risulta molto più comprensibile. Tanto più che se proprio se si vuole creare un
hard link rispetto alla destinazione di un link simbolico è sempre possibile farlo direttamente.3
La rimozione di un file (o più precisamente della voce che lo referenzia all’interno di una
directory) si effettua con la funzione unlink; il suo prototipo è il seguente:
#include <unistd.h>
int unlink(const char *pathname)
Cancella un file.
La funzione restituisce zero in caso di successo e -1 per un errore, nel qual caso il file non viene
toccato. La variabile errno viene impostata secondo i seguenti codici di errore:
EISDIR pathname si riferisce ad una directory. 4
EROFS pathname è su un filesystem montato in sola lettura.
EISDIR pathname fa riferimento a una directory.
ed inoltre: EACCES, EFAULT, ENOENT, ENOTDIR, ENOMEM, EROFS, ELOOP, EIO.
La funzione cancella il nome specificato da pathname nella relativa directory e decrementa il
numero di riferimenti nel relativo inode. Nel caso di link simbolico cancella il link simbolico; nel
caso di socket, fifo o file di dispositivo rimuove il nome, ma come per i file i processi che hanno
aperto uno di questi oggetti possono continuare ad utilizzarlo.
Per cancellare una voce in una directory è necessario avere il permesso di scrittura su di essa,
dato che si va a rimuovere una voce dal suo contenuto, e il diritto di esecuzione sulla directory
che la contiene (affronteremo in dettaglio l’argomento dei permessi di file e directory in sez. 5.3).
Se inoltre lo sticky bit (vedi sez. 5.3.2) è impostato occorrerà anche essere proprietari del file o
proprietari della directory (o root, per cui nessuna delle restrizioni è applicata).
Una delle caratteristiche di queste funzioni è che la creazione/rimozione del nome dalla
directory e l’incremento/decremento del numero di riferimenti nell’inode devono essere effettuati
in maniera atomica (si veda sez. 3.6.1) senza possibili interruzioni fra le due operazioni. Per
questo entrambe queste funzioni sono realizzate tramite una singola system call.
Si ricordi infine che un file non viene eliminato dal disco fintanto che tutti i riferimenti ad
esso sono stati cancellati: solo quando il link count mantenuto nell’inode diventa zero lo spazio
occupato su disco viene rimosso (si ricordi comunque che a questo si aggiunge sempre un’ulteriore
condizione,5 e cioè che non ci siano processi che abbiano il suddetto file aperto).
Questa proprietà viene spesso usata per essere sicuri di non lasciare file temporanei su disco
in caso di crash dei programmi; la tecnica è quella di aprire il file e chiamare unlink subito dopo,
in questo modo il contenuto del file è sempre disponibile all’interno del processo attraverso il
suo file descriptor (vedi sez. 6.1.1) fintanto che il processo non chiude il file, ma non ne resta
3
ciò non toglie che questo comportamento fuori standard possa causare problemi, come nell’esempio descritto
nell’articolo citato nella nota precedente, a programmi che non si aspettano questa differenza rispetto allo standard
POSIX.
4
questo è un valore specifico ritornato da Linux che non consente l’uso di unlink con le directory (vedi
sez. 5.1.2). Non è conforme allo standard POSIX, che prescrive invece l’uso di EPERM in caso l’operazione non sia
consentita o il processo non abbia privilegi sufficienti.
5
come vedremo in cap. 6 il kernel mantiene anche una tabella dei file aperti nei vari processi, che a sua volta
contiene i riferimenti agli inode ad essi relativi. Prima di procedere alla cancellazione dello spazio occupato su
disco dal contenuto di un file il kernel controlla anche questa tabella, per verificare che anche in essa non ci sia
più nessun riferimento all’inode in questione.

traccia in nessuna directory, e lo spazio occupato su disco viene immediatamente rilasciato alla
conclusione del processo (quando tutti i file vengono chiusi).
5.1.2 Le funzioni remove e rename
Al contrario di quanto avviene con altri Unix, in Linux non è possibile usare unlink sulle
directory; per cancellare una directory si può usare la funzione rmdir (vedi sez. 5.1.4), oppure
la funzione remove.
Questa è la funzione prevista dallo standard ANSI C per cancellare un file o una directory
(e funziona anche per i sistemi che non supportano i link diretti). Per i file è identica a unlink
e per le directory è identica a rmdir; il suo prototipo è:
#include <stdio.h>
int remove(const char *pathname)
Cancella un nome dal filesystem.
toccato.
I codici di errore riportati in errno sono quelli della chiamata utilizzata, pertanto si può fare
riferimento a quanto illustrato nelle descrizioni di unlink e rmdir.
La funzione utilizza la funzione unlink6 per cancellare i file e la funzione rmdir per cancellare
le directory; si tenga presente che per alcune implementazioni del protocollo NFS utilizzare
questa funzione può comportare la scomparsa di file ancora in uso.
Per cambiare nome ad un file o a una directory (che devono comunque essere nello stesso
filesystem) si usa invece la funzione rename,7 il cui prototipo è:
#include <stdio.h>
int rename(const char *oldpath, const char *newpath)
Rinomina un file.
toccato. La variabile errno viene impostata secondo i seguenti codici di errore:
EISDIR newpath è una directory mentre oldpath non è una directory.
EXDEV oldpath e newpath non sono sullo stesso filesystem.
ENOTEMPTY newpath è una directory già esistente e non vuota.
EBUSY o oldpath o newpath sono in uso da parte di qualche processo (come directory di
lavoro o come radice) o del sistema (come mount point).
EINVAL newpath contiene un prefisso di oldpath o più in generale si è cercato di creare una
directory come sotto-directory di se stessa.
ENOTDIR uno dei componenti dei pathname non è una directory o oldpath è una directory e
newpath esiste e non è una directory.
ed inoltre EACCES, EPERM, EMLINK, ENOENT, ENOMEM, EROFS, ELOOP e ENOSPC.
La funzione rinomina il file oldpath in newpath, eseguendo se necessario lo spostamento di
un file fra directory diverse. Eventuali altri link diretti allo stesso file non vengono influenzati.
Il comportamento della funzione è diverso a seconda che si voglia rinominare un file o una
directory; se ci riferisce ad un file allora newpath, se esiste, non deve essere una directory (altri-
menti si ha l’errore EISDIR). Nel caso newpath indichi un file esistente questo viene cancellato e
rimpiazzato (atomicamente).
6
questo vale usando le glibc; nelle libc4 e nelle libc5 la funzione remove è un semplice alias alla funzione unlink
e quindi non può essere usata per le directory.
7
la funzione è definita dallo standard ANSI C, ma si applica solo per i file, lo standard POSIX estende la
funzione anche alle directory.

Se oldpath è una directory allora newpath, se esiste, deve essere una directory vuota, al-
trimenti si avranno gli errori ENOTDIR (se non è una directory) o ENOTEMPTY (se non è vuota).
Chiaramente newpath non può contenere oldpath altrimenti si avrà un errore EINVAL.
Se oldpath si riferisce ad un link simbolico questo sarà rinominato; se newpath è un link
simbolico verrà cancellato come qualunque altro file. Infine qualora oldpath e newpath siano
due nomi dello stesso file lo standard POSIX prevede che la funzione non dia errore, e non faccia
nulla, lasciando entrambi i nomi; Linux segue questo standard, anche se, come fatto notare dal
manuale delle glibc, il comportamento più ragionevole sarebbe quello di cancellare oldpath.
Il vantaggio nell’uso di questa funzione al posto della chiamata successiva di link e unlink
è che l’operazione è eseguita atomicamente, non può esistere cioè nessun istante in cui un altro
processo può trovare attivi entrambi i nomi dello stesso file, o, in caso di sostituzione di un file
esistente, non trovare quest’ultimo prima che la sostituzione sia stata eseguita.
In ogni caso se newpath esiste e l’operazione fallisce per un qualche motivo (come un crash
del kernel), rename garantisce di lasciare presente un’istanza di newpath. Tuttavia nella sovra-
scrittura potrà esistere una finestra in cui sia oldpath che newpath fanno riferimento allo stesso
file.
5.1.3 I link simbolici
Come abbiamo visto in sez. 5.1.1 la funzione link crea riferimenti agli inode, pertanto può
funzionare soltanto per file che risiedono sullo stesso filesystem e solo per un filesystem di tipo
Unix. Inoltre abbiamo visto che in Linux non è consentito eseguire un link diretto ad una
directory.
Per ovviare a queste limitazioni i sistemi Unix supportano un’altra forma di link (i cosiddetti
soft link o symbolic link), che sono, come avviene in altri sistemi operativi, dei file speciali che
contengono semplicemente il riferimento ad un altro file (o directory). In questo modo è possibile
effettuare link anche attraverso filesystem diversi, a file posti in filesystem che non supportano
i link diretti, a delle directory, ed anche a file che non esistono ancora.
Il sistema funziona in quanto i link simbolici sono riconosciuti come tali dal kernel8 per cui
alcune funzioni di libreria (come open o stat) quando ricevono come argomento un link simbolico
vengono automaticamente applicate al file da esso specificato. La funzione che permette di creare
un nuovo link simbolico è symlink, ed il suo prototipo è:
#include <unistd.h>
int symlink(const char *oldpath, const char *newpath)
Crea un nuovo link simbolico di nome newpath il cui contenuto è oldpath.
La funzione restituisce zero in caso di successo e -1 per un errore, nel qual caso la variabile errno
assumerà i valori:
EPERM il filesystem che contiene newpath non supporta i link simbolici.
ENOENT una componente di newpath non esiste o oldpath è una stringa vuota.
EEXIST esiste già un file newpath.
EROFS newpath è su un filesystem montato in sola lettura.
ed inoltre EFAULT, EACCES, ENAMETOOLONG, ENOTDIR, ENOMEM, ELOOP, ENOSPC e EIO.
Si tenga presente che la funzione non effettua nessun controllo sull’esistenza di un file di nome
oldpath, ma si limita ad inserire quella stringa nel link simbolico. Pertanto un link simbolico
può anche riferirsi ad un file che non esiste: in questo caso si ha quello che viene chiamato un
dangling link, letteralmente un link ciondolante.
8
è uno dei diversi tipi di file visti in tab. 4.1, contrassegnato come tale nell’inode, e riconoscibile dal valore del
campo st_mode della struttura stat (vedi sez. 5.2.1).

Come accennato i link simbolici sono risolti automaticamente dal kernel all’invocazione delle
varie system call; in tab. 5.1 si è riportato un elenco dei comportamenti delle varie funzioni di
libreria che operano sui file nei confronti della risoluzione dei link simbolici, specificando quali
seguono il link simbolico e quali invece possono operare direttamente sul suo contenuto.
Funzione Segue il link Non segue il link
access • –
chdir • –
chmod • –
chown – •
creat • –
exec • –
lchown • –
link9
– •
lstat – •
mkdir • –
mkfifo • –
mknod • –
open • –
opendir • –
pathconf • –
readlink – •
remove – •
rename – •
stat • –
truncate • –
unlink – •
Tabella 5.1: Uso dei link simbolici da parte di alcune funzioni.
Si noti che non si è specificato il comportamento delle funzioni che operano con i file de-
scriptor, in quanto la risoluzione del link simbolico viene in genere effettuata dalla funzione che
restituisce il file descriptor (normalmente la open, vedi sez. 6.2.1) e tutte le operazioni seguenti
fanno riferimento solo a quest’ultimo.
Dato che, come indicato in tab. 5.1, funzioni come la open seguono i link simbolici, occorrono
funzioni apposite per accedere alle informazioni del link invece che a quelle del file a cui esso fa
riferimento. Quando si vuole leggere il contenuto di un link simbolico si usa la funzione readlink,
#include <unistd.h>
int readlink(const char *path, char *buff, size_t size)
Legge il contenuto del link simbolico indicato da path nel buffer buff di dimensione size.
La funzione restituisce il numero di caratteri letti dentro buff o -1 per un errore, nel qual caso la
variabile errno assumerà i valori:
EINVAL path non è un link simbolico o size non è positiva.
ed inoltre ENOTDIR, ENAMETOOLONG, ENOENT, EACCES, ELOOP, EIO, EFAULT e ENOMEM.
La funzione apre il link simbolico, ne legge il contenuto, lo scrive nel buffer, e lo richiude.
Si tenga presente che la funzione non termina la stringa con un carattere nullo e la tronca alla
dimensione specificata da size per evitare di sovrascrivere oltre le dimensioni del buffer.
Un caso comune che si può avere con i link simbolici è la creazione dei cosiddetti loop. La
situazione è illustrata in fig. 5.1, che riporta la struttura della directory /boot. Come si vede si
è creato al suo interno un link simbolico che punta di nuovo a /boot.10
9
a partire dalla serie 2.0, e contrariamente a quanto indicato dallo standard POSIX, si veda quanto detto in
sez. 5.1.1.
10
il loop mostrato in fig. 5.1 è un usato per poter permettere a grub (un bootloader in grado di leggere di-

Figura 5.1: Esempio di loop nel filesystem creato con un link simbolico.
Questo può causare problemi per tutti quei programmi che effettuano la scansione di una di-
rectory senza tener conto dei link simbolici, ad esempio se lanciassimo un comando del tipo grep
-r linux *, il loop nella directory porterebbe il comando ad esaminare /boot, /boot/boot,
/boot/boot/boot e cos`ı via.
Per questo motivo il kernel e le librerie prevedono che nella risoluzione di un pathname
possano essere seguiti un numero limitato di link simbolici, il cui valore limite è specificato dalla
costante MAXSYMLINKS. Qualora questo limite venga superato viene generato un errore ed errno
viene impostata al valore ELOOP.
Un punto da tenere sempre presente è che, come abbiamo accennato, un link simbolico può
fare riferimento anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo
nella nostra directory con un link del tipo:
$ ln -s /tmp/tmp_file temporaneo
anche se /tmp/tmp_file non esiste. Questo può generare confusione, in quanto aprendo in
scrittura temporaneo verrà creato /tmp/tmp_file e scritto; ma accedendo in sola lettura a
temporaneo, ad esempio con cat, otterremmo:
$ cat temporaneo
cat: temporaneo: No such file or directory
con un errore che può sembrare sbagliato, dato che un’ispezione con ls ci mostrerebbe invece
l’esistenza di temporaneo.
rettamente da vari filesystem il file da lanciare come sistema operativo) di vedere i file contenuti nella directory
/boot con lo stesso pathname con cui verrebbero visti dal sistema operativo, anche se essi si trovano, come accade
spesso, su una partizione separata (che grub, all’avvio, vede come radice).

5.1.4 La creazione e la cancellazione delle directory
Benché in sostanza le directory non siano altro che dei file contenenti elenchi di nomi ed inode, non
è possibile trattarle come file ordinari e devono essere create direttamente dal kernel attraverso
una opportuna system call.11 La funzione usata per creare una directory è mkdir, ed il suo
prototipo è:
#include <sys/stat.h>
int mkdir(const char *dirname, mode_t mode)
Crea una nuova directory.
La funzione restituisce zero in caso di successo e -1 per un errore, nel qual caso errno assumerà i
valori:
EEXIST un file (o una directory) con quel nome esiste di già.
EACCES non c’è il permesso di scrittura per la directory in cui si vuole inserire la nuova
directory.
EMLINK la directory in cui si vuole creare la nuova directory contiene troppi file; sotto Linux
questo normalmente non avviene perché il filesystem standard consente la creazione di
un numero di file maggiore di quelli che possono essere contenuti nel disco, ma potendo
avere a che fare anche con filesystem di altri sistemi questo errore può presentarsi.
ENOSPC non c’è abbastanza spazio sul file system per creare la nuova directory o si è esaurita
la quota disco dell’utente.
ed inoltre anche EPERM, EFAULT, ENAMETOOLONG, ENOENT, ENOTDIR, ENOMEM, ELOOP, EROFS.
La funzione crea una nuova directory vuota, che contiene cioè solo le due voci standard
presenti in ogni directory (cioè “.” e “..”), con il nome indicato dall’argomento dirname. Il
nome può essere indicato sia come pathname assoluto che come pathname relativo.
I permessi di accesso (vedi sez. 5.3) con cui la directory viene creata sono specificati dal-
l’argomento mode, i cui possibili valori sono riportati in tab. 5.9; si tenga presente che questi
sono modificati dalla maschera di creazione dei file (si veda sez. 5.3.3). La titolarità della nuova
directory è impostata secondo quanto riportato in sez. 5.3.4.
La funzione che permette la cancellazione di una directory è invece rmdir, ed il suo prototipo
è:
int rmdir(const char *dirname)
Cancella una directory.
valori:
EPERM il filesystem non supporta la cancellazione di directory, oppure la directory che contiene
dirname ha lo sticky bit impostato e l’user-ID effettivo del processo non corrisponde
al proprietario della directory.
EACCES non c’è il permesso di scrittura per la directory che contiene la directory che si vuo-
le cancellare, o non c’è il permesso di attraversare (esecuzione) una delle directory
specificate in dirname.
EBUSY la directory specificata è la directory di lavoro o la radice di qualche processo.
ENOTEMPTY la directory non è vuota.
ed inoltre anche EFAULT, ENAMETOOLONG, ENOENT, ENOTDIR, ENOMEM, ELOOP, EROFS.
La funzione cancella la directory dirname, che deve essere vuota (la directory deve cioè
contenere soltanto le due voci standard “.” e “..”). Il nome può essere indicato con il pathname
assoluto o relativo.
11
questo è quello che permette anche, attraverso l’uso del VFS, l’utilizzo di diversi formati per la gestione dei
suddetti elenchi, dalle semplici liste a strutture complesse come alberi binari, hash, ecc. che consentono una ricerca
veloce quando il numero di file è molto grande.

La modalità con cui avviene la cancellazione è analoga a quella di unlink: fintanto che il
numero di link all’inode della directory non diventa nullo e nessun processo ha la directory
aperta lo spazio occupato su disco non viene rilasciato. Se un processo ha la directory aperta
la funzione rimuove il link all’inode e nel caso sia l’ultimo, pure le voci standard “.” e “..”, a
questo punto il kernel non consentirà di creare più nuovi file nella directory.
5.1.5 La creazione di file speciali
Finora abbiamo parlato esclusivamente di file, directory e link simbolici; in sez. 4.1.2 abbiamo
visto però che il sistema prevede pure degli altri tipi di file speciali, come i file di dispositivo, le
fifo ed i socket (questi ultimi sono un caso a parte, essendo associati anche alla comunicazione
via rete, per cui ci saranno trattati in dettaglio a partire da cap. 15).
La manipolazione delle caratteristiche di questi diversi tipi di file e la loro cancellazione può
essere effettuata con le stesse funzioni che operano sui file regolari; ma quando li si devono creare
sono necessarie delle funzioni apposite. La prima di queste funzioni è mknod, il cui prototipo è:
#include <fcntl.h>
#include <unistd.h>
int mknod(const char *pathname, mode_t mode, dev_t dev)
Crea un inode del tipo specificato sul filesystem.
valori:
EPERM non si hanno privilegi sufficienti a creare l’inode, o il filesystem su cui si è cercato di
creare pathname non supporta l’operazione.
EINVAL il valore di mode non indica un file, una fifo, un socket o un dispositivo.
EEXIST pathname esiste già o è un link simbolico.
ed inoltre anche EFAULT, EACCES, ENAMETOOLONG, ENOENT, ENOTDIR, ENOMEM, ELOOP, ENOSPC, EROFS.
La funzione, come suggerisce il nome, permette di creare un “nodo” sul filesystem, e viene
in genere utilizzata per creare i file di dispositivo, ma si può usare anche per creare file regolari.
L’argomento mode specifica sia il tipo di file che si vuole creare che i relativi permessi, secondo i
valori riportati in tab. 5.4, che vanno combinati con un OR binario. I permessi sono comunque
modificati nella maniera usuale dal valore di umask (si veda sez. 5.3.3).
Per il tipo di file può essere specificato solo uno fra i seguenti valori: S_IFREG per un file
regolare (che sarà creato vuoto), S_IFBLK per un dispositivo a blocchi, S_IFCHR per un dispositivo
a caratteri, S_IFSOCK per un socket e S_IFIFO per una fifo;12 un valore diverso comporterà
l’errore EINVAL.
Qualora si sia specificato in mode un file di dispositivo (vale a dire o S_IFBLK o S_IFCHR), il
valore di dev dovrà essere usato per indicare a quale dispositivo si fa riferimento, altrimenti il
suo valore verrà ignorato. Solo l’amministratore può creare un file di dispositivo usando questa
funzione (il processo deve avere la capability CAP_MKNOD), ma in Linux13 l’uso per la creazione
di un file ordinario, di una fifo o di un socket è consentito anche agli utenti normali.
I nuovi inode creati con mknod apparterranno al proprietario e al gruppo del processo che
li ha creati, a meno che non si sia attivato il bit sgid per la directory o sia stata attivata la
semantica BSD per il filesystem (si veda sez. 5.3.4) in cui si va a creare l’inode.
12
con Linux la funzione non può essere usata per creare directory o link simbolici, si dovranno usare le funzioni
mkdir e symlink a questo dedicate.
13
questo è un comportamento specifico di Linux, la funzione non è prevista dallo standard POSIX.1 originale,
mentre è presente in SVr4 e 4.4BSD, ma esistono differenze nei comportamenti e nei codici di errore, tanto che
questa è stata introdotta in POSIX.1-2001 con una nota che la definisce portabile solo quando viene usata per
creare delle fifo, ma comunque deprecata essendo utilizzabile a tale scopo la specifica mkfifo.

Nella creazione di un file di dispositivo occorre poi specificare correttamente il valore di dev;
questo infatti è di tipo dev_t, che è un tipo primitivo (vedi tab. 1.2) riservato per indicare
un numero di dispositivo; il kernel infatti identifica ciascun dispositivo con un valore numerico.
Originariamente questo era un intero a 16 bit diviso in due parti di 8 bit chiamate rispettivamente
major number e minor number, che sono poi i due numeri mostrati dal comando ls -l al posto
della dimensione quando lo si esegue su un file di dispositivo.
Il major number identifica una classe di dispositivi (ad esempio la seriale, o i dischi IDE)
e serve in sostanza per indicare al kernel quale è il modulo che gestisce quella classe di dispo-
sitivi; per identificare uno specifico dispositivo di quella classe (ad esempio una singola por-
ta seriale, o una partizione di un disco) si usa invece il minor number. L’elenco aggiornato
di questi numeri con le relative corrispondenze ai vari dispositivi può essere trovato nel file
Documentation/devices.txt allegato alla documentazione dei sorgenti del kernel.
Data la crescita nel numero di dispositivi supportati, ben presto il limite massimo di 256 si
è rivelato troppo basso, e nel passaggio dai kernel della serie 2.4 alla serie 2.6 è stata aumentata
a 32 bit la dimensione del tipo dev_t, con delle dimensioni passate a 12 bit per il major number
e 20 bit per il minor number. La transizione però ha anche comportato il passaggio di dev_t a
tipo opaco, e la necessità di specificare il numero tramite delle opportune macro, cos`ı da non
avere problemi di compatibilità con eventuali ulteriori estensioni.
Le macro sono definite nel file sys/sysmacros.h, che viene automaticamente incluso quando
si include sys/types.h; si possono pertanto ottenere i valori del major number e minor number
di un dispositivo rispettivamente con le macro major e minor:
int major(dev_t dev)
Restituisce il major number del dispositivo dev.
int minor(dev_t dev)
Restituisce il minor number del dispositivo dev.
mentre una volta che siano noti major number e minor number si potrà costruire il relativo
identificativo con la macro makedev:
dev_t minor(int major, int minor)
Restituisce l’identificativo di un dispositivo dati major number e minor number.
Infine con lo standard POSIX.1-2001 è stata introdotta una funzione specifica per creare una
fifo (tratteremo le fifo in in sez. 11.1.4); la funzione è mkfifo ed il suo prototipo è:
int mkfifo(const char *pathname, mode_t mode)
Crea una fifo.
valori EACCES, EEXIST, ENAMETOOLONG, ENOENT, ENOSPC, ENOTDIR e EROFS.
La funzione crea la fifo pathname con i permessi mode. Come per mknod il file pathname
non deve esistere (neanche come link simbolico); al solito i permessi specificati da mode vengono
modificati dal valore di umask.
5.1.6 Accesso alle directory
Benché le directory alla fine non siano altro che dei file che contengono delle liste di nomi ed
inode, per il ruolo che rivestono nella struttura del sistema, non possono essere trattate come
dei normali file di dati. Ad esempio, onde evitare inconsistenze all’interno del filesystem, solo
il kernel può scrivere il contenuto di una directory, e non può essere un processo a inserirvi
direttamente delle voci con le usuali funzioni di scrittura.

Ma se la scrittura e l’aggiornamento dei dati delle directory è compito del kernel, sono molte
le situazioni in cui i processi necessitano di poterne leggere il contenuto. Benché questo possa
essere fatto direttamente (vedremo in sez. 6.2.1 che è possibile aprire una directory come se
fosse un file, anche se solo in sola lettura) in generale il formato con cui esse sono scritte può
dipendere dal tipo di filesystem, tanto che, come riportato in tab. 4.2, il VFS del kernel prevede
una apposita funzione per la lettura delle directory.
Tutto questo si riflette nello standard POSIX14 che ha introdotto una apposita interfaccia per
la lettura delle directory, basata sui cosiddetti directory stream (chiamati cos`ı per l’analogia con
i file stream dell’interfaccia standard ANSI C di cap. 7). La prima funzione di questa interfaccia
è opendir, il cui prototipo è:
#include <dirent.h>
DIR * opendir(const char *dirname)
Apre un directory stream.
La funzione restituisce un puntatore al directory stream in caso di successo e NULL per un errore,
nel qual caso errno assumerà i valori EACCES, EMFILE, ENFILE, ENOENT, ENOMEM e ENOTDIR.
La funzione apre un directory stream per la directory dirname, ritornando il puntatore ad
un oggetto di tipo DIR (che è il tipo opaco usato dalle librerie per gestire i directory stream) da
usare per tutte le operazioni successive, la funzione inoltre posiziona lo stream sulla prima voce
contenuta nella directory.
Si tenga presente che comunque la funzione opera associando il directory stream ad un
opportuno file descriptor sottostante, sul quale vengono compiute le operazioni. Questo viene
sempre aperto impostando il flag di close-on-exec, cos`ı da evitare che resti aperto in caso di
esecuzione di un altro programma.
Nel caso in cui sia necessario conoscere il file descriptor associato ad un directory stream si
può usare la funzione dirfd,15 il cui prototipo è:
#include <dirent.h>
int dirfd(DIR * dir)
Restituisce il file descriptor associato ad un directory stream.
La funzione restituisce il file descriptor (un valore positivo) in caso di successo e -1 in caso di
errore.
La funzione restituisce il file descriptor associato al directory stream dir. Di solito si utilizza
questa funzione in abbinamento a funzioni che operano sui file descriptor, ad esempio si potrà
usare fstat per ottenere le proprietà della directory, o fchdir per spostare su di essa la directory
di lavoro (vedi sez. 5.1.7).
Viceversa se si è aperto un file descriptor corrispondente ad una directory è possibile asso-
ciarvi un directory stream con la funzione fdopendir,16 il cui prototipo è:
14
le funzioni erano presenti in SVr4 e 4.3BSD, la loro specifica è riportata in POSIX.1-2001.
15
questa funzione è una estensione introdotta con BSD 4.3-Reno ed è presente in Linux con le libc5 (a partire
dalla versione 5.1.2) e con le glibc ma non presente in POSIX fino alla revisione POSIX.1-2008, per questo per
poterla utilizzare fino alla versione 2.10 delle glibc era necessario definire le macro _BSD_SOURCE o _SVID_SOURCE,
dalla versione 2.10 si possono usare anche _POSIX_C_SOURCE >= 200809L o _XOPEN_SOURCE >= 700.
16
questa funzione è però disponibile solo a partire dalla versione 2.4 delle glibc, ed è stata introdotta nello
standard POSIX solo a partire dalla revisione POSIX.1-2008, prima della versione 2.10 delle glibc per poterla
utilizzare era necessario definire la macro _GNU_SOURCE, dalla versione 2.10 si possono usare anche _POSIX_C_SOURCE
>= 200809L o _XOPEN_SOURCE >= 700 .

#include <dirent.h>
DIR * fdopendir(int fd)
Associa un directory stream al file descriptor fd.
La funzione restituisce un puntatore al directory stream in caso di successo e NULL per un errore,
nel qual caso errno assumerà il valore EBADF.
La funzione è identica a opendir, ma ritorna un directory stream facendo riferimento ad un
file descriptor fd che deve essere stato aperto in precedenza; la funzione darà un errore qualora
questo non corrisponda ad una directory. L’uso di questa funzione permette di rispondere agli
stessi requisiti delle funzioni “at” che vedremo in sez. 6.3.5.
Una volta utilizzata il file descriptor verrà usato internamente dalle funzioni che operano
sul directory stream e non dovrà essere più utilizzato all’interno del proprio programma; in
particolare dovrà essere chiuso con closedir e non direttamente. Si tenga presente inoltre che
fdopendir non modifica lo stato di un eventuale flag di close-on-exec, che pertanto dovrà essere
impostato esplicitamente in fase di apertura del file descriptor.
Una volta che si sia aperto un directory stream la lettura del contenuto della directory viene
effettuata attraverso la funzione readdir; il suo prototipo è:
#include <dirent.h>
struct dirent *readdir(DIR *dir)
Legge una voce dal directory stream.
La funzione restituisce il puntatore alla struttura contenente i dati in caso di successo e NULL
altrimenti, in caso di directory stream non valido errno assumerà il valore EBADF, il valore NULL
viene restituito anche quando si raggiunge la fine dello stream.
La funzione legge la voce corrente nella directory, posizionandosi sulla voce successiva. Per-
tanto se si vuole leggere l’intero contenuto di una directory occorrerà ripetere l’esecuzione della
funzione fintanto che non si siano esaurite tutte le voci in essa presenti.
struct dirent {
ino_t d_ino; /* inode number */
off_t d_off; /* offset to the next dirent */
unsigned short int d_reclen; /* length of this record */
unsigned char d_type; /* type of file;
by all file system types */
char d_name [256]; /* filename */
};
Figura 5.2: La struttura dirent per la lettura delle informazioni dei file.
I dati vengono memorizzati in una struttura dirent, la cui definizione è riportata in fig. 5.2.17
La funzione restituisce il puntatore alla struttura; si tenga presente però che quest’ultima è
allocata staticamente, per cui viene sovrascritta tutte le volte che si ripete la lettura di una voce
sullo stesso directory stream.
Di questa funzione esiste anche una versione rientrante, readdir_r,18 che non usa una
struttura allocata staticamente, e può essere utilizzata anche con i thread, il suo prototipo è:
17
la definizione è quella usata da Linux, che si trova nel file /usr/include/bits/dirent.h, essa non contempla
la presenza del campo d_namlen che indica la lunghezza del nome del file.
18
per usarla è necessario definire una qualunque delle macro _POSIX_C_SOURCE >= 1, _XOPEN_SOURCE,
_BSD_SOURCE, _SVID_SOURCE, _POSIX_SOURCE.

#include <dirent.h>
int readdir_r(DIR *dir, struct dirent *entry, struct dirent **result)
Legge una voce dal directory stream.
La funzione restituisce 0 in caso di successo e -1 in caso di errore, gli errori sono gli stessi di
readdir.
La funzione restituisce in result (come value result argument) l’indirizzo dove sono stati
salvati i dati, che di norma corrisponde a quello della struttura precedentemente allocata e
specificata dall’argomento entry, anche se non è assicurato che la funzione usi lo spazio fornito
dall’utente.
I vari campi di dirent contengono le informazioni relative alle voci presenti nella directory;
sia BSD che SVr4 prevedono che siano sempre presenti il campo d_name,19 che contiene il nome
del file nella forma di una stringa terminata da uno zero,20 ed il campo d_ino, che contiene il
numero di inode cui il file è associato e corrisponde al campo st_ino di stat.
La presenza di ulteriori campi opzionali oltre i due citati è segnalata dalla definizione di
altrettante macro nella forma _DIRENT_HAVE_D_XXX dove XXX è il nome del relativo campo; nel
caso di Linux sono pertanto definite le macro _DIRENT_HAVE_D_TYPE, _DIRENT_HAVE_D_OFF e
_DIRENT_HAVE_D_RECLEN, mentre non è definita la macro _DIRENT_HAVE_D_NAMLEN.
Valore Tipo di file
DT_UNKNOWN Tipo sconosciuto.
DT_REG File normale.
DT_DIR Directory.
DT_LNK Link simbolico.
DT_FIFO Fifo.
DT_SOCK Socket.
DT_CHR Dispositivo a caratteri.
DT_BLK Dispositivo a blocchi.
Tabella 5.2: Costanti che indicano i vari tipi di file nel campo d_type della struttura dirent.
Per quanto riguarda il significato dei campi opzionali, il campo d_type indica il tipo di file
(se fifo, directory, link simbolico, ecc.), e consente di evitare una successiva chiamata a lstat
per determinarlo. I suoi possibili valori sono riportati in tab. 5.2. Si tenga presente che questo
valore è disponibile solo per i filesystem che ne supportano la restituzione (fra questi i più noti
sono btrfs, ext2, ext3, e ext4), per gli altri si otterrà sempre il valore DT_UNKNOWN.21
Per la conversione da e verso l’analogo valore mantenuto dentro il campo st_mode di stat
sono definite anche due macro di conversione, IFTODT e DTTOIF:
int IFTODT(mode_t MODE)
Converte il tipo di file dal formato di st_mode a quello di d_type.
mode_t DTTOIF(int DTYPE)
Converte il tipo di file dal formato di d_type a quello di st_mode.
Il campo d_off contiene invece la posizione della voce successiva della directory, mentre il
campo d_reclen la lunghezza totale della voce letta. Con questi due campi diventa possibile,
19
lo standard POSIX prevede invece solo la presenza del campo d_fileno, identico d_ino, che in Linux è definito
come alias di quest’ultimo; il campo d_name è considerato dipendente dall’implementazione.
20
lo standard POSIX non specifica una lunghezza, ma solo un limite NAME_MAX; in SVr4 la lunghezza del campo
è definita come NAME_MAX+1 che di norma porta al valore di 256 byte usato anche in Linux.
21
inoltre fino alla versione 2.1 delle glibc, pur essendo il campo d_type presente, il suo uso non era implementato,
e veniva restituito comunque il valore DT_UNKNOWN.

determinando la posizione delle varie voci, spostarsi all’interno dello stream usando la funzione
seekdir,22 il cui prototipo è:
#include <dirent.h>
void seekdir(DIR *dir, off_t offset)
Cambia la posizione all’interno di un directory stream.
La funzione non ritorna nulla e non segnala errori, è però necessario che il valore dell’ar-
gomento offset sia valido per lo stream dir; esso pertanto deve essere stato ottenuto o dal
valore di d_off di dirent o dal valore restituito dalla funzione telldir, che legge la posizione
corrente; il prototipo di quest’ultima è:23
#include <dirent.h>
long telldir(DIR *dir)
Ritorna la posizione corrente in un directory stream.
La funzione restituisce la posizione corrente nello stream (un numero positivo) in caso di successo,
e -1 altrimenti, nel qual caso errno assume solo il valore di EBADF, corrispondente ad un valore
errato per dir.
La sola funzione di posizionamento nello stream prevista originariamente dallo standard
POSIX è rewinddir, che riporta la posizione a quella iniziale; il suo prototipo è:
#include <dirent.h>
void rewinddir(DIR *dir)
Si posiziona all’inizio di un directory stream.
Una volta completate le operazioni si può chiudere il directory stream, ed il file descriptor ad
esso associato, con la funzione closedir, il cui prototipo è:
#include <dirent.h>
int closedir(DIR * dir)
Chiude un directory stream.
La funzione restituisce 0 in caso di successo e -1 altrimenti, nel qual caso errno assume il valore
EBADF.
A parte queste funzioni di base in BSD 4.3 venne introdotta un’altra funzione che permette
di eseguire una scansione completa, con tanto di ricerca ed ordinamento, del contenuto di una
directory; la funzione è scandir24 ed il suo prototipo è:
#include <dirent.h>
int scandir(const char *dir, struct dirent ***namelist, int(*filter)(const struct
dirent *), int(*compar)(const struct dirent **, const struct dirent **))
Esegue una scansione di un directory stream.
La funzione restituisce in caso di successo il numero di voci trovate, e -1 altrimenti.
Al solito, per la presenza fra gli argomenti di due puntatori a funzione, il prototipo non è
molto comprensibile; queste funzioni però sono quelle che controllano rispettivamente la selezione
di una voce (quella passata con l’argomento filter) e l’ordinamento di tutte le voci selezionate
(quella specificata dell’argomento compar).
22
sia questa funzione che telldir, sono estensioni prese da BSD, ed introdotte nello standard POSIX solo a
partire dalla revisione POSIX.1-2001, per poterle utilizzare deve essere definita una delle macro _XOPEN_SOURCE,
_BSD_SOURCE o _SVID_SOURCE.
23
prima delle glibc 2.1.1 la funzione restituiva un valore di tipo off_t, sostituito a partire dalla versione 2.1.2
da long per conformità a POSIX.1-2001.
24
in Linux questa funzione è stata introdotta fin dalle libc4 e richiede siano definite le macro _BSD_SOURCE o
_SVID_SOURCE.

La funzione legge tutte le voci della directory indicata dall’argomento dir, passando un
puntatore a ciascuna di esse (una struttura dirent) come argomento della funzione di selezione
specificata da filter; se questa ritorna un valore diverso da zero il puntatore viene inserito in
un vettore che viene allocato dinamicamente con malloc. Qualora si specifichi un valore NULL
per l’argomento filter non viene fatta nessuna selezione e si ottengono tutte le voci presenti.
Le voci selezionate possono essere riordinate tramite qsort, le modalità del riordinamento
possono essere personalizzate usando la funzione compar come criterio di ordinamento di qsort,
la funzione prende come argomenti le due strutture dirent da confrontare restituendo un valore
positivo, nullo o negativo per indicarne l’ordinamento; alla fine l’indirizzo della lista ordinata dei
puntatori alle strutture dirent viene restituito nell’argomento namelist.25
Per l’ordinamento, vale a dire come valori possibili per l’argomento compar sono disponibili
due funzioni predefinite, alphasort e versionsort, i cui prototipi sono:
#include <dirent.h>
int alphasort(const void *a, const void *b)
int versionsort(const void *a, const void *b)
Funzioni per l’ordinamento delle voci di directory stream.
Le funzioni restituiscono un valore minore, uguale o maggiore di zero qualora il primo argomento
sia rispettivamente minore, uguale o maggiore del secondo.
La funzione alphasort deriva da BSD ed è presente in Linux fin dalle libc426 e deve essere
specificata come argomento compar per ottenere un ordinamento alfabetico (secondo il valore
del campo d_name delle varie voci). Le glibc prevedono come estensione27 anche versionsort,
che ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui file10 viene
comunque dopo file4.)
Un semplice esempio dell’uso di queste funzioni è riportato in fig. 5.3, dove si è riportata la
sezione principale di un programma che, usando la funzione di scansione illustrata in fig. 5.4,
stampa i nomi dei file contenuti in una directory e la relativa dimensione (in sostanza una
versione semplificata del comando ls).
Il programma è estremamente semplice; in fig. 5.3 si è omessa la parte di gestione delle
opzioni (che prevede solo l’uso di una funzione per la stampa della sintassi, anch’essa omessa)
ma il codice completo potrà essere trovato coi sorgenti allegati nel file myls.c.
In sostanza tutto quello che fa il programma, dopo aver controllato (12-15) di avere almeno
un argomento (che indicherà la directory da esaminare) è chiamare (16) la funzione DirScan per
eseguire la scansione, usando la funzione do_ls (22-29) per fare tutto il lavoro.
Quest’ultima si limita (26) a chiamare stat sul file indicato dalla directory entry passata
come argomento (il cui nome è appunto direntry->d_name), memorizzando in una opportuna
struttura data i dati ad esso relativi, per poi provvedere (27) a stampare il nome del file e la
dimensione riportata in data.
Dato che la funzione verrà chiamata all’interno di DirScan per ogni voce presente questo è
sufficiente a stampare la lista completa dei file e delle relative dimensioni. Si noti infine come si
restituisca sempre 0 come valore di ritorno per indicare una esecuzione senza errori.
Tutto il grosso del lavoro è svolto dalla funzione DirScan, riportata in fig. 5.4. La funzione è
volutamente generica e permette di eseguire una funzione, passata come secondo argomento, su
tutte le voci di una directory. La funzione inizia con l’aprire (18-22) uno stream sulla directory
passata come primo argomento, stampando un messaggio in caso di errore.
25
la funzione alloca automaticamente la lista, e restituisce, come value result argument, l’indirizzo della stessa;
questo significa che namelist deve essere dichiarato come struct dirent **namelist ed alla funzione si deve
passare il suo indirizzo.
26
la versione delle libc4 e libc5 usa però come argomenti dei puntatori a delle strutture dirent; le glibc usano
il prototipo originario di BSD, mostrato anche nella definizione, che prevede puntatori a void.
27
le glibc, a partire dalla versione 2.1, effettuano anche l’ordinamento alfabetico tenendo conto delle varie
localizzazioni, usando strcoll al posto di strcmp.

1 #include <sys/types.h>
2 #include <sys/stat.h>
3 #include <dirent.h> /* directory */
5 #include <unistd.h>
6 /* computation function for DirScan */
7 int do_ls(struct dirent * direntry );
8 /* main body */
9 int main(int argc , char *argv [])
10 {
11 ...
12 if (( argc - optind) != 1) { /* There must be remaing parameters */
13 printf("Wrong number of arguments %dn", argc - optind );
14 usage ();
15 }
16 DirScan(argv [1], do_ls );
17 exit (0);
18 }
19 /*
20 * Routine to print file name and size inside DirScan
21 */
22 int do_ls(struct dirent * direntry)
23 {
24 struct stat data;
25
26 stat(direntry ->d_name , &data ); /* get stat data */
27 printf("File: %s t size: %dn", direntry ->d_name , data.st_size );
28 return 0;
29 }
Figura 5.3: Esempio di codice per eseguire la lista dei file contenuti in una directory.
Il passo successivo (23-24) è cambiare directory di lavoro (vedi sez. 5.1.7), usando in sequenza
le funzioni dirfd e fchdir (in realtà si sarebbe potuto usare direttamente chdir su dirname), in
modo che durante il successivo ciclo (26-30) sulle singole voci dello stream ci si trovi all’interno
della directory.28
Avendo usato lo stratagemma di fare eseguire tutte le manipolazioni necessarie alla funzione
passata come secondo argomento, il ciclo di scansione della directory è molto semplice; si legge
una voce alla volta (26) all’interno di una istruzione di while e fintanto che si riceve una voce
valida, cioè un puntatore diverso da NULL, si esegue (27) la funzione di elaborazione compare (che
nel nostro caso sarà do_ls), ritornando con un codice di errore (28) qualora questa presenti una
anomalia, identificata da un codice di ritorno negativo. Una volta terminato il ciclo la funzione
si conclude con la chiusura (32) dello stream29 e la restituzione (32) del codice di operazioni
concluse con successo.
28
questo è essenziale al funzionamento della funzione do_ls, e ad ogni funzione che debba usare il campo d_name,
in quanto i nomi dei file memorizzati all’interno di una struttura dirent sono sempre relativi alla directory in
questione, e senza questo posizionamento non si sarebbe potuto usare stat per ottenere le dimensioni.
29
nel nostro caso, uscendo subito dopo la chiamata, questo non servirebbe, in generale però l’operazione è ne-
cessaria, dato che la funzione può essere invocata molte volte all’interno dello stesso processo, per cui non chiudere
i directory stream comporterebbe un consumo progressivo di risorse, con conseguente rischio di esaurimento delle
stesse.

1 #include <sys/types.h>
2 #include <sys/stat.h>
3 #include <dirent.h> /* directory */
5 #include <unistd.h>
6
7 /*
8 * Function DirScan:
9 *
10 * Input: the directory name and a computation function
11 * Return: 0 if OK , -1 on errors
12 */
13 int DirScan(char * dirname , int(* compute )( struct dirent *))
14 {
15 DIR * dir;
16 struct dirent *direntry;
17
18 if ( (dir = opendir(dirname )) == NULL) { /* open directory */
19 printf("Opening %sn", dirname ); /* on error print messages */
20 perror("Cannot open directory"); /* and then return */
21 return -1;
22 }
23 fd = dirfd(dir); /* get file descriptor */
24 fchdir(fd); /* change directory */
25 /* loop on directory entries */
26 while ( (direntry = readdir(dir)) != NULL) { /* read entry */
27 if (compute(direntry )) { /* execute function on it */
28 return -1; /* on error return */
29 }
30 }
31 closedir(dir);
32 return 0;
33 }
Figura 5.4: Codice della funzione di scansione di una directory contenuta nel file DirScan.c.
5.1.7 La directory di lavoro
Come accennato in sez. 3.2.2 a ciascun processo è associata una directory nel filesystem,30 che
è chiamata directory corrente o directory di lavoro (in inglese current working directory). La
directory di lavoro è quella da cui si parte quando un pathname è espresso in forma relativa,
dove il “relativa” fa riferimento appunto a questa directory.
Quando un utente effettua il login, questa directory viene impostata alla home directory
del suo account. Il comando cd della shell consente di cambiarla a piacere, spostandosi da una
directory ad un’altra, il comando pwd la stampa sul terminale. Siccome la directory corrente
resta la stessa quando viene creato un processo figlio (vedi sez. 3.2.2), la directory corrente della
shell diventa anche la directory corrente di qualunque comando da essa lanciato.
Dato che è il kernel che tiene traccia per ciascun processo dell’inode della directory di lavo-
ro, per ottenerne il pathname occorre usare una apposita funzione di libreria, getcwd,31 il cui
prototipo è:
30
questa viene mantenuta all’interno dei dati della sua task_struct (vedi fig. 3.2), più precisamente nel campo
pwd della sotto-struttura fs_struct.
31
con Linux getcwd è una system call dalla versione 2.1.9, in precedenza il valore doveva essere ottenuto tramite
il filesystem /proc da /proc/self/cwd.

#include <unistd.h>
char *getcwd(char *buffer, size_t size)
Legge il pathname della directory di lavoro corrente.
La funzione restituisce il puntatore buffer se riesce, NULL se fallisce, in quest’ultimo caso la
variabile errno è impostata con i seguenti codici di errore:
EINVAL l’argomento size è zero e buffer non è nullo.
ERANGE l’argomento size è più piccolo della lunghezza del pathname.
EACCES manca il permesso di lettura o di ricerca su uno dei componenti del pathname (cioè
su una delle directory superiori alla corrente).
ENOENT la directory di lavoro è stata eliminata.
La funzione restituisce il pathname completo della directory di lavoro corrente nella stringa
puntata da buffer, che deve essere precedentemente allocata, per una dimensione massima di
size. Il buffer deve essere sufficientemente largo da poter contenere il pathname completo più
lo zero di terminazione della stringa. Qualora esso ecceda le dimensioni specificate con size la
funzione restituisce un errore.
Si può anche specificare un puntatore nullo come buffer,32 nel qual caso la stringa sarà
allocata automaticamente per una dimensione pari a size qualora questa sia diversa da zero, o
della lunghezza esatta del pathname altrimenti. In questo caso ci si deve ricordare di disallocare
la stringa una volta cessato il suo utilizzo.
Di questa funzione esiste una versione char *getwd(char *buffer) fatta per compatibilità
all’indietro con BSD, che non consente di specificare la dimensione del buffer; esso deve essere
allocato in precedenza ed avere una dimensione superiore a PATH_MAX (di solito 256 byte, vedi
sez. 8.1.1); il problema è che in Linux non esiste una dimensione superiore per un pathname,
per cui non è detto che il buffer sia sufficiente a contenere il nome del file, e questa è la ragione
principale per cui questa funzione è deprecata.
Un uso comune di getcwd è quello di salvare la directory di lavoro iniziale per poi potervi
tornare in un tempo successivo, un metodo alternativo più veloce, se non si è a corto di file
descriptor, è invece quello di aprire la directory corrente (vale a dire “.”) e tornarvi in seguito
con fchdir.
Una seconda usata per ottenere la directory di lavoro è char *get_current_dir_name(void)
che è sostanzialmente equivalente ad una getcwd(NULL, 0), con la sola differenza che essa ri-
torna il valore della variabile di ambiente PWD, che essendo costruita dalla shell può contenere un
pathname comprendente anche dei link simbolici. Usando getcwd infatti, essendo il pathname
ricavato risalendo all’indietro l’albero della directory, si perderebbe traccia di ogni passaggio
attraverso eventuali link simbolici.
Per cambiare la directory di lavoro si può usare la funzione chdir (equivalente del comando
di shell cd) il cui nome sta appunto per change directory, il suo prototipo è:
#include <unistd.h>
int chdir(const char *pathname)
Cambia la directory di lavoro in pathname.
La funzione restituisce 0 in caso di successo e -1 per un errore, nel qual caso errno assumerà i
valori:
ENOTDIR non si è specificata una directory.
EACCES manca il permesso di ricerca su uno dei componenti di path.
ed inoltre EFAULT, ENAMETOOLONG, ENOENT, ENOMEM, ELOOP e EIO.
ed ovviamente pathname deve indicare una directory per la quale si hanno i permessi di accesso.
Dato che anche le directory sono file, è possibile riferirsi ad esse anche tramite il file descriptor,
e non solo tramite il pathname, per fare questo si usa fchdir, il cui prototipo è:
32
questa è un’estensione allo standard POSIX.1, supportata da Linux e dalla glibc.

#include <unistd.h>
int fchdir(int fd)
Identica a chdir, ma usa il file descriptor fd invece del pathname.
La funzione restituisce zero in caso di successo e -1 per un errore, in caso di errore errno assumerà
i valori EBADF o EACCES.
anche in questo caso fd deve essere un file descriptor valido che fa riferimento ad una directory.
Inoltre l’unico errore di accesso possibile (tutti gli altri sarebbero occorsi all’apertura di fd), è
quello in cui il processo non ha il permesso di accesso alla directory specificata da fd.
5.1.8 I file temporanei
In molte occasioni è utile poter creare dei file temporanei; benché la cosa sembri semplice, in
realtà il problema è più sottile di quanto non appaia a prima vista. Infatti anche se sembrerebbe
banale generare un nome a caso e creare il file dopo aver controllato che questo non esista, nel
momento fra il controllo e la creazione si ha giusto lo spazio per una possibile race condition (si
ricordi quanto visto in sez. 3.6.2).
Le glibc provvedono varie funzioni per generare nomi di file temporanei, di cui si abbia
certezza di unicità al momento della generazione; storicamente la prima di queste funzioni create
a questo scopo era tmpnam,33 il cui prototipo è:
#include <stdio.h>
char *tmpnam(char *string)
Genera un nome univoco per un file temporaneo.
La funzione ritorna il puntatore alla stringa con il nome o NULL in caso di fallimento. Non sono
definiti errori.
La funzione restituisce il puntatore ad una stringa contente un nome di file valido e non
esistente al momento dell’invocazione; se si è passato come argomento string un puntatore non
nullo ad un buffer di caratteri questo deve essere di dimensione L_tmpnam ed il nome generato
vi verrà copiato automaticamente; altrimenti il nome sarà generato in un buffer statico interno
che verrà sovrascritto ad una chiamata successiva. Successive invocazioni della funzione conti-
nueranno a restituire nomi unici fino ad un massimo di TMP_MAX volte, limite oltre il quale il
comportamento è indefinito. Al nome viene automaticamente aggiunto come prefisso la directory
specificata dalla costante P_tmpdir.34
Di questa funzione esiste una versione rientrante, tmpnam_r, che non fa nulla quando si passa
NULL come argomento. Una funzione simile, tempnam, permette di specificare un prefisso per il
file esplicitamente, il suo prototipo è:
#include <stdio.h>
char *tempnam(const char *dir, const char *pfx)
La funzione ritorna il puntatore alla stringa con il nome o NULL in caso di fallimento, errno viene
impostata a ENOMEM qualora fallisca l’allocazione della stringa.
La funzione alloca con malloc la stringa in cui restituisce il nome, per cui è sempre rientrante,
occorre però ricordarsi di disallocare con free il puntatore che restituisce. L’argomento pfx
specifica un prefisso di massimo 5 caratteri per il nome provvisorio. La funzione assegna come
directory per il file temporaneo, verificando che esista e sia accessibile, la prima valida fra le
seguenti:
• La variabile di ambiente TMPDIR (non ha effetto se non è definita o se il programma
chiamante è suid o sgid, vedi sez. 5.3.2).
33
la funzione è stata deprecata nella revisione POSIX.1-2008 dello standard POSIX.
34
le costanti L_tmpnam, P_tmpdir e TMP_MAX sono definite in stdio.h.

• il valore dell’argomento dir (se diverso da NULL).
• Il valore della costante P_tmpdir.
• la directory /tmp.
In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile ottenere un
nome duplicato, nulla assicura che un altro processo non possa avere creato, fra l’ottenimento
del nome e l’apertura del file, un altro file con lo stesso nome; per questo motivo quando si usa
il nome ottenuto da una di queste funzioni occorre sempre aprire il nuovo file in modalità di
esclusione (cioè con l’opzione O_EXCL per i file descriptor o con il flag x per gli stream) che fa
fallire l’apertura in caso il file sia già esistente.
Per evitare di dovere effettuare a mano tutti questi controlli, lo standard POSIX definisce la
funzione tmpfile, che permette di ottenere in maniera sicura l’accesso ad un file temporaneo, il
suo prototipo è:
#include <stdio.h>
FILE *tmpfile(void)
Restituisce un file temporaneo aperto in lettura/scrittura.
La funzione ritorna il puntatore allo stream associato al file temporaneo in caso di successo e NULL
in caso di errore, nel qual caso errno assumerà i valori:
EEXIST non è stato possibile generare un nome univoco.
ed inoltre EFAULT, EMFILE, ENFILE, ENOSPC, EROFS e EACCES.
La funzione restituisce direttamente uno stream già aperto (in modalità r+b, si veda sez. 7.2.1)
e pronto per l’uso, che viene automaticamente cancellato alla sua chiusura o all’uscita dal pro-
gramma. Lo standard non specifica in quale directory verrà aperto il file, ma le glibc prima
tentano con P_tmpdir e poi con /tmp. Questa funzione è rientrante e non soffre di problemi di
race condition.
Alcune versioni meno recenti di Unix non supportano queste funzioni; in questo caso si
possono usare le vecchie funzioni mktemp e mkstemp che modificano una stringa di input che
serve da modello e che deve essere conclusa da 6 caratteri X che verranno sostituiti da un codice
unico. La prima delle due è analoga a tmpnam e genera un nome casuale, il suo prototipo è:
#include <stlib.h>
char *mktemp(char *template)
La funzione ritorna il puntatore template in caso di successo e NULL in caso di errore, nel qual
caso errno assumerà i valori:
EINVAL template non termina con XXXXXX.
La funzionane genera un nome univoco sostituendo le XXXXXX finali di template; dato che
template deve poter essere modificata dalla funzione non si può usare una stringa costante.
Tutte le avvertenze riguardo alle possibili race condition date per tmpnam continuano a valere;
inoltre in alcune vecchie implementazioni il valore usato per sostituire le XXXXXX viene formato
con il pid del processo più una lettera, il che mette a disposizione solo 26 possibilità diverse
per il nome del file, e rende il nome temporaneo facile da indovinare. Per tutti questi motivi la
funzione è deprecata e non dovrebbe mai essere usata.
La seconda funzione, mkstemp è sostanzialmente equivalente a tmpfile, ma restituisce un
file descriptor invece di un nome; il suo prototipo è:

5.2. LA MANIPOLAZIONE DELLE CARATTERISTICHE DEI FILE 129
#include <stlib.h>
int mkstemp(char *template)
Genera un file temporaneo.
La funzione ritorna il file descriptor in caso di successo e -1 in caso di errore, nel qual caso errno
assumerà i valori:
EEXIST non è riuscita a creare un file temporaneo, il contenuto di template è indefinito.
Come per mktemp anche in questo caso template non può essere una stringa costante. La
funzione apre un file in lettura/scrittura con la funzione open, usando l’opzione O_EXCL (si veda
sez. 6.2.1), in questo modo al ritorno della funzione si ha la certezza di essere stati i creatori del
file, i cui permessi (si veda sez. 5.3.1) sono impostati al valore 0600 (lettura e scrittura solo per
il proprietario).35 Di questa funzione esiste una variante mkostemp, introdotta specificamente
dalla glibc,36 il cui prototipo è:
#include <stlib.h>
int mkostemp(char *template, int flags)
Genera un file temporaneo.
La funzione ritorna il file descriptor in caso di successo e -1 in caso di errore, con gli stessi errori
di mkstemp.
la cui sola differenza è la presenza dell’ulteriore argomento flags che consente di specificare i
flag da passare ad open nell’apertura del file.
In OpenBSD è stata introdotta un’altra funzione simile alle precedenti, mkdtemp, che crea
invece una directory temporanea;37 il suo prototipo è:
#include <stlib.h>
char *mkdtemp(char *template)
Genera una directory temporanea.
La funzione ritorna il puntatore al nome della directory in caso successo e NULL in caso di errore,
nel qual caso errno assumerà i valori:
più gli altri eventuali codici di errore di mkdir.
La funzione genera una directory il cui nome è ottenuto sostituendo le XXXXXX finali di
template con permessi 0700 (al solito si veda cap. 6 per i dettagli); dato che la creazione della
directory è sempre esclusiva i precedenti problemi di race condition non si pongono.
5.2 La manipolazione delle caratteristiche dei file
Come spiegato in sez. 4.2.3 tutte le informazioni generali relative alle caratteristiche di ciascun
file, a partire dalle informazioni relative al controllo di accesso, sono mantenute nell’inode.
Vedremo in questa sezione come sia possibile leggere tutte queste informazioni usando la
funzione stat, che permette l’accesso a tutti i dati memorizzati nell’inode; esamineremo poi le
varie funzioni usate per manipolare tutte queste informazioni (eccetto quelle che riguardano la
gestione del controllo di accesso, trattate in in sez. 5.3).
35
questo è vero a partire dalle glibc 2.0.7, le versioni precedenti delle glibc e le vecchie libc5 e libc4 usavano il
valore 0666 che permetteva a chiunque di leggere e scrivere i contenuti del file.
36
la funzione è stata introdotta nella versione 2.7 delle librerie e richiede che sia definita la macro _GNU_SOURCE.
37
la funzione è stata introdotta nelle glibc a partire dalla versione 2.1.91 ed inserita nello standard POSIX.1-2008.

5.2.1 La lettura delle caratteristiche dei file
La lettura delle informazioni relative ai file è fatta attraverso la famiglia delle funzioni stat che
sono quelle che usa il comando ls per poter ottenere e mostrare tutti i dati relativi ad un file;
ne fanno parte le funzioni stat, fstat e lstat, i cui prototipi sono:
#include <unistd.h>
int stat(const char *file_name, struct stat *buf)
int lstat(const char *file_name, struct stat *buf)
int fstat(int filedes, struct stat *buf)
Legge le informazioni di un file.
Le funzioni restituiscono 0 in caso di successo e -1 per un errore, nel qual caso errno assumerà
uno dei valori: EBADF, ENOENT, ENOTDIR, ELOOP, EFAULT, EACCES, ENOMEM, ENAMETOOLONG.
La funzione stat legge le informazioni del file il cui pathname è specificato dalla stringa
puntata da file_name e le inserisce nel buffer puntato dall’argomento buf; la funzione lstat
è identica a stat eccetto che se file_name è un link simbolico vengono lette le informazioni
relative ad esso e non al file a cui fa riferimento. Infine fstat esegue la stessa operazione su un
file già aperto, specificato tramite il suo file descriptor filedes.
La struttura stat usata da queste funzioni è definita nell’header sys/stat.h e in generale
dipende dall’implementazione; la versione usata da Linux è mostrata in fig. 5.5, cos`ı come ri-
portata dalla pagina di manuale di stat; in realtà la definizione effettivamente usata nel kernel
dipende dall’architettura e ha altri campi riservati per estensioni come tempi dei file più precisi
(vedi sez. 5.2.4), o per il padding dei campi.
struct stat {
dev_t st_dev; /* device */
ino_t st_ino; /* inode */
mode_t st_mode; /* protection */
nlink_t st_nlink; /* number of hard links */
uid_t st_uid; /* user ID of owner */
gid_t st_gid; /* group ID of owner */
dev_t st_rdev; /* device type (if inode device) */
off_t st_size; /* total size , in bytes */
unsigned long st_blksize; /* blocksize for filesystem I/O */
unsigned long st_blocks; /* number of blocks allocated */
time_t st_atime; /* time of last access */
time_t st_mtime; /* time of last modification */
time_t st_ctime; /* time of last change */
};
Figura 5.5: La struttura stat per la lettura delle informazioni dei file.
Si noti come i vari membri della struttura siano specificati come tipi primitivi del sistema
(di quelli definiti in tab. 1.2, e dichiarati in sys/types.h).
5.2.2 I tipi di file
Come riportato in tab. 4.1 in Linux oltre ai file e alle directory esistono altri oggetti che possono
stare su un filesystem. Il tipo di file è ritornato dalla funzione stat come maschera binaria nel
campo st_mode (che contiene anche le informazioni relative ai permessi) di una struttura stat.
Dato che il valore numerico può variare a seconda delle implementazioni, lo standard POSIX
definisce un insieme di macro per verificare il tipo di file, queste vengono usate anche da Linux

che supporta pure le estensioni allo standard per i link simbolici e i socket definite da BSD;
l’elenco completo delle macro con cui è possibile estrarre l’informazione da st_mode è riportato
in tab. 5.3.
Macro Tipo del file
S_ISREG(m) file normale.
S_ISDIR(m) directory.
S_ISCHR(m) dispositivo a caratteri.
S_ISBLK(m) dispositivo a blocchi.
S_ISFIFO(m) fifo.
S_ISLNK(m) link simbolico.
S_ISSOCK(m) socket.
Tabella 5.3: Macro per i tipi di file (definite in sys/stat.h).
Oltre alle macro di tab. 5.3 è possibile usare direttamente il valore di st_mode per ricavare
il tipo di file controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
sys/stat.h sono definite le costanti numeriche riportate in tab. 5.4.
Il primo valore dell’elenco di tab. 5.4 è la maschera binaria che permette di estrarre i bit nei
quali viene memorizzato il tipo di file, i valori successivi sono le costanti corrispondenti ai singoli
bit, e possono essere usati per effettuare la selezione sul tipo di file voluto, con un’opportuna
combinazione.
Flag Valore Significato
S_IFMT 0170000 Maschera per i bit del tipo di file.
S_IFSOCK 0140000 Socket.
S_IFLNK 0120000 Link simbolico.
S_IFREG 0100000 File regolare.
S_IFBLK 0060000 Dispositivo a blocchi.
S_IFDIR 0040000 Directory.
S_IFCHR 0020000 Dispositivo a caratteri.
S_IFIFO 0010000 Fifo.
S_ISUID 0004000 Set UID bit .
S_ISGID 0002000 Set GID bit .
S_ISVTX 0001000 Sticky bit .
S_IRUSR 00400 Il proprietario ha permesso di lettura.
S_IWUSR 00200 Il proprietario ha permesso di scrittura.
S_IXUSR 00100 Il proprietario ha permesso di esecuzione.
S_IRGRP 00040 Il gruppo ha permesso di lettura.
S_IWGRP 00020 Il gruppo ha permesso di scrittura.
S_IXGRP 00010 Il gruppo ha permesso di esecuzione.
S_IROTH 00004 Gli altri hanno permesso di lettura.
S_IWOTH 00002 Gli altri hanno permesso di esecuzione.
S_IXOTH 00001 Gli altri hanno permesso di esecuzione.
Tabella 5.4: Costanti per l’identificazione dei vari bit che compongono il campo st_mode (definite in sys/stat.h).
Ad esempio se si volesse impostare una condizione che permetta di controllare se un file è
una directory o un file ordinario si potrebbe definire la macro di preprocessore:
#define IS_FILE_DIR(x) (((x) & S_IFMT) & (S_IFDIR | S_IFREG ))
in cui prima si estraggono da st_mode i bit relativi al tipo di file e poi si effettua il confronto
con la combinazione di tipi scelta.
5.2.3 Le dimensioni dei file
Il campo st_size di una struttura stat contiene la dimensione del file in byte, se si tratta di
un file regolare. Nel caso di un link simbolico la dimensione è quella del pathname che il link

stesso contiene; per le fifo questo campo è sempre nullo.
Il campo st_blocks definisce la lunghezza del file in blocchi di 512 byte. Il campo st_blksize
infine definisce la dimensione preferita per i trasferimenti sui file (che è la dimensione usata anche
dalle librerie del C per l’interfaccia degli stream); scrivere sul file a blocchi di dati di dimensione
inferiore sarebbe inefficiente.
Si tenga conto che la lunghezza del file riportata in st_size non è detto che corrisponda
all’occupazione dello spazio su disco per via della possibile esistenza dei cosiddetti holes (lette-
ralmente buchi) che si formano tutte le volte che si va a scrivere su un file dopo aver eseguito
uno spostamento oltre la sua fine (tratteremo in dettaglio l’argomento in sez. 6.2.3).
In questo caso si avranno risultati differenti a seconda del modo in cui si calcola la lunghezza
del file, ad esempio il comando du, (che riporta il numero di blocchi occupati) potrà dare una
dimensione inferiore, mentre se si legge dal file (ad esempio usando il comando wc -c), dato che
in tal caso per le parti non scritte vengono restituiti degli zeri, si avrà lo stesso risultato di ls.
Se è sempre possibile allargare un file, scrivendoci sopra od usando la funzione lseek per spo-
starsi oltre la sua fine, esistono anche casi in cui si può avere bisogno di effettuare un troncamento,
scartando i dati presenti al di là della dimensione scelta come nuova fine del file.
Un file può sempre essere troncato a zero aprendolo con il flag O_TRUNC, ma questo è un
caso particolare; per qualunque altra dimensione si possono usare le due funzioni truncate e
ftruncate, i cui prototipi sono:
#include <unistd.h>
int truncate(const char *file_name, off_t length)
int ftruncate(int fd, off_t length))
Troncano un file alla lunghezza length.
Le funzioni restituiscono zero in caso di successo e -1 per un errore, nel qual caso errno viene
impostata opportunamente; per ftruncate si hanno i valori:
EBADF fd non è un file descriptor.
EINVAL fd è un riferimento ad un socket, non a un file o non è aperto in scrittura.
per truncate si hanno:
EACCES il file non ha permesso di scrittura o non si ha il permesso di esecuzione una delle
directory del pathname.
ETXTBSY il file è un programma in esecuzione.
ed anche ENOTDIR, ENAMETOOLONG, ENOENT, EROFS, EIO, EFAULT, ELOOP.
Entrambe le funzioni fan s`ı che la dimensione del file sia troncata ad un valore massimo
specificato da length, e si distinguono solo per il fatto che il file viene indicato con il pathname
file_name per truncate e con il file descriptor fd per ftruncate; se il file è più lungo della
lunghezza specificata i dati in eccesso saranno perduti.
Il comportamento in caso di lunghezza inferiore non è specificato e dipende dall’implemen-
tazione: il file può essere lasciato invariato o esteso fino alla lunghezza scelta; nel caso di Linux
viene esteso con la creazione di un buco nel file e ad una lettura si otterranno degli zeri; si tenga
presente però che questo comportamento è supportato solo per filesystem nativi, ad esempio su
un filesystem non nativo come il VFAT di Windows questo non è possibile.
5.2.4 I tempi dei file
Il sistema mantiene per ciascun file tre tempi, questi sono registrati nell’inode insieme agli altri
attributi del file e possono essere letti tramite la funzione stat, che li restituisce attraverso tre
specifici campi della struttura stat di fig. 5.5. Il significato di detti tempi e dei relativi campi è
riportato nello schema in tab. 5.5, dove è anche riportato un esempio delle funzioni che effettuano
cambiamenti su di essi. Il valore è espresso nel cosiddetto calendar time, su cui torneremo in
dettaglio in sez. 8.4.

Membro Significato Funzione Opzione di ls
st_atime ultimo accesso ai dati del file read, utime -u
st_mtime ultima modifica ai dati del file write, utime default
st_ctime ultima modifica ai dati dell’inode chmod, utime -c
Tabella 5.5: I tre tempi associati a ciascun file.
Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di ultima modifica
(il modification time, st_mtime) e il tempo di ultimo cambiamento di stato (il change time,
st_ctime). Il primo infatti fa riferimento ad una modifica del contenuto di un file, mentre il
secondo ad una modifica dell’inode. Dato che esistono molte operazioni, come la funzione link
e altre che vedremo in seguito, che modificano solo le informazioni contenute nell’inode senza
toccare il contenuto del file, diventa necessario l’utilizzo di questo secondo tempo.
Il tempo di ultima modifica viene usato ad esempio da programmi come make per decidere
quali file necessitano di essere ricompilati o (talvolta insieme anche al tempo di cambiamento di
stato) per decidere quali file devono essere archiviati per il backup. Il tempo di ultimo accesso
viene di solito usato per identificare i file che non vengono più utilizzati per un certo lasso di
tempo. Ad esempio un programma come leafnode lo usa per cancellare gli articoli letti più
vecchi, mentre mutt lo usa per marcare i messaggi di posta che risultano letti. Il sistema non
tiene conto dell’ultimo accesso all’inode, pertanto funzioni come access o stat non hanno alcuna
influenza sui tre tempi. Il comando ls (quando usato con le opzioni -l o -t) mostra i tempi dei
file secondo lo schema riportato nell’ultima colonna di tab. 5.5.
L’aggiornamento del tempo di ultimo accesso è stato a lungo considerato un difetto pro-
gettuale di Unix, questo infatti comporta la necessità di effettuare un accesso in scrittura sul
disco anche in tutti i casi in cui questa informazione non interessa e sarebbe possibile avere un
semplice accesso in lettura sui dati bufferizzati. Questo comporta un ovvio costo sia in termini
di prestazioni, che di consumo di risorse come la batteria per i portatili, o cicli di riscrittura per
i dischi su memorie riscrivibili.
Per questo motivo, onde evitare di mantenere una informazione che nella maggior parte
dei casi non interessa, è sempre stato possibile disabilitare l’aggiornamento del tempo di ultimo
accesso con l’opzione di montaggio noatime. Dato però che questo può creare problemi a qualche
programma, in Linux è stata introdotta la opzione relatime che esegue l’aggiornamento soltanto
se il tempo di ultimo accesso è precedente al tempo di ultima modifica o cambiamento, cos`ı da
rendere evidente che vi è stato un accesso dopo la scrittura, ed evitando al contempo ulteriori
operazioni su disco negli accessi successivi. In questo modo l’informazione relativa al fatto che un
file sia stato letto resta disponibile, e ad esempio i programmi citati in precedenza continuano a
funzionare. Questa opzione, a partire dal kernel 2.6.30, è diventata il comportamento di default
e non deve più essere specificata esplicitamente.38
L’effetto delle varie funzioni di manipolazione dei file sui relativi tempi è illustrato in tab. 5.6,
facendo riferimento al comportamento classico per quanto riguarda st_atime. Si sono riportati
gli effetti sia per il file a cui si fa riferimento, sia per la directory che lo contiene; questi ultimi
possono essere capiti se si tiene conto di quanto già detto, e cioè che anche le directory sono
anch’esse file che contengono una lista di nomi, che il sistema tratta in maniera del tutto analoga
a tutti gli altri.
Per questo motivo tutte le volte che compiremo un’operazione su un file che comporta una
modifica del nome contenuto nella directory, andremo anche a scrivere sulla directory che lo
contiene cambiandone il tempo di modifica. Un esempio di questo tipo di operazione può essere
la cancellazione di un file, invece leggere o scrivere o cambiare i permessi di un file ha effetti solo
sui tempi di quest’ultimo.
38
si può comunque riottenere il vecchio comportamento usando la opzione di montaggio strictatime.

Funzione
File o directory del
riferimento
Directory contenente
il riferimento Note
(a) (m) (c) (a) (m) (c)
chmod, fchmod – – • – – –
chown, fchown – – • – – –
creat • • • – • • con O_CREATE
creat – • • – • • con O_TRUNC
exec • – – – – –
lchown – – • – – –
link – – • – • •
mkdir • • • – • •
mkfifo • • • – • •
open • • • – • • con O_CREATE
open – • • – – – con O_TRUNC
pipe • • • – – –
read • – – – – –
remove – – • – • • se esegue unlink
remove – – – – • • se esegue rmdir
rename – – • – • • per entrambi gli argomenti
rmdir – – – – • •
truncate, ftruncate – • • – – –
unlink – – • – • •
utime • • • – – –
write – • • – – –
Tabella 5.6: Prospetto dei cambiamenti effettuati sui tempi di ultimo accesso (a), ultima modifica (m) e ultimo
cambiamento (c) dalle varie funzioni operanti su file e directory.
Si noti infine come st_ctime non abbia nulla a che fare con il tempo di creazione del file,
usato in molti altri sistemi operativi, ma che in Unix non esiste. Per questo motivo quando si
copia un file, a meno di preservare esplicitamente i tempi (ad esempio con l’opzione -p di cp)
esso avrà sempre il tempo corrente come data di ultima modifica.
I tempi di ultimo accesso e modifica possono essere modificati esplicitamente usando la
funzione utime, il cui prototipo è:
#include <utime.h>
int utime(const char *filename, struct utimbuf *times)
Modifica i tempi di ultimo accesso e modifica di un file.
La funzione restituisce 0 in caso di successo e -1 in caso di errore, nel qual caso errno assumerà
uno dei valori:
EACCES non si ha il permesso di scrittura sul file.
EPERM non si è proprietari del file.
ed inoltre EROFS e ENOENT.
La funzione cambia i tempi di ultimo accesso e modifica del file specificato dall’argomento
filename, e richiede come secondo argomento il puntatore ad una struttura utimbuf, la cui
definizione è riportata in fig. 5.6, con i nuovi valori di detti tempi (rispettivamente nei campi
actime e modtime). Se si passa un puntatore nullo verrà impostato il tempo corrente.
struct utimbuf {
time_t actime; /* access time */
time_t modtime; /* modification time */
};
Figura 5.6: La struttura utimbuf, usata da utime per modificare i tempi dei file.

L’effetto della funzione e i privilegi necessari per eseguirla dipendono da cosa è l’argomento
times; se è NULL la funzione imposta il tempo corrente ed è sufficiente avere accesso in scrittura
al file; se invece si è specificato un valore la funzione avrà successo solo se si è proprietari del file
o si hanno i privilegi di amministratore.
Si tenga presente che non è comunque possibile specificare il tempo di cambiamento di stato
del file, che viene aggiornato direttamente dal kernel tutte le volte che si modifica l’inode (quindi
anche alla chiamata di utime). Questo serve anche come misura di sicurezza per evitare che si
possa modificare un file nascondendo completamente le proprie tracce. In realtà la cosa resta
possibile se si è in grado di accedere al file di dispositivo, scrivendo direttamente sul disco senza
passare attraverso il filesystem, ma ovviamente in questo modo la cosa è più complicata da
realizzare.
A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di tab. 5.5 è espressa
in secondi, è stata portata ai nanosecondi per la gran parte dei filesystem. La ulteriore in-
formazione può essere acceduta attraverso altri campi appositamente aggiunti alla struttura
stat. Se si sono definite le macro _BSD_SOURCE o _SVID_SOURCE questi sono st_atim.tv_nsec,
st_mtim.tv_nsec e st_ctim.tv_nsec se queste non sono definite, st_atimensec, st_mtimensec
e st_mtimensec. Qualora il supporto per questa maggior precisione sia assente questi campi
aggiuntivi saranno nulli.
Per la gestione di questi nuovi valori è stata definita una seconda funzione di modifica,
utimes, che consente di specificare tempi con maggior precisione; il suo prototipo è:
#include <sys/time.h>
int utimes(const char *filename, struct timeval times[2])
Modifica i tempi di ultimo accesso e modifica di un file.
uno dei valori:
EACCES non si ha il permesso di scrittura sul file.
EPERM non si è proprietari del file.
ed inoltre EROFS e ENOENT.
La funzione è del tutto analoga alla precedente utime ma usa come secondo argomento un
vettore di due strutture timeval, la cui definizione è riportata in fig. 5.7, che consentono di
indicare i tempi con una precisione del microsecondo. Il primo elemento di times indica il valore
per il tempo di ultimo accesso, il secondo quello per il tempo di ultima modifica. Se si indica
come secondo argomento un puntatore nullo di nuovo verrà utilizzato il tempo corrente.
struct timeval
{
time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* microseconds */
};
Figura 5.7: La struttura timeval usata per indicare valori di tempo con la precisione del microsecondo.
Oltre ad utimes su Linux sono presenti altre due funzioni,39 futimes e lutimes, che con-
sentono rispettivamente di effettuare la modifica utilizzando un file già aperto o di eseguirla
direttamente su un link simbolico. I relativi prototipi sono:
39
le due funzioni non sono definite in nessuno standard, ma sono presenti, oltre che su Linux, anche su BSD.

int futimes(int fd, const struct timeval tv[2])
Cambia i tempi di un file già aperto specificato tramite il file descriptor fd.
int lutimes(const char *filename, const struct timeval tv[2])
Cambia i tempi di filename anche se questo è un link simbolico.
Le funzioni restituiscono zero in caso di successo e −1 per un errore, nel qual caso errno assumerà
gli stessi valori di utimes, con in più per futimes:
ENOSYS il filesystem /proc non è accessibile.
Le due funzioni anno lo stesso comportamento di utimes e richiedono gli stessi privilegi
per poter operare, la differenza è che con futimes si può indicare il file su cui operare facendo
riferimento al relativo file descriptor mentre con lutimes nel caso in cui filename sia un link
simbolico saranno modificati i suoi tempi invece di quelli del file a cui esso punta.
Nonostante il kernel, come accennato, supporti risoluzioni dei tempi dei file fino al nanose-
condo, le funzioni fin qui esaminate non consentono di impostare valori con questa precisione.
Per questo sono state introdotte due nuove funzioni, futimens e utimensat, in grado di eseguire
questo compito; i rispettivi prototipi sono:
futimens(int fd, const struct timespec times[2])
Cambia i tempi di un file già aperto, specificato dal file descriptor fd.
int utimensat(int dirfd, const char *pathname, const struct timespec times[2],
int flags)
Cambia i tempi del file pathname.
Le funzioni restituiscono zero in caso di successo e −1 per un errore, nel qual caso errno assumerà
gli stessi valori di utimes, con in più per futimes:
ENOSYS il filesystem /proc non è accessibile.
Entrambe le funzioni utilizzano per indicare i valori dei tempi un vettore times di due
strutture timespec che permette di specificare un valore di tempo con una precisione fino al
nanosecondo, la cui definizione è riportata in fig. 5.8.
struct timespec {
time_t tv_sec; /* seconds */
long int tv_nsec; /* nanoseconds */
};
Figura 5.8: La struttura timespec usata per indicare valori di tempo con la precisione del nanosecondo.
Come per le precedenti funzioni il primo elemento di times indica il tempo di ultimo accesso
ed il secondo quello di ultima modifica, e se si usa il valore NULL verrà impostato il tempo corrente
sia per l’ultimo accesso che per l’ultima modifica. Nei singoli elementi di times si possono inoltre
utilizzare due valori speciali per il campo tv_nsec: con UTIME_NOW si richiede l’uso del tempo
corrente, mentre con UTIME_OMIT si richiede di non impostare il tempo. Si può cos`ı aggiornare
in maniera specifica soltanto uno fra il tempo di ultimo accesso e quello di ultima modifica.
Quando si usa uno di questi valori speciali per tv_nsec il corrispondente valore di tv_sec viene
ignorato.
Queste due funzioni sono una estensione definita in una recente revisione dello standard
POSIX (la POSIX.1-2008); sono state introdotte a partire dal kernel 2.6.22, e supportate dalle

5.3. IL CONTROLLO DI ACCESSO AI FILE 137
glibc a partire dalla versione 2.6.40 La prima è sostanzialmente una estensione di futimes che
consente di specificare i tempi con precisione maggiore, la seconda supporta invece, rispetto ad
utimes, una sintassi più complessa che, come vedremo in sez. 6.3.5 consente una indicazione
sicura dei pathname relativi specificando la directory da usare come riferimento in dirfd e la
possibilità di usare flags per indicare alla funzione di dereferenziare o meno i link simbolici;
si rimanda pertanto la spiegazione del significato degli argomenti aggiuntivi alla trattazione
generica delle varie funzioni che usano la stessa sintassi, effettuata in sez. 6.3.5.
5.3 Il controllo di accesso ai file
Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella del controllo di ac-
cesso ai file, che viene implementato per qualunque filesystem standard.41 In questa sezione ne
esamineremo i concetti essenziali e le funzioni usate per gestirne i vari aspetti.
5.3.1 I permessi per l’accesso ai file
Ad ogni file Linux associa sempre l’utente che ne è proprietario (il cosiddetto owner) ed un
gruppo di appartenenza, secondo il meccanismo degli identificatori di utente e gruppo (uid e
gid). Questi valori sono accessibili da programma tramite la funzione stat, e sono mantenuti
nei campi st_uid e st_gid della struttura stat (si veda sez. 5.2.1).42
Il controllo di accesso ai file segue un modello abbastanza semplice che prevede tre permessi
fondamentali strutturati su tre livelli di accesso. Esistono varie estensioni a questo modello,43
ma nella maggior parte dei casi il meccanismo standard è più che sufficiente a soddisfare tutte
le necessità più comuni. I tre permessi di base associati ad ogni file sono:
• il permesso di lettura (indicato con la lettera r, dall’inglese read).
• il permesso di scrittura (indicato con la lettera w, dall’inglese write).
• il permesso di esecuzione (indicato con la lettera x, dall’inglese execute).
mentre i tre livelli su cui sono divisi i privilegi sono:
• i privilegi per l’utente proprietario del file.
• i privilegi per un qualunque utente faccia parte del gruppo cui appartiene il file.
• i privilegi per tutti gli altri utenti.
L’insieme dei permessi viene espresso con un numero a 12 bit; di questi i nove meno signifi-
cativi sono usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed esecuzione
e sono applicati rispettivamente rispettivamente al proprietario, al gruppo, a tutti gli altri.
I restanti tre bit (noti come suid bit, sgid bit, e sticky bit) sono usati per indicare alcune
caratteristiche più complesse del meccanismo del controllo di accesso su cui torneremo in seguito
(in sez. 5.3.2); lo schema di allocazione dei bit è riportato in fig. 5.9.
40
in precedenza, a partire dal kernel 2.6.16, era stata introdotta la funzione futimesat seguendo una bozza della
revisione dello standard poi modificata, questa funzione, sostituita da utimensat, è stata dichiarata obsoleta, non
è supportata da nessuno standard e non deve essere più utilizzata: pertanto non la tratteremo.
41
per standard si intende che implementa le caratteristiche previste dallo standard POSIX; in Linux sono
disponibili anche una serie di altri filesystem, come quelli di Windows e del Mac, che non supportano queste
caratteristiche.
42
questo è vero solo per filesystem di tipo Unix, ad esempio non è vero per il filesystem vfat di Windows, che
non fornisce nessun supporto per l’accesso multiutente, e per il quale i permessi vengono assegnati in maniera
fissa con un opzione in fase di montaggio.
43
come le Access Control List che sono state aggiunte ai filesystem standard con opportune estensioni (vedi
sez. 5.4.2) per arrivare a meccanismi di controllo ancora più sofisticati come il mandatory access control di
SE-Linux.

Figura 5.9: Lo schema dei bit utilizzati per specificare i permessi di un file contenuti nel campo st_mode di stat.
Anche i permessi, come tutte le altre informazioni pertinenti al file, sono memorizzati nell’inode;
in particolare essi sono contenuti in alcuni bit del campo st_mode della struttura stat (si veda
di nuovo fig. 5.5).
In genere ci si riferisce ai tre livelli dei privilegi usando le lettere u (per user), g (per group)
e o (per other), inoltre se si vuole indicare tutti i raggruppamenti insieme si usa la lettera a (per
all). Si tenga ben presente questa distinzione dato che in certi casi, mutuando la terminologia in
uso nel VMS, si parla dei permessi base come di permessi per owner, group ed all, le cui iniziali
possono dar luogo a confusione. Le costanti che permettono di accedere al valore numerico di
questi bit nel campo st_mode sono riportate in tab. 5.7.
st_mode bit Significato
S_IRUSR user-read, l’utente può leggere.
S_IWUSR user-write, l’utente può scrivere.
S_IXUSR user-execute, l’utente può eseguire.
S_IRGRP group-read, il gruppo può leggere.
S_IWGRP group-write, il gruppo può scrivere.
S_IXGRP group-execute, il gruppo può eseguire.
S_IROTH other-read, tutti possono leggere.
S_IWOTH other-write, tutti possono scrivere.
S_IXOTH other-execute, tutti possono eseguire.
Tabella 5.7: I bit dei permessi di accesso ai file, come definiti in <sys/stat.h>
I permessi vengono usati in maniera diversa dalle varie funzioni, e a seconda che si riferiscano a
dei file, dei link simbolici o delle directory; qui ci limiteremo ad un riassunto delle regole generali,
entrando nei dettagli più avanti.
La prima regola è che per poter accedere ad un file attraverso il suo pathname occorre il
permesso di esecuzione in ciascuna delle directory che compongono il pathname; lo stesso vale
per aprire un file nella directory corrente (per la quale appunto serve il diritto di esecuzione).
Per una directory infatti il permesso di esecuzione significa che essa può essere attraversata
nella risoluzione del pathname, ed è distinto dal permesso di lettura che invece implica che si
può leggere il contenuto della directory.
Questo significa che se si ha il permesso di esecuzione senza permesso di lettura si potrà lo
stesso aprire un file in una directory (se si hanno i permessi opportuni per il medesimo) ma
non si potrà vederlo con ls (mentre per crearlo occorrerà anche il permesso di scrittura per la
directory).
Avere il permesso di lettura per un file consente di aprirlo con le opzioni (si veda quanto
riportato in tab. 6.2) di sola lettura o di lettura/scrittura e leggerne il contenuto. Avere il
permesso di scrittura consente di aprire un file in sola scrittura o lettura/scrittura e modificarne
il contenuto, lo stesso permesso è necessario per poter troncare il file.
Non si può creare un file fintanto che non si disponga del permesso di esecuzione e di quello
di scrittura per la directory di destinazione; gli stessi permessi occorrono per cancellare un file

da una directory (si ricordi che questo non implica necessariamente la rimozione del contenuto
del file dal disco), non è necessario nessun tipo di permesso per il file stesso (infatti esso non
viene toccato, viene solo modificato il contenuto della directory, rimuovendo la voce che ad esso
fa riferimento).
Per poter eseguire un file (che sia un programma compilato od uno script di shell, od un altro
tipo di file eseguibile riconosciuto dal kernel), occorre avere il permesso di esecuzione, inoltre
solo i file regolari possono essere eseguiti.
I permessi per un link simbolico sono ignorati, contano quelli del file a cui fa riferimento;
per questo in genere il comando ls riporta per un link simbolico tutti i permessi come concessi;
utente e gruppo a cui esso appartiene vengono pure ignorati quando il link viene risolto, vengono
controllati solo quando viene richiesta la rimozione del link e quest’ultimo è in una directory con
lo sticky bit impostato (si veda sez. 5.3.2).
La procedura con cui il kernel stabilisce se un processo possiede un certo permesso (di lettura,
scrittura o esecuzione) si basa sul confronto fra l’utente e il gruppo a cui il file appartiene (i
valori di st_uid e st_gid accennati in precedenza) e l’user-ID effettivo, il group-ID effettivo e
gli eventuali group-ID supplementari del processo.44
Per una spiegazione dettagliata degli identificatori associati ai processi si veda sez. 3.3; nor-
malmente, a parte quanto vedremo in sez. 5.3.2, l’user-ID effettivo e il group-ID effettivo corri-
spondono ai valori dell’uid e del gid dell’utente che ha lanciato il processo, mentre i group-ID
supplementari sono quelli dei gruppi cui l’utente appartiene.
I passi attraverso i quali viene stabilito se il processo possiede il diritto di accesso sono i
seguenti:
1. Se l’user-ID effettivo del processo è zero (corrispondente all’amministratore) l’accesso è
sempre garantito senza nessun ulteriore controllo. Per questo motivo root ha piena libertà
di accesso a tutti i file.
2. Se l’user-ID effettivo del processo è uguale all’uid del proprietario del file (nel qual caso si
dice che il processo è proprietario del file) allora:
• se il relativo45 bit dei permessi d’accesso dell’utente è impostato, l’accesso è consentito
• altrimenti l’accesso è negato
3. Se il group-ID effettivo del processo o uno dei group-ID supplementari dei processi corri-
spondono al gid del file allora:
• se il bit dei permessi d’accesso del gruppo è impostato, l’accesso è consentito,
• altrimenti l’accesso è negato
4. Se il bit dei permessi d’accesso per tutti gli altri è impostato, l’accesso è consentito,
altrimenti l’accesso è negato.
Si tenga presente che questi passi vengono eseguiti esattamente in quest’ordine. Questo vuol
dire che se un processo è il proprietario di un file, l’accesso è consentito o negato solo sulla base
dei permessi per l’utente; i permessi per il gruppo non vengono neanche controllati. Lo stesso
vale se il processo appartiene ad un gruppo appropriato, in questo caso i permessi per tutti gli
altri non vengono controllati.
44
in realtà Linux, per quanto riguarda l’accesso ai file, utilizza gli identificatori del gruppo filesystem (si ricordi
quanto esposto in sez. 3.3), ma essendo questi del tutto equivalenti ai primi, eccetto il caso in cui si voglia scrivere
un server NFS, ignoreremo questa differenza.
45
per relativo si intende il bit di user-read se il processo vuole accedere in lettura, quello di user-write per
l’accesso in scrittura, ecc.

5.3.2 I bit dei permessi speciali
Come si è accennato (in sez. 5.3.1) nei dodici bit del campo st_mode di stat che vengono
usati per il controllo di accesso oltre ai bit dei permessi veri e propri, ci sono altri tre bit che
vengono usati per indicare alcune proprietà speciali dei file. Due di questi sono i bit detti suid
(da set-user-ID bit) e sgid (da set-group-ID bit) che sono identificati dalle costanti S_ISUID e
S_ISGID.
Come spiegato in dettaglio in sez. 3.2.5, quando si lancia un programma il comportamento
normale del kernel è quello di impostare gli identificatori del gruppo effective del nuovo processo
al valore dei corrispondenti del gruppo real del processo corrente, che normalmente corrispondono
a quelli dell’utente con cui si è entrati nel sistema.
Se però il file del programma (che ovviamente deve essere eseguibile46) ha il bit suid im-
postato, il kernel assegnerà come user-ID effettivo al nuovo processo l’uid del proprietario del
file al posto dell’uid del processo originario. Avere il bit sgid impostato ha lo stesso effetto sul
group-ID effettivo del processo.
I bit suid e sgid vengono usati per permettere agli utenti normali di usare programmi che
richiedono privilegi speciali; l’esempio classico è il comando passwd che ha la necessità di modi-
ficare il file delle password, quest’ultimo ovviamente può essere scritto solo dall’amministratore,
ma non è necessario chiamare l’amministratore per cambiare la propria password. Infatti il co-
mando passwd appartiene a root ma ha il bit suid impostato per cui quando viene lanciato da
un utente normale parte con i privilegi di root.
Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe normalmente
l’utente che lo ha lanciato comporta vari rischi, e questo tipo di programmi devono essere scrit-
ti accuratamente per evitare che possano essere usati per guadagnare privilegi non consentiti
(l’argomento è affrontato in dettaglio in sez. 3.3).
La presenza dei bit suid e sgid su un file può essere rilevata con il comando ls -l, che
visualizza una lettera s al posto della x in corrispondenza dei permessi di utente o gruppo. La
stessa lettera s può essere usata nel comando chmod per impostare questi bit. Infine questi bit
possono essere controllati all’interno di st_mode con l’uso delle due costanti S_ISUID e S_IGID,
i cui valori sono riportati in tab. 5.4.
Gli stessi bit vengono ad assumere in significato completamente diverso per le directory,
normalmente infatti Linux usa la convenzione di SVr4 per indicare con questi bit l’uso della
semantica BSD nella creazione di nuovi file (si veda sez. 5.3.4 per una spiegazione dettagliata al
proposito).
Infine Linux utilizza il bit sgid per un’ulteriore estensione mutuata da SVr4. Il caso in cui
un file ha il bit sgid impostato senza che lo sia anche il corrispondente bit di esecuzione viene
utilizzato per attivare per quel file il mandatory locking (affronteremo questo argomento in
dettaglio più avanti, in sez. 12.1.5).
L’ultimo dei bit rimanenti, identificato dalla costante S_ISVTX, è in parte un rimasuglio
delle origini dei sistemi Unix. A quell’epoca infatti la memoria virtuale e l’accesso ai file erano
molto meno sofisticati e per ottenere la massima velocità possibile per i programmi usati più
comunemente si poteva impostare questo bit.
L’effetto di questo bit era che il segmento di testo del programma (si veda sez. 2.2.2 per i
dettagli) veniva scritto nella swap la prima volta che questo veniva lanciato, e vi permaneva fino
al riavvio della macchina (da questo il nome di sticky bit); essendo la swap un file continuo o
una partizione indicizzata direttamente si poteva risparmiare in tempo di caricamento rispetto
alla ricerca attraverso la struttura del filesystem. Lo sticky bit è indicato usando la lettera t al
posto della x nei permessi per gli altri.
46
per motivi di sicurezza il kernel ignora i bit suid e sgid per gli script eseguibili.

Ovviamente per evitare che gli utenti potessero intasare la swap solo l’amministratore era in
grado di impostare questo bit, che venne chiamato anche con il nome di saved text bit, da cui
deriva quello della costante. Le attuali implementazioni di memoria virtuale e filesystem rendono
sostanzialmente inutile questo procedimento.
Benché ormai non venga più utilizzato per i file, lo sticky bit ha invece assunto un uso
importante per le directory;47 in questo caso se tale bit è impostato un file potrà essere rimosso
dalla directory soltanto se l’utente ha il permesso di scrittura su di essa ed inoltre è vera una
delle seguenti condizioni:
• l’utente è proprietario del file
• l’utente è proprietario della directory
• l’utente è l’amministratore
un classico esempio di directory che ha questo bit impostato è /tmp, i permessi infatti di solito
sono i seguenti:
$ ls -ld /tmp
drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp
quindi con lo sticky bit bit impostato. In questo modo qualunque utente nel sistema può creare dei
file in questa directory (che, come suggerisce il nome, è normalmente utilizzata per la creazione
di file temporanei), ma solo l’utente che ha creato un certo file potrà cancellarlo o rinominarlo.
In questo modo si evita che un utente possa, più o meno consapevolmente, cancellare i file
temporanei creati degli altri utenti.
5.3.3 Le funzioni per la gestione dei permessi dei file
Come visto in sez. 5.3 il controllo di accesso ad un file viene fatto utilizzando l’user-ID ed il
group-ID effettivo del processo; ci sono casi però in cui si può voler effettuare il controllo con
l’user-ID reale ed il group-ID reale, vale a dire usando i valori di uid e gid relativi all’utente che
ha lanciato il programma, e che, come accennato in sez. 5.3.2 e spiegato in dettaglio in sez. 3.3,
non è detto siano uguali a quelli effettivi.
Per far questo si può usare la funzione access, il cui prototipo è:
#include <unistd.h>
int access(const char *pathname, int mode)
Verifica i permessi di accesso.
La funzione ritorna 0 se l’accesso è consentito, -1 se l’accesso non è consentito ed in caso di errore;
nel qual caso la variabile errno assumerà i valori:
EINVAL il valore di mode non è valido.
EACCES l’accesso al file non è consentito, o non si ha il permesso di attraversare una delle
directory di pathname.
EROFS si è richiesto l’accesso in scrittura per un file su un filesystem montato in sola lettura.
ed inoltre EFAULT, ENAMETOOLONG, ENOENT, ENOTDIR, ELOOP, EIO.
La funzione verifica i permessi di accesso, indicati da mode, per il file indicato da pathname. I
valori possibili per l’argomento mode sono esprimibili come combinazione delle costanti numeriche
riportate in tab. 5.8 (attraverso un OR binario delle stesse). I primi tre valori implicano anche
la verifica dell’esistenza del file, se si vuole verificare solo quest’ultima si può usare F_OK, o
anche direttamente stat. Nel caso in cui pathname si riferisca ad un link simbolico, questo viene
seguito ed il controllo è fatto sul file a cui esso fa riferimento.
47
lo sticky bit per le directory è un’estensione non definita nello standard POSIX, Linux però la supporta, cos`ı
come BSD e SVr4.

La funzione controlla solo i bit dei permessi di accesso, si ricordi che il fatto che una directory
abbia permesso di scrittura non significa che ci si possa scrivere come in un file, e il fatto che
un file abbia permesso di esecuzione non comporta che contenga un programma eseguibile. La
funzione ritorna zero solo se tutte i permessi controllati sono disponibili, in caso contrario (o di
errore) ritorna -1.
mode Significato
R_OK Verifica il permesso di lettura.
W_OK Verifica il permesso di scrittura.
X_OK Verifica il permesso di esecuzione.
F_OK Verifica l’esistenza del file.
Tabella 5.8: Valori possibile per l’argomento mode della funzione access.
Un esempio tipico per l’uso di questa funzione è quello di un processo che sta eseguendo un
programma coi privilegi di un altro utente (ad esempio attraverso l’uso del suid bit) che vuole
controllare se l’utente originale ha i permessi per accedere ad un certo file.
Del tutto analoghe a access sono le due funzioni euidaccess e eaccess che ripetono lo
stesso controllo usando però gli identificatori del gruppo effettivo, verificando quindi le effettive
capacità di accesso ad un file. Le funzioni hanno entrambe lo stesso prototipo48 che è del tutto
identico a quello di access. Prendono anche gli stessi valori e restituiscono gli stessi risultati e
gli stessi codici di errore.
Per cambiare i permessi di un file il sistema mette ad disposizione due funzioni chmod e
fchmod, che operano rispettivamente su un filename e su un file descriptor, i loro prototipi sono:
int chmod(const char *path, mode_t mode)
Cambia i permessi del file indicato da path al valore indicato da mode.
int fchmod(int fd, mode_t mode)
Analoga alla precedente, ma usa il file descriptor fd per indicare il file.
Le funzioni restituiscono zero in caso di successo e -1 per un errore, in caso di errore errno può
assumere i valori:
EPERM l’user-ID effettivo non corrisponde a quello del proprietario del file o non è zero.
EROFS il file è su un filesystem in sola lettura.
ed inoltre EIO; chmod restituisce anche EFAULT, ENAMETOOLONG, ENOENT, ENOMEM, ENOTDIR, EACCES,
ELOOP; fchmod anche EBADF.
Entrambe le funzioni utilizzano come secondo argomento mode, una variabile dell’apposito
tipo primitivo mode_t (vedi tab. 1.2) utilizzato per specificare i permessi sui file.
Le costanti con cui specificare i singoli bit di mode sono riportate in tab. 5.9. Il valore di mode
può essere ottenuto combinando fra loro con un OR binario le costanti simboliche relative ai vari
bit, o specificato direttamente, come per l’omonimo comando di shell, con un valore numerico
(la shell lo vuole in ottale, dato che i bit dei permessi sono divisibili in gruppi di tre), che si può
calcolare direttamente usando lo schema si utilizzo dei bit illustrato in fig. 5.9.
Ad esempio i permessi standard assegnati ai nuovi file (lettura e scrittura per il proprietario,
sola lettura per il gruppo e gli altri) sono corrispondenti al valore ottale 0644, un programma
invece avrebbe anche il bit di esecuzione attivo, con un valore di 0755, se si volesse attivare il
bit suid il valore da fornire sarebbe 4755.
Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha comunque
alcune limitazioni, previste per motivi di sicurezza. L’uso delle funzioni infatti è possibile solo se
48
in realtà eaccess è solo un sinonimo di euidaccess fornita per compatibilità con l’uso di questo nome in altri
sistemi.

mode Valore Significato
S_ISUID 04000 Set user ID .
S_ISGID 02000 Set group ID .
S_ISVTX 01000 Sticky bit .
S_IRWXU 00700 L’utente ha tutti i permessi.
S_IRUSR 00400 L’utente ha il permesso di lettura.
S_IWUSR 00200 L’utente ha il permesso di scrittura.
S_IXUSR 00100 L’utente ha il permesso di esecuzione.
S_IRWXG 00070 Il gruppo ha tutti i permessi.
S_IRGRP 00040 Il gruppo ha il permesso di lettura.
S_IWGRP 00020 Il gruppo ha il permesso di scrittura.
S_IXGRP 00010 Il gruppo ha il permesso di esecuzione.
S_IRWXO 00007 Gli altri hanno tutti i permessi.
S_IROTH 00004 Gli altri hanno il permesso di lettura.
S_IWOTH 00002 Gli altri hanno il permesso di scrittura.
S_IXOTH 00001 Gli altri hanno il permesso di esecuzione.
Tabella 5.9: Valori delle costanti usate per indicare i vari bit di mode utilizzato per impostare i permessi dei file.
l’user-ID effettivo del processo corrisponde a quello del proprietario del file o dell’amministratore,
altrimenti esse falliranno con un errore di EPERM.
Ma oltre a questa regola generale, di immediata comprensione, esistono delle limitazioni
ulteriori. Per questo motivo, anche se si è proprietari del file, non tutti i valori possibili di mode
sono permessi o hanno effetto; in particolare accade che:
1. siccome solo l’amministratore può impostare lo sticky bit, se l’user-ID effettivo del processo
non è zero esso viene automaticamente cancellato (senza notifica di errore) qualora sia stato
indicato in mode.
2. per quanto detto in sez. 5.3.4 riguardo la creazione dei nuovi file, si può avere il caso in cui il
file creato da un processo è assegnato ad un gruppo per il quale il processo non ha privilegi.
Per evitare che si possa assegnare il bit sgid ad un file appartenente ad un gruppo per cui
non si hanno diritti, questo viene automaticamente cancellato da mode (senza notifica di
errore) qualora il gruppo del file non corrisponda a quelli associati al processo (la cosa non
avviene quando l’user-ID effettivo del processo è zero).
Per alcuni filesystem49 è inoltre prevista un’ulteriore misura di sicurezza, volta a scongiurare
l’abuso dei bit suid e sgid; essa consiste nel cancellare automaticamente questi bit dai permessi
di un file qualora un processo che non appartenga all’amministratore50 effettui una scrittura. In
questo modo anche se un utente malizioso scopre un file suid su cui può scrivere, un’eventuale
modifica comporterà la perdita di questo privilegio.
Le funzioni chmod e fchmod ci permettono di modificare i permessi di un file, resta però il
problema di quali sono i permessi assegnati quando il file viene creato. Le funzioni dell’interfaccia
nativa di Unix, come vedremo in sez. 6.2.1, permettono di indicare esplicitamente i permessi di
creazione di un file, ma questo non è possibile per le funzioni dell’interfaccia standard ANSI C che
non prevede l’esistenza di utenti e gruppi, ed inoltre il problema si pone anche per l’interfaccia
nativa quando i permessi non vengono indicati esplicitamente.
Per le funzioni dell’interfaccia standard ANSI C l’unico riferimento possibile è quello della
modalità di apertura del nuovo file (lettura/scrittura o sola lettura), che però può fornire un
valore che è lo stesso per tutti e tre i permessi di sez. 5.3.1 (cioè 666 nel primo caso e 222
nel secondo). Per questo motivo il sistema associa ad ogni processo51 una maschera di bit, la
49
i filesystem più comuni (ext2, ext3, ext4, ReiserFS) supportano questa caratteristica, che è mutuata da BSD.
50
per la precisione un processo che non dispone della capacità CAP_FSETID, vedi sez. 5.4.4.
51
è infatti contenuta nel campo umask della struttura fs_struct, vedi fig. 3.2.

cosiddetta umask, che viene utilizzata per impedire che alcuni permessi possano essere assegnati
ai nuovi file in sede di creazione. I bit indicati nella maschera vengono infatti cancellati dai
permessi quando un nuovo file viene creato.52
La funzione che permette di impostare il valore di questa maschera di controllo è umask, ed
il suo prototipo è:
#include <stat.h>
mode_t umask(mode_t mask)
Imposta la maschera dei permessi dei bit al valore specificato da mask (di cui vengono presi
solo i 9 bit meno significativi).
La funzione ritorna il precedente valore della maschera. È una delle poche funzioni che non
restituisce codici di errore.
In genere si usa questa maschera per impostare un valore predefinito che escluda preventi-
vamente alcuni permessi (usualmente quello di scrittura per il gruppo e gli altri, corrispondente
ad un valore per mask pari a 022). In questo modo è possibile cancellare automaticamente i
permessi non voluti. Di norma questo valore viene impostato una volta per tutte al login a 022,
e gli utenti non hanno motivi per modificarlo.
5.3.4 La gestione della titolarità dei file
Vedremo in sez. 6.2 con quali funzioni si possono creare nuovi file, in tale occasione vedremo che
è possibile specificare in sede di creazione quali permessi applicare ad un file, però non si può
indicare a quale utente e gruppo esso deve appartenere. Lo stesso problema si presenta per la
creazione di nuove directory (procedimento descritto in sez. 5.1.4).
Lo standard POSIX prescrive che l’uid del nuovo file corrisponda all’user-ID effettivo del
processo che lo crea; per il gid invece prevede due diverse possibilità:
• il gid del file corrisponde al group-ID effettivo del processo.
• il gid del file corrisponde al gid della directory in cui esso è creato.
in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata semantica BSD.
Linux invece segue quella che viene chiamata semantica SVr4; di norma cioè il nuovo file viene
creato, seguendo la prima opzione, con il gid del processo, se però la directory in cui viene creato
il file ha il bit sgid impostato allora viene usata la seconda opzione.
Usare la semantica BSD ha il vantaggio che il gid viene sempre automaticamente propagato,
restando coerente a quello della directory di partenza, in tutte le sotto-directory.
La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso risultato di
coerenza che si ha con BSD necessita che quando si creano nuove directory venga anche propagato
anche il bit sgid. Questo è il comportamento predefinito del comando mkdir, ed è in questo modo
ad esempio che le varie distribuzioni assicurano che le sotto-directory create nella home di un
utente restino sempre con il gid del gruppo primario dello stesso.
La presenza del bit sgid è inoltre molto comoda quando si hanno directory contenenti file
condivisi all’intero di un gruppo in cui possono scrivere tutti i membri dello stesso, dato che
assicura che i file che gli utenti vi creano appartengano sempre allo stesso gruppo. Questo non
risolve però completamente i problemi di accesso da parte di altri utenti dello stesso gruppo, in
quanto i permessi assegnati al gruppo potrebbero non essere sufficienti; in tal caso si deve aver
cura di usare un valore di umask che ne lasci di sufficienti.53
52
l’operazione viene fatta sempre: anche qualora si indichi esplicitamente un valore dei permessi nelle funzioni
di creazione che lo consentono, i permessi contenuti nella umask verranno tolti.
53
in tal caso si può assegnare agli utenti del gruppo una umask di 002, anche se la soluzione migliore in questo
caso è usare una ACL di default (vedi sez. 5.4.2).

Come avviene nel caso dei permessi il sistema fornisce anche delle funzioni, chown, fchown e
lchown, che permettono di cambiare sia l’utente che il gruppo a cui un file appartiene; i rispettivi
prototipi sono:
int chown(const char *path, uid_t owner, gid_t group)
int fchown(int fd, uid_t owner, gid_t group)
int lchown(const char *path, uid_t owner, gid_t group)
Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori specificati dalle
variabili owner e group.
Le funzioni restituiscono 0 in caso di successo e -1 per un errore, nel qual caso caso errno assumerà
i valori:
EPERM l’user-ID effettivo non corrisponde a quello del proprietario del file o non è zero, o
utente e gruppo non sono validi
Oltre a questi entrambe restituiscono gli errori EROFS e EIO; chown restituisce anche EFAULT,
ENAMETOOLONG, ENOENT, ENOMEM, ENOTDIR, EACCES, ELOOP; fchown anche EBADF.
Con Linux solo l’amministratore54 può cambiare il proprietario di un file; in questo viene
seguita la semantica usata da BSD che non consente agli utenti di assegnare i loro file ad altri
utenti evitando eventuali aggiramenti delle quote. L’amministratore può cambiare sempre il
gruppo di un file, il proprietario può cambiare il gruppo solo dei file che gli appartengono e solo
se il nuovo gruppo è il suo gruppo primario o uno dei gruppi di cui fa parte.
La funzione chown segue i link simbolici, per operare direttamente su un link simbolico si
deve usare la funzione lchown.55 La funzione fchown opera su un file aperto, essa è mutuata da
BSD, ma non è nello standard POSIX. Un’altra estensione rispetto allo standard POSIX è che
specificando -1 come valore per owner e group i valori restano immutati.
Quando queste funzioni sono chiamate con successo da un processo senza i privilegi di root
entrambi i bit suid e sgid vengono cancellati. Questo non avviene per il bit sgid nel caso in cui
esso sia usato (in assenza del corrispondente permesso di esecuzione) per indicare che per il file
è attivo il mandatory locking (vedi sez. 12.1.5).
5.3.5 Un quadro d’insieme sui permessi
Avendo affrontato in maniera separata il comportamento delle varie funzioni che operano sui
permessi dei file ed avendo trattato in sezioni diverse il significato dei singoli bit dei permessi,
vale la pena di fare un riepilogo in cui si riassumano le caratteristiche di ciascuno di essi, in
modo da poter fornire un quadro d’insieme.
Nella parte superiore di tab. 5.10 si è riassunto il significato dei vari bit dei permessi per un
file ordinario; per quanto riguarda l’applicazione dei permessi per proprietario, gruppo ed altri
si ricordi quanto illustrato in sez. 5.3.1. Per compattezza, nella tabella si sono specificati i bit
di suid, sgid e sticky con la notazione illustrata anche in fig. 5.9. Nella parte inferiore si sono
invece riassunti i significati dei vari bit dei permessi per una directory; anche in questo caso si
è riapplicato ai bit di suid, sgid e sticky la notazione illustrata in fig. 5.9.
Si ricordi infine che i permessi non hanno alcun significato per i link simbolici, mentre per
i file di dispositivo hanno senso soltanto i permessi di lettura e scrittura, che si riflettono sulla
possibilità di compiere dette operazioni sul dispositivo stesso.
Nella tabella si è indicato con il carattere “-” il fatto che il valore del bit in questione non
è influente rispetto a quanto indicato nella riga della tabella; la descrizione del significato fa
54
o in generale un processo con la capacità CAP_CHOWN, vedi sez. 5.4.4.
55
fino alla versione 2.1.81 in Linux chown non seguiva i link simbolici, da allora questo comportamento è stato
assegnato alla funzione lchown, introdotta per l’occasione, ed è stata creata una nuova system call per chown che
seguisse i link simbolici.

special user group other
Significato per i file
s s t r w x r w x r w x
1 - - - - - - - - - - - Se eseguito ha i permessi del proprietario.
- 1 - - - 1 - - - - - - Se eseguito ha i permessi del gruppo proprietario.
- 1 - - - 0 - - - - - - Il mandatory locking è abilitato.
- - 1 - - - - - - - - - Non utilizzato.
- - - 1 - - - - - - - - Permesso di lettura per il proprietario.
- - - - 1 - - - - - - - Permesso di scrittura per il proprietario.
- - - - - 1 - - - - - - Permesso di esecuzione per il proprietario.
- - - - - - 1 - - - - - Permesso di lettura per il gruppo proprietario.
- - - - - - - 1 - - - - Permesso di scrittura per il gruppo proprietario.
- - - - - - - - 1 - - - Permesso di esecuzione per il gruppo proprietario.
- - - - - - - - - 1 - - Permesso di lettura per tutti gli altri.
- - - - - - - - - - 1 - Permesso di scrittura per tutti gli altri.
- - - - - - - - - - - 1 Permesso di esecuzione per tutti gli altri.
special user group other
Significato per le directory
s s t r w x r w x r w x
1 - - - - - - - - - - - Non utilizzato.
- 1 - - - - - - - - - - Propaga il gruppo proprietario ai nuovi file creati.
- - 1 - - - - - - - - - Limita l’accesso in scrittura dei file nella directory.
- - - 1 - - - - - - - - Permesso di visualizzazione per il proprietario.
- - - - 1 - - - - - - - Permesso di aggiornamento per il proprietario.
- - - - - 1 - - - - - - Permesso di attraversamento per il proprietario.
- - - - - - 1 - - - - - Permesso di visualizzazione per il gruppo proprietario.
- - - - - - - 1 - - - - Permesso di aggiornamento per il gruppo proprietario.
- - - - - - - - 1 - - - Permesso di attraversamento per il gruppo proprietario.
- - - - - - - - - 1 - - Permesso di visualizzazione per tutti gli altri.
- - - - - - - - - - 1 - Permesso di aggiornamento per tutti gli altri.
- - - - - - - - - - - 1 Permesso di attraversamento per tutti gli altri.
Tabella 5.10: Tabella riassuntiva del significato dei bit dei permessi per un file e directory.
riferimento soltanto alla combinazione di bit per i quali è stato riportato esplicitamente un
valore. Si rammenti infine che il valore dei bit dei permessi non ha alcun effetto qualora il
processo possieda i privilegi di amministratore.
5.4 Caratteristiche e funzionalità avanzate
Tratteremo qui alcune caratteristiche e funzionalità avanzate della gestione di file e directory,
affrontando anche una serie di estensioni dell’interfaccia classica dei sistemi unix-like, princi-
palmente utilizzate a scopi di sicurezza, che sono state introdotte nelle versioni più recenti di
Linux.
5.4.1 Gli attributi estesi
Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni che il sistema man-
tiene negli inode, e le varie funzioni che permettono di modificarle. Si sarà notato come in realtà
queste informazioni siano estremamente ridotte. Questo è dovuto al fatto che Unix origina ne-
gli anni ’70, quando le risorse di calcolo e di spazio disco erano minime. Con il venir meno di
queste restrizioni è incominciata ad emergere l’esigenza di poter associare ai file delle ulteriori
informazioni astratte (quelli che vengono chiamati i meta-dati) che però non potevano trovare
spazio nei dati classici mantenuti negli inode.
Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche Linux) hanno in-
trodotto un meccanismo generico, detto Extended Attributes che consenta di associare delle

5.4. CARATTERISTICHE E FUNZIONALITÀ AVANZATE 147
informazioni ai singoli file.56 Gli attributi estesi non sono altro che delle coppie nome/valore
che sono associate permanentemente ad un oggetto sul filesystem, analoghi di quello che sono le
variabili di ambiente (vedi sez. 2.3.3) per un processo.
Altri sistemi (come Solaris, MacOS e Windows) hanno adottato un meccanismo diverso in
cui ad un file sono associati diversi flussi di dati, su cui possono essere mantenute ulteriori
informazioni, che possono essere accedute con le normali operazioni di lettura e scrittura. Questi
non vanno confusi con gli Extended Attributes (anche se su Solaris hanno lo stesso nome), che
sono un meccanismo molto più semplice, che pur essendo limitato (potendo contenere solo una
quantità limitata di informazione) hanno il grande vantaggio di essere molto più semplici da
realizzare, più efficienti,57 e di garantire l’atomicità di tutte le operazioni.
In Linux gli attributi estesi sono sempre associati al singolo inode e l’accesso viene sempre
eseguito in forma atomica, in lettura il valore corrente viene scritto su un buffer in memoria,
mentre la scrittura prevede che ogni valore precedente sia sovrascritto.
Si tenga presente che non tutti i filesystem supportano gli Extended Attributes; al momento
della scrittura di queste dispense essi sono presenti solo sui vari extN, ReiserFS, JFS, XFS e
Btrfs.58 Inoltre a seconda della implementazione ci possono essere dei limiti sulla quantità di
attributi che si possono utilizzare.59 Infine lo spazio utilizzato per mantenere gli attributi estesi
viene tenuto in conto per il calcolo delle quote di utente e gruppo proprietari del file.
Come meccanismo per mantenere informazioni aggiuntive associate al singolo file, gli Exten-
ded Attributes possono avere usi anche molto diversi fra loro. Per poterli distinguere allora sono
stati suddivisi in classi, a cui poter applicare requisiti diversi per l’accesso e la gestione. Per questo
motivo il nome di un attributo deve essere sempre specificato nella forma namespace.attribute,
dove namespace fa riferimento alla classe a cui l’attributo appartiene, mentre attribute è il
nome ad esso assegnato. In tale forma il nome di un attributo esteso deve essere univoco. Al
momento60 sono state definite le quattro classi di attributi riportate in tab. 5.11.
Nome Descrizione
security Gli extended security attributes: vengono utilizzati dalle estensioni di sicurezza del ker-
nel (i Linux Security Modules), per le realizzazione di meccanismi evoluti di controllo
di accesso come SELinux o le capabilities dei file di sez. 5.4.4.
system Gli extended security attributes: sono usati dal kernel per memorizzare dati di sistema
associati ai file come le ACL (vedi sez. 5.4.2) o le capabilities (vedi sez. 5.4.4).
trusted I trusted extended attributes: vengono utilizzati per poter realizzare in user space
meccanismi che consentano di mantenere delle informazioni sui file che non devono
essere accessibili ai processi ordinari.
user Gli extended user attributes: utilizzati per mantenere informazioni aggiuntive sui file
(come il mime-type, la codifica dei caratteri o del file) accessibili dagli utenti.
Tabella 5.11: I nomi utilizzati valore di namespace per distinguere le varie classi di Extended Attributes.
Dato che uno degli usi degli Extended Attributes è quello che li impiega per realizzare delle
estensioni (come le ACL, SELinux, ecc.) al tradizionale meccanismo dei controlli di accesso di
Unix, l’accesso ai loro valori viene regolato in maniera diversa a seconda sia della loro classe sia
di quali, fra le estensioni che li utilizzano, sono poste in uso. In particolare, per ciascuna delle
classi riportate in tab. 5.11, si hanno i seguenti casi:
56
l’uso più comune è quello della ACL, che tratteremo nella prossima sezione.
57
cosa molto importante, specie per le applicazioni che richiedono una gran numero di accessi, come le ACL.
58
l’elenco è aggiornato a Luglio 2011.
59
ad esempio nel caso di ext2 ed ext3 è richiesto che essi siano contenuti all’interno di un singolo blocco (pertanto
con dimensioni massime pari a 1024, 2048 o 4096 byte a seconda delle dimensioni di quest’ultimo impostate in fase
di creazione del filesystem), mentre con XFS non ci sono limiti ed i dati vengono memorizzati in maniera diversa
(nell’inode stesso, in un blocco a parte, o in una struttura ad albero dedicata) per mantenerne la scalabilità.
60
della scrittura di questa sezione, kernel 2.6.23, ottobre 2007.

security L’accesso agli extended security attributes dipende dalle politiche di sicurezza stabilite
da loro stessi tramite l’utilizzo di un sistema di controllo basato sui Linux Security
Modules (ad esempio SELinux). Pertanto l’accesso in lettura o scrittura dipende
dalle politiche di sicurezza implementate all’interno dal modulo di sicurezza che si
sta utilizzando al momento (ciascuno avrà le sue). Se non è stato caricato nessun
modulo di sicurezza l’accesso in lettura sarà consentito a tutti i processi, mentre
quello in scrittura solo ai processi con privilegi amministrativi dotati della capability
CAP_SYS_ADMIN.
system Anche l’accesso agli extended system attributes dipende dalle politiche di accesso che
il kernel realizza anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel
caso delle ACL l’accesso è consentito in lettura ai processi che hanno la capacità
di eseguire una ricerca sul file (cioè hanno il permesso di lettura sulla directory che
contiene il file) ed in scrittura al proprietario del file o ai processi dotati della capability
CAP_FOWNER.61
trusted L’accesso ai trusted extended attributes, sia per la lettura che per la scrittura, è
consentito soltanto ai processi con privilegi amministrativi dotati della capability
CAP_SYS_ADMIN. In questo modo si possono utilizzare questi attributi per realizzare
in user space dei meccanismi di controllo che accedono ad informazioni non disponibili
ai processi ordinari.
user L’accesso agli extended user attributes è regolato dai normali permessi dei file: occorre
avere il permesso di lettura per leggerli e quello di scrittura per scriverli o modificarli.
Dato l’uso di questi attributi si è scelto di applicare al loro accesso gli stessi criteri che
si usano per l’accesso al contenuto dei file (o delle directory) cui essi fanno riferimento.
Questa scelta vale però soltanto per i file e le directory ordinarie, se valesse in generale
infatti si avrebbe un serio problema di sicurezza dato che esistono diversi oggetti sul
filesystem per i quali è normale avere avere il permesso di scrittura consentito a tutti
gli utenti, come i link simbolici, o alcuni file di dispositivo come /dev/null. Se fosse
possibile usare su di essi gli extended user attributes un utente qualunque potrebbe
inserirvi dati a piacere.62
La semantica del controllo di accesso indicata inoltre non avrebbe alcun senso al di
fuori di file e directory: i permessi di lettura e scrittura per un file di dispositivo
attengono alle capacità di accesso al dispositivo sottostante,63 mentre per i link sim-
bolici questi vengono semplicemente ignorati: in nessuno dei due casi hanno a che
fare con il contenuto del file, e nella discussione relativa all’uso degli extended user
attributes nessuno è mai stato capace di indicare una qualche forma sensata di utiliz-
zo degli stessi per link simbolici o file di dispositivo, e neanche per le fifo o i socket.
Per questo motivo essi sono stati completamente disabilitati per tutto ciò che non
sia un file regolare o una directory.64 Inoltre per le directory è stata introdotta una
ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi di scrittura
completi su directory come /tmp. Per questo motivo, per evitare eventuali abusi, se
una directory ha lo sticky bit attivo sarà consentito scrivere i suoi extended user at-
tributes soltanto se si è proprietari della stessa, o si hanno i privilegi amministrativi
della capability CAP_FOWNER.
61
vale a dire una politica di accesso analoga a quella impiegata per gli ordinari permessi dei file.
62
la cosa è stata notata su XFS, dove questo comportamento permetteva, non essendovi limiti sullo spazio
occupabile dagli Extended Attributes, di bloccare il sistema riempiendo il disco.
63
motivo per cui si può formattare un disco anche se /dev è su un filesystem in sola lettura.
64
si può verificare la semantica adottata consultando il file fs/xattr.c dei sorgenti del kernel.

Le funzioni per la gestione degli attributi estesi, come altre funzioni di gestione avanzate
specifiche di Linux, non fanno parte delle glibc, e sono fornite da una apposita libreria, libattr,
che deve essere installata a parte;65 pertanto se un programma le utilizza si dovrà indicare
esplicitamente l’uso della suddetta libreria invocando il compilatore con l’opzione -lattr.
Per poter leggere gli attributi estesi sono disponibili tre diverse funzioni, getxattr, lgetxattr
e fgetxattr, che consentono rispettivamente di richiedere gli attributi relativi a un file, a un
link simbolico e ad un file descriptor; i rispettivi prototipi sono:
#include <attr/xattr.h>
ssize_t getxattr(const char *path, const char *name, void *value, size_t size)
ssize_t lgetxattr(const char *path, const char *name, void *value, size_t size)
ssize_t fgetxattr(int filedes, const char *name, void *value, size_t size)
Le funzioni leggono il valore di un attributo esteso.
Le funzioni restituiscono un intero positivo che indica la dimensione dell’attributo richiesto in caso
di successo, e −1 in caso di errore, nel qual caso errno assumerà i valori:
ENOATTR l’attributo richiesto non esiste.
ERANGE la dimensione size del buffer value non è sufficiente per contenere il risultato.
ENOTSUP gli attributi estesi non sono supportati dal filesystem o sono disabilitati.
e tutti gli errori di stat, come EPERM se non si hanno i permessi di accesso all’attributo.
Le funzioni getxattr e lgetxattr prendono come primo argomento un pathname che indica
il file di cui si vuole richiedere un attributo, la sola differenza è che la seconda, se il pathname
indica un link simbolico, restituisce gli attributi di quest’ultimo e non quelli del file a cui esso
fa riferimento. La funzione fgetxattr prende invece come primo argomento un numero di file
descriptor, e richiede gli attributi del file ad esso associato.
Tutte e tre le funzioni richiedono di specificare nell’argomento name il nome dell’attributo di
cui si vuole ottenere il valore. Il nome deve essere indicato comprensivo di prefisso del namespace
cui appartiene (uno dei valori di tab. 5.11) nella forma namespace.attributename, come stringa
terminata da un carattere NUL. Il suo valore verrà restituito nel buffer puntato dall’argomento
value per una dimensione massima di size byte;66 se quest’ultima non è sufficiente si avrà un
errore di ERANGE.
Per evitare di dover indovinare la dimensione di un attributo per tentativi si può eseguire
una interrogazione utilizzando un valore nullo per size; in questo caso non verrà letto nessun
dato, ma verrà restituito come valore di ritorno della funzione chiamata la dimensione totale
dell’attributo esteso richiesto, che si potrà usare come stima per allocare un buffer di dimensioni
sufficienti.67
Un secondo gruppo di funzioni è quello che consente di impostare il valore di un attributo
esteso, queste sono setxattr, lsetxattr e fsetxattr, e consentono di operare rispettivamente
su un file, su un link simbolico o specificando un file descriptor; i loro prototipi sono:
65
la versione corrente della libreria è libattr1.
66
gli attributi estesi possono essere costituiti arbitrariamente da dati testuali o binari.
67
si parla di stima perché anche se le funzioni restituiscono la dimensione esatta dell’attributo al momento in
cui sono eseguite, questa potrebbe essere modificata in qualunque momento da un successivo accesso eseguito da
un altro processo.

int setxattr(const char *path, const char *name, const void *value, size_t size,
int flags)
int lsetxattr(const char *path, const char *name, const void *value, size_t size,
int flags)
int fsetxattr(int filedes, const char *name, const void *value, size_t size, int
flags)
Impostano il valore di un attributo esteso.
Le funzioni restituiscono 0 in caso di successo, e −1 in caso di errore, nel qual caso errno assumerà
i valori:
ENOATTR si è usato il flag XATTR_REPLACE e l’attributo richiesto non esiste.
EEXIST si è usato il flag XATTR_CREATE ma l’attributo esiste già.
Oltre a questi potranno essere restituiti tutti gli errori di stat, ed in particolare EPERM se non si
hanno i permessi di accesso all’attributo.
Le tre funzioni prendono come primo argomento un valore adeguato al loro scopo, usato
in maniera del tutto identica a quanto visto in precedenza per le analoghe che leggono gli
attributi estesi. Il secondo argomento name deve indicare, anche in questo caso con gli stessi
criteri appena visti per le analoghe getxattr, lgetxattr e fgetxattr, il nome (completo di
suffisso) dell’attributo su cui si vuole operare.
Il valore che verrà assegnato all’attributo dovrà essere preparato nel buffer puntato da value,
e la sua dimensione totale (in byte) sarà indicata dall’argomento size. Infine l’argomento flag
consente di controllare le modalità di sovrascrittura dell’attributo esteso, esso può prendere
due valori: con XATTR_REPLACE si richiede che l’attributo esista, nel qual caso verrà sovrascritto,
altrimenti si avrà errore, mentre con XATTR_CREATE si richiede che l’attributo non esista, nel qual
caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà modificato. Utilizzando
per flag un valore nullo l’attributo verrà modificato se è già presente, o creato se non c’è.
Le funzioni finora illustrate permettono di leggere o scrivere gli attributi estesi, ma sarebbe
altrettanto utile poter vedere quali sono gli attributi presenti; a questo provvedono le funzioni
listxattr, llistxattr e flistxattr i cui prototipi sono:
ssize_t listxattr(const char *path, char *list, size_t size)
ssize_t llistxattr(const char *path, char *list, size_t size)
ssize_t flistxattr(int filedes, char *list, size_t size)
Leggono la lista degli attributi estesi di un file.
Le funzioni restituiscono un intero positivo che indica la dimensione della lista in caso di successo,
e −1 in caso di errore, nel qual caso errno assumerà i valori:
ERANGE la dimensione size del buffer value non è sufficiente per contenere il risultato.
Oltre a questi potranno essere restituiti tutti gli errori di stat, ed in particolare EPERM se non si
hanno i permessi di accesso all’attributo.
Come per le precedenti le tre funzioni leggono gli attributi rispettivamente di un file, un link
simbolico o specificando un file descriptor, da specificare con il loro primo argomento. Gli altri
due argomenti, identici per tutte e tre, indicano rispettivamente il puntatore list al buffer dove
deve essere letta la lista e la dimensione size di quest’ultimo.
La lista viene fornita come sequenza non ordinata dei nomi dei singoli attributi estesi (sempre
comprensivi del prefisso della loro classe) ciascuno dei quali è terminato da un carattere nullo.
I nomi sono inseriti nel buffer uno di seguito all’altro. Il valore di ritorno della funzione indica
la dimensione totale della lista in byte.

Come per le funzioni di lettura dei singoli attributi se le dimensioni del buffer non sono
sufficienti si avrà un errore, ma è possibile ottenere dal valore di ritorno della funzione una stima
della dimensione totale della lista usando per size un valore nullo.
Infine per rimuovere semplicemente un attributo esteso, si ha a disposizione un ultimo gruppo
di funzioni: removexattr, lremovexattr e fremovexattr; i rispettivi prototipi sono:
int removexattr(const char *path, const char *name)
int lremovexattr(const char *path, const char *name)
int fremovexattr(int filedes, const char *name)
Rimuovono un attributo esteso di un file.
Le funzioni restituiscono 0 in caso di successo, e −1 in caso di errore, nel qual caso errno assumerà
i valori:
ENOATTR l’attributo richiesto non esiste.
ed inoltre tutti gli errori di stat.
Le tre funzioni rimuovono l’attributo esteso indicato dall’argomento name rispettivamente
di un file, un link simbolico o specificando un file descriptor, da specificare con il loro primo
argomento. Anche in questo caso l’argomento name deve essere specificato con le modalità già
illustrate in precedenza per le altre funzioni relative agli attributi estesi.
5.4.2 Le Access Control List
Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente, è comunque piut-
tosto limitato e per quanto possa aver coperto per lunghi anni le esigenze più comuni con un
meccanismo semplice e potente, non è in grado di rispondere in maniera adeguata a situazioni
che richiedono una gestione complessa dei permessi di accesso.68
Per questo motivo erano state progressivamente introdotte nelle varie versioni di Unix dei
meccanismi di gestione dei permessi dei file più flessibili, nella forma delle cosiddette Access
Control List (indicate usualmente con la sigla ACL). Nello sforzo di standardizzare queste fun-
zionalità era stato creato un gruppo di lavoro il cui scopo era estendere lo standard POSIX 1003
attraverso due nuovi insiemi di specifiche, la POSIX 1003.1e per l’interfaccia di programmazione
e la POSIX 1003.2c per i comandi di shell.
Gli obiettivi erano però forse troppo ambizioni, e nel gennaio del 1998 i finanziamenti ven-
nero ritirati senza che si fosse arrivati alla definizione di uno standard, dato però che una parte
della documentazione prodotta era di alta qualità venne deciso di rilasciare al pubblico la di-
ciassettesima bozza del documento, quella che va sotto il nome di POSIX 1003.1e Draft 17, che
è divenuta la base sulla quale si definiscono le cosiddette Posix ACL.
A differenza di altri sistemi (ad esempio FreeBSD) nel caso di Linux si è scelto di realizzare le
ACL attraverso l’uso degli Extended Attributes (appena trattati in sez. 5.4.1), e fornire tutte le
relative funzioni di gestione tramite una libreria, libacl che nasconde i dettagli implementativi
delle ACL e presenta ai programmi una interfaccia che fa riferimento allo standard POSIX
1003.1e.
Anche in questo caso le funzioni di questa libreria non fanno parte delle glibc e devono essere
installate a parte;69 pertanto se un programma le utilizza si dovrà indicare esplicitamente l’uso
della libreria libacl invocando il compilatore con l’opzione -lacl. Si tenga presente inoltre che
68
già un requisito come quello di dare accesso in scrittura ad alcune persone ed in sola lettura ad altre non si
può soddisfare in maniera semplice.
69
la versione corrente della libreria è libacl1, e nel caso si usi Debian la si può installare con il pacchetto
omonimo e con il collegato libacl1-dev per i file di sviluppo.

per poterle utilizzare le ACL devono essere attivate esplicitamente montando il filesystem70 su
cui le si vogliono utilizzare con l’opzione acl attiva. Dato che si tratta di una estensione è infatti
opportuno utilizzarle soltanto laddove siano necessarie.
Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta costituita da un
tipo, da un eventuale qualificatore,71 e da un insieme di permessi. Ad ogni oggetto sul filesystem
si può associare una ACL che ne governa i permessi di accesso, detta access ACL. Inoltre per le
directory si può impostare una ACL aggiuntiva, detta default ACL, che serve ad indicare quale
dovrà essere la ACL assegnata di default nella creazione di un file all’interno della directory
stessa. Come avviene per i permessi le ACL possono essere impostate solo del proprietario del
file, o da un processo con la capability CAP_FOWNER.
Tipo Descrizione
ACL_USER_OBJ voce che contiene i diritti di accesso del proprietario del
file.
ACL_USER voce che contiene i diritti di accesso per l’utente indicato
dal rispettivo qualificatore.
ACL_GROUP_OBJ voce che contiene i diritti di accesso del gruppo
proprietario del file.
ACL_GROUP voce che contiene i diritti di accesso per il gruppo indicato
dal rispettivo qualificatore.
ACL_MASK voce che contiene la maschera dei massimi permessi di
accesso che possono essere garantiti da voci del tipo
ACL_USER, ACL_GROUP e ACL_GROUP_OBJ.
ACL_OTHER voce che contiene i diritti di accesso di chi non
corrisponde a nessuna altra voce dell’ACL.
Tabella 5.12: Le costanti che identificano i tipi delle voci di una ACL.
L’elenco dei vari tipi di voci presenti in una ACL, con una breve descrizione del relativo signi-
ficato, è riportato in tab. 5.12. Tre di questi tipi, ACL_USER_OBJ, ACL_GROUP_OBJ e ACL_OTHER,
corrispondono direttamente ai tre permessi ordinari dei file (proprietario, gruppo proprietario
e tutti gli altri) e per questo una ACL valida deve sempre contenere una ed una sola voce per
ciascuno di questi tipi.
Una ACL può poi contenere un numero arbitrario di voci di tipo ACL_USER e ACL_GROUP,
ciascuna delle quali indicherà i permessi assegnati all’utente e al gruppo indicato dal relativo
qualificatore; ovviamente ciascuna di queste voci dovrà fare riferimento ad un utente o ad un
gruppo diverso, e non corrispondenti a quelli proprietari del file. Inoltre se in una ACL esiste
una voce di uno di questi due tipi è obbligatoria anche la presenza di una ed una sola voce di
tipo ACL_MASK, che negli altri casi è opzionale.
Quest’ultimo tipo di voce contiene la maschera dei permessi che possono essere assegnati
tramite voci di tipo ACL_USER, ACL_GROUP e ACL_GROUP_OBJ; se in una di queste voci si fosse
specificato un permesso non presente in ACL_MASK questo verrebbe ignorato. L’uso di una ACL di
tipo ACL_MASK è di particolare utilità quando essa associata ad una default ACL su una directory,
in quanto i permessi cos`ı specificati verranno ereditati da tutti i file creati nella stessa directory.
Si ottiene cos`ı una sorta di umask associata ad un oggetto sul filesystem piuttosto che a un
processo.
Dato che le ACL vengono a costituire una estensione dei permessi ordinari, uno dei pro-
blemi che si erano posti nella loro standardizzazione era appunto quello della corrispondenza
fra questi e le ACL. Come accennato i permessi ordinari vengono mappati le tre voci di tipo
ACL_USER_OBJ, ACL_GROUP_OBJ e ACL_OTHER che devono essere presenti in qualunque ACL; un
cambiamento ad una di queste voci viene automaticamente riflesso sui permessi ordinari dei
70
che deve supportarle, ma questo è ormai vero per praticamente tutti i filesystem più comuni, con l’eccezione
di NFS per il quale esiste però un supporto sperimentale.
71
deve essere presente soltanto per le voci di tipo ACL_USER e ACL_GROUP.

file72 e viceversa. In realtà la mappatura è diretta solo per le voci ACL_USER_OBJ e ACL_OTHER,
nel caso di ACL_GROUP_OBJ questo vale soltanto se non è presente una voce di tipo ACL_MASK, se
invece questa è presente verranno tolti dai permessi di ACL_GROUP_OBJ tutti quelli non presenti
in ACL_MASK.73
Un secondo aspetto dell’incidenza delle ACL sul comportamento del sistema è quello relativo
alla creazione di nuovi file,74 che come accennato può essere modificato dalla presenza di una
default ACL sulla directory che contiene quel file. Se questa non c’è valgono le regole usuali
illustrate in sez. 5.3.3, per cui essi sono determinati dalla umask del processo, e la sola differenza è
che i permessi ordinari da esse risultanti vengono automaticamente rimappati anche su una ACL
di accesso assegnata automaticamente al nuovo file, che contiene soltanto le tre corrispondenti
voci di tipo ACL_USER_OBJ, ACL_GROUP_OBJ e ACL_OTHER.
Se invece è presente una ACL di default sulla directory che contiene il nuovo file questa
diventerà automaticamente la sua ACL di accesso, a meno di non aver indicato, nelle funzioni
di creazione che lo consentono, uno specifico valore per i permessi ordinari;75 in tal caso saranno
eliminati dalle voci corrispondenti nella ACL tutti quelli non presenti in tale indicazione.
Dato che questa è la ragione che ha portato alla loro creazione, la principale modifica intro-
dotta con la presenza della ACL è quella alle regole del controllo di accesso ai file illustrate in
sez. 5.3.1. Come nel caso ordinario per il controllo vengono sempre utilizzati gli identificatori del
gruppo effective del processo, ma in presenza di ACL i passi attraverso i quali viene stabilito se
esso ha diritto di accesso sono i seguenti:
1. Se l’user-ID del processo è nullo l’accesso è sempre garantito senza nessun controllo.
2. Se l’user-ID del processo corrisponde al proprietario del file allora:
• se la voce ACL_USER_OBJ contiene il permesso richiesto, l’accesso è consentito;
• altrimenti l’accesso è negato.
3. Se l’user-ID del processo corrisponde ad un qualunque qualificatore presente in una voce
ACL_USER allora:
• se la voce ACL_USER corrispondente e la voce ACL_MASK contengono entrambe il
permesso richiesto, l’accesso è consentito;
4. Se è il group-ID del processo o uno dei group-ID supplementari corrisponde al gruppo
proprietario del file allora:
• se la voce ACL_GROUP_OBJ e una eventuale voce ACL_MASK (se non vi sono voci di
tipo ACL_GROUP questa può non essere presente) contengono entrambe il permesso
richiesto, l’accesso è consentito;
5. Se è il group-ID del processo o uno dei group-ID supplementari corrisponde ad un qualun-
que qualificatore presente in una voce ACL_GROUP allora:
• se la voce ACL_GROUP corrispondente e la voce ACL_MASK contengono entrambe il
permesso richiesto, l’accesso è consentito;
72
per permessi ordinari si intende quelli mantenuti nell’inode, che devono restare dato che un filesystem può
essere montato senza abilitare le ACL.
73
questo diverso comportamento a seconda delle condizioni è stato introdotto dalla standardizzazione POSIX
1003.1e Draft 17 per mantenere il comportamento invariato sui sistemi dotati di ACL per tutte quelle applicazioni
che sono conformi soltanto all’ordinario standard POSIX 1003.1.
74
o oggetti sul filesystem, il comportamento discusso vale per le funzioni open e creat (vedi sez. 6.2.1), mkdir
(vedi sez. 5.1.4), mknod e mkfifo (vedi sez. 5.1.5).
75
tutte le funzioni citate in precedenza supportano un argomento mode che indichi un insieme di permessi
iniziale.

6. Se la voce ACL_USER_OBJ contiene il permesso richiesto, l’accesso è consentito, altrimenti
l’accesso è negato.
I passi di controllo vengono eseguiti esattamente in questa sequenza, e la decisione viene
presa non appena viene trovata una corrispondenza con gli identificatori del processo. Questo
significa che i permessi presenti in una voce di tipo ACL_USER hanno la precedenza sui permessi
ordinari associati al gruppo proprietario del file (vale a dire su ACL_GROUP_OBJ).
Per la gestione delle ACL lo standard POSIX 1003.1e Draft 17 ha previsto delle apposite
funzioni ed tutta una serie di tipi di dati dedicati;76 tutte le operazioni devono essere effettuate
attraverso tramite questi tipi di dati, che incapsulano tutte le informazioni contenute nelle ACL.
La prima di queste funzioni che prendiamo in esame è acl_init, il cui prototipo è:
#include <sys/acl.h>
acl_t acl_init(int count)
Inizializza un’area di lavoro per una ACL di count voci.
La funzione restituisce un puntatore all’area di lavoro in caso di successo e NULL in caso di errore,
nel qual caso errno assumerà uno dei valori:
EINVAL il valore di count è negativo.
ENOMEM non c’è sufficiente memoria disponibile.
La funzione alloca ed inizializza un’area di memoria che verrà usata per mantenere i dati
di una ACL contenente fino ad un massimo di count voci. La funzione ritorna un valore di
tipo acl_t, da usare in tutte le altre funzioni che operano sulla ACL. La funzione si limita alla
allocazione iniziale e non inserisce nessun valore nella ACL che resta vuota. Si tenga presente
che pur essendo acl_t un tipo opaco che identifica “l’oggetto” ACL, il valore restituito dalla
funzione non è altro che un puntatore all’area di memoria allocata per i dati richiesti; pertanto
in caso di fallimento verrà restituito un puntatore nullo e si dovrà confrontare il valore di ritorno
della funzione con “(acl_t) NULL”.
Una volta che si siano completate le operazioni sui dati di una ACL la memoria allocata dovrà
essere liberata esplicitamente attraverso una chiamata alla funzione acl_free, il cui prototipo
è:
int acl_free(void * obj_p)
Disalloca la memoria riservata per i dati di una ACL.
La funzione restituisce 0 in caso di successo e −1 se obj_p non è un puntatore valido, nel qual
caso errno assumerà il valore EINVAL
Si noti come la funzione richieda come argomento un puntatore di tipo “void *”, essa infatti
può essere usata non solo per liberare la memoria allocata per i dati di una ACL, ma anche
per quella usata per creare le stringhe di descrizione testuale delle ACL o per ottenere i valori
dei qualificatori di una voce; pertanto a seconda dei casi occorrerà eseguire un cast a “void
*” del tipo di dato di cui si vuole eseguire la disallocazione. Si tenga presente poi che oltre a
acl_init esistono molte altre funzioni che possono allocare memoria per i dati delle ACL, è
pertanto opportuno tenere traccia di tutte queste funzioni perché alla fine delle operazioni tutta
la memoria allocata dovrà essere liberata con acl_free.
Una volta che si abbiano a disposizione i dati di una ACL tramite il riferimento ad oggetto
di tipo acl_t questi potranno essere copiati con la funzione acl_dup, il cui prototipo è:
76
fino a definire un tipo di dato e delle costanti apposite per identificare i permessi standard di lettura, scrittura
ed esecuzione.

acl_t acl_dup(acl_t acl)
Crea una copia della ACL acl.
La funzione restituisce un oggetto di tipo acl_t in caso di successo e (acl_t)NULL in caso di
errore, nel qual caso errno assumerà uno dei valori:
EINVAL l’argomento acl non è un puntatore valido per una ACL.
ENOMEM non c’è sufficiente memoria disponibile per eseguire la copia.
La funzione crea una copia dei dati della ACL indicata tramite l’argomento acl, allocando
autonomamente tutto spazio necessario alla copia e restituendo un secondo oggetto di tipo acl_t
come riferimento a quest’ultima. Valgono per questo le stesse considerazioni fatte per il valore
di ritorno di acl_init, ed in particolare il fatto che occorrerà prevedere una ulteriore chiamata
esplicita a acl_free per liberare la memoria occupata dalla copia.
Se si deve creare una ACL manualmente l’uso di acl_init è scomodo, dato che la funzione
restituisce una ACL vuota, una alternativa allora è usare acl_from_mode che consente di creare
una ACL a partire da un valore di permessi ordinari, il prototipo della funzione è:
acl_t acl_from_mode(mode_t mode)
Crea una ACL inizializzata con i permessi di mode.
errore, nel qual caso errno assumerà il valore ENOMEM.
La funzione restituisce una ACL inizializzata con le tre voci obbligatorie ACL_USER_OBJ,
ACL_GROUP_OBJ e ACL_OTHER già impostate secondo la corrispondenza ai valori dei permessi
ordinari indicati dalla maschera passata nell’argomento mode. Questa funzione è una estensione
usata dalle ACL di Linux e non è portabile, ma consente di semplificare l’inizializzazione in
maniera molto comoda.
Altre due funzioni che consentono di creare una ACL già inizializzata sono acl_get_fd e
acl_get_file, che però sono per lo più utilizzate per leggere la ACL corrente di un file; i
acl_t acl_get_file(const char *path_p, acl_type_t type)
acl_t acl_get_fd(int fd)
Ottiene i dati delle ACL di un file.
ENOMEM non c’è memoria sufficiente per allocare i dati.
ENOTSUP il filesystem cui fa riferimento il file non supporta le ACL.
ed inoltre EBADF per acl_get_fd, ed EINVAL per valori scorretti di type e tutti i possibili errori
per l’accesso ad un file per acl_get_file.
Le due funzioni ritornano, con un oggetto di tipo acl_t, il valore della ACL correntemente
associata ad un file, che può essere identificato tramite un file descriptor usando acl_get_fd o
con un pathname usando acl_get_file. Nel caso di quest’ultima funzione, che può richiedere
anche la ACL relativa ad una directory, il secondo argomento type consente di specificare se
si vuole ottenere la ACL di default o quella di accesso. Questo argomento deve essere di tipo
acl_type_t e può assumere solo i due valori riportati in tab. 5.13.
Si tenga presente che nel caso di acl_get_file occorrerà che il processo chiamante abbia pri-
vilegi di accesso sufficienti a poter leggere gli attributi estesi dei file (come illustrati in sez. 5.4.1);

Tipo Descrizione
ACL_TYPE_ACCESS indica una ACL di accesso.
ACL_TYPE_DEFAULT indica una ACL di default.
Tabella 5.13: Le costanti che identificano il tipo di ACL.
inoltre una ACL di tipo ACL_TYPE_DEFAULT potrà essere richiesta soltanto per una directory, e
verrà restituita solo se presente, altrimenti verrà restituita una ACL vuota.
Infine si potrà creare una ACL direttamente dalla sua rappresentazione testuale con la
funzione acl_from_text, il cui prototipo è:
acl_t acl_from_text(const char *buf_p)
Crea una ACL a partire dalla sua rappresentazione testuale.
EINVAL la rappresentazione testuale all’indirizzo buf_p non è valida.
La funzione prende come argomento il puntatore ad un buffer dove si è inserita la rappre-
sentazione testuale della ACL che si vuole creare, la memoria necessaria viene automaticamen-
te allocata ed in caso di successo viene restituito come valore di ritorno un oggetto di tipo
acl_t con il contenuto della stessa, che come per le precedenti funzioni, dovrà essere disallocato
esplicitamente al termine del suo utilizzo.
La rappresentazione testuale di una ACL è quella usata anche dai comandi ordinari per la
gestione delle ACL (getfacl e setfacl), che prevede due diverse forme, estesa e breve, entrambe
supportate da acl_from_text. La forma estesa prevede che sia specificata una voce per riga,
nella forma:
tipo:qualificatore:permessi
dove il tipo può essere uno fra user, group, other e mask. Il qualificatore è presente solo per
user e group e indica l’utente o il gruppo a cui la voce si riferisce; i permessi sono espressi con
una tripletta di lettere analoga a quella usata per i permessi dei file.77
Va precisato che i due tipi user e group sono usati rispettivamente per indicare delle voci
relative ad utenti e gruppi,78 applicate sia a quelli proprietari del file che a quelli generici; quelle
dei proprietari si riconoscono per l’assenza di un qualificatore, ed in genere si scrivono per prima
delle altre. Il significato delle voci di tipo mask e mark è evidente. In questa forma si possono
anche inserire dei commenti precedendoli con il carattere “#”.
La forma breve prevede invece la scrittura delle singole voci su una riga, separate da virgole;
come specificatori del tipo di voce si possono usare le iniziali dei valori usati nella forma estesa
(cioè “u”, “g”, “o” e “m”), mentre le altri parte della voce sono le stesse. In questo caso non sono
consentiti permessi.
Per la conversione inversa, che consente di ottenere la rappresentazione testuale di una ACL,
sono invece disponibili due funzioni, la prima delle due, di uso più immediato, è acl_to_text,
77
vale a dire r per il permesso di lettura, w per il permesso di scrittura, x per il permesso di esecuzione (scritti
in quest’ordine) e - per l’assenza del permesso.
78
cioè per voci di tipo ACL_USER_OBJ e ACL_USER per user e ACL_GROUP_OBJ e ACL_GROUP per group.

char * acl_to_text(acl_t acl, ssize_t *len_p)
Produce la rappresentazione testuale di una ACL.
La funzione restituisce il puntatore ad una stringa con la rappresentazione testuale della ACL in
caso di successo e (acl t)NULL in caso di errore, nel qual caso errno assumerà uno dei valori:
EINVAL la ACL indicata da acl non è valida.
La funzione restituisce il puntatore ad una stringa terminata da NUL contenente la rappre-
sentazione in forma estesa della ACL passata come argomento, ed alloca automaticamente la
memoria necessaria. Questa dovrà poi essere liberata, quando non più necessaria, con acl_free.
Se nell’argomento len_p si passa un valore puntatore ad una variabile intera in questa ver-
rà restituita la dimensione della stringa con la rappresentazione testuale (non comprendente il
carattere nullo finale).
La seconda funzione, acl_to_any_text, permette di controllare con dovizia di dettagli la
generazione della stringa contenente la rappresentazione testuale della ACL, il suo prototipo è:
char * acl_to_any_text(acl_t acl, const char *prefix, char separator, int
options)
Produce la rappresentazione testuale di una ACL.
La funzione restituisce il puntatore ad una stringa con la rappresentazione testuale della ACL in
caso di successo e NULL in caso di errore, nel qual caso errno assumerà uno dei valori:
La funzione converte in formato testo la ACL indicata dall’argomento acl, usando il carattere
separator come separatore delle singole voci; se l’argomento prefix non è nullo la stringa da
esso indicata viene utilizzata come prefisso per le singole voci.
L’ultimo argomento, options, consente di controllare la modalità con cui viene generata
la rappresentazione testuale. Un valore nullo fa si che vengano usati gli identificatori standard
user, group, other e mask con i nomi di utenti e gruppi risolti rispetto ai loro valori numerici.
Altrimenti si può specificare un valore in forma di maschera binaria, da ottenere con un OR
aritmetico dei valori riportati in tab. 5.14.
Tipo Descrizione
TEXT_ABBREVIATE stampa le voci in forma abbreviata.
TEXT_NUMERIC_IDS non effettua la risoluzione numerica di user-ID e group-
ID.
TEXT_SOME_EFFECTIVE per ciascuna voce che contiene permessi che vengono
eliminati dalla ACL_MASK viene generato un commento
con i permessi effettivamente risultanti; il commento è
separato con un tabulatore.
TEXT_ALL_EFFECTIVE viene generato un commento con i permessi effettivi per
ciascuna voce che contiene permessi citati nella ACL_MASK,
anche quando questi non vengono modificati da essa; il
commento è separato con un tabulatore.
TEXT_SMART_INDENT da usare in combinazione con le precedenti
TEXT_SOME_EFFECTIVE e TEXT_ALL_EFFECTIVE aumenta
automaticamente il numero di spaziatori prima degli
eventuali commenti in modo da mantenerli allineati.
Tabella 5.14: Possibili valori per l’argomento options di acl_to_any_text.

Come per acl_to_text anche in questo caso il buffer contenente la rappresentazione testua-
le dell’ACL, di cui la funzione restituisce l’indirizzo, viene allocato automaticamente, e dovrà
essere esplicitamente disallocato con una chiamata ad acl_free. Si tenga presente infine che
questa funzione è una estensione specifica di Linux, e non è presente nella bozza dello standard
POSIX.1e.
Per quanto utile per la visualizzazione o l’impostazione da comando delle ACL, la forma
testuale non è la più efficiente per poter memorizzare i dati relativi ad una ACL, ad esempio
quando si vuole eseguirne una copia a scopo di archiviazione. Per questo è stata prevista la
possibilità di utilizzare una rappresentazione delle ACL in una apposita forma binaria contigua e
persistente. È cos`ı possibile copiare il valore di una ACL in un buffer e da questa rappresentazione
tornare indietro e generare una ACL.
Lo standard POSIX.1e prevede a tale scopo tre funzioni, la prima e più semplice è acl_size,
che consente di ottenere la dimensione che avrà la citata rappresentazione binaria, in modo da
poter allocare per essa un buffer di dimensione sufficiente, il suo prototipo è:
ssize_t acl_size(acl_t acl)
Determina la dimensione della rappresentazione binaria di una ACL.
La funzione restituisce in caso di successo la dimensione in byte della rappresentazione binaria
della ACL indicata da acl e −1 in caso di errore, nel qual caso errno assumerà uno dei valori:
Prima di effettuare la lettura della rappresentazione binaria è sempre necessario allocare un
buffer di dimensione sufficiente a contenerla, pertanto prima si dovrà far ricorso a acl_size per
ottenere tale dimensione e poi allocare il buffer con una delle funzioni di sez. 2.2.3. Una volta
terminato l’uso della rappresentazione binaria, il buffer dovrà essere esplicitamente disallocato.
La funzione che consente di leggere la rappresentazione binaria di una ACL è acl_copy_ext,
ssize_t acl_copy_ext(void *buf_p, acl_t acl, ssize_t size)
Ottiene la rappresentazione binaria di una ACL.
La funzione restituisce in caso di successo la dimensione in byte della rappresentazione binaria
della ACL indicata da acl e −1 in caso di errore, nel qual caso errno assumerà uno dei valori:
EINVAL la ACL indicata da acl non è valida o size è negativo o nullo.
ERANGE il valore di size è più piccolo della dimensione della rappresentazione della ACL.
La funzione salverà la rappresentazione binaria della ACL indicata da acl sul buffer posto
all’indirizzo buf_p e lungo size byte, restituendo la dimensione della stessa come valore di
ritorno. Qualora la dimensione della rappresentazione ecceda il valore di size la funzione fallirà
con un errore di ERANGE. La funzione non ha nessun effetto sulla ACL indicata da acl.
Viceversa se si vuole ripristinare una ACL a partire dalla rappresentazione binaria della
stessa disponibile in un buffer si potrà usare la funzione acl_copy_int, il cui prototipo è:
ssize_t acl_copy_int(const void *buf_p)
Ripristina la rappresentazione binaria di una ACL.
EINVAL il buffer all’indirizzo buf_p non contiene una rappresentazione corretta di una ACL.
ENOMEM non c’è memoria sufficiente per allocare un oggetto acl_t per la ACL richiesta.

La funzione in caso di successo alloca autonomamente un oggetto di tipo acl_t che viene
restituito come valore di ritorno con il contenuto della ACL rappresentata dai dati contenuti nel
buffer puntato da buf_p. Si ricordi che come per le precedenti funzioni l’oggetto acl_t dovrà
essere disallocato esplicitamente al termine del suo utilizzo.
Una volta che si disponga della ACL desiderata, questa potrà essere impostata su un file o
una directory. Per impostare una ACL sono disponibili due funzioni; la prima è acl_set_file,
che opera sia su file che su directory, ed il cui prototipo è:
int acl_set_file(const char *path, acl_type_t type, acl_t acl)
Imposta una ACL su un file o una directory.
La funzione restituisce 0 in caso di successo e −1 in caso di errore, nel qual caso errno assumerà
uno dei valori:
EACCES o un generico errore di accesso a path o il valore di type specifica una ACL il cui tipo
non può essere assegnato a path.
EINVAL o acl non è una ACL valida, o type ha in valore non corretto.
ENOSPC non c’è spazio disco sufficiente per contenere i dati aggiuntivi della ACL.
ENOTSUP si è cercato di impostare una ACL su un file contenuto in un filesystem che non
supporta le ACL.
ed inoltre ENOENT, ENOTDIR, ENAMETOOLONG, EROFS, EPERM.
La funzione consente di assegnare la ACL contenuta in acl al file o alla directory indicate
dal pathname path, mentre con type si indica il tipo di ACL utilizzando le costanti di tab. 5.13,
ma si tenga presente che le ACL di default possono essere solo impostate qualora path indichi
una directory. Inoltre perché la funzione abbia successo la ACL dovrà essere valida, e contenere
tutti le voci necessarie, unica eccezione è quella in cui si specifica una ACL vuota per cancellare
la ACL di default associata a path.79 La seconda funzione che consente di impostare una ACL
è acl_set_fd, ed il suo prototipo è:
int acl_set_fd(int fd, acl_t acl)
Imposta una ACL su un file descriptor.
uno dei valori:
EINVAL o acl non è una ACL valida, o type ha in valore non corretto.
ENOSPC non c’è spazio disco sufficiente per contenere i dati aggiuntivi della ACL.
ENOTSUP si è cercato di impostare una ACL su un file contenuto in un filesystem che non
supporta le ACL.
ed inoltre EBADF, EROFS, EPERM.
La funzione è del tutto è analoga a acl_set_file ma opera esclusivamente sui file identificati
tramite un file descriptor. Non dovendo avere a che fare con directory (e con la conseguente
possibilità di avere una ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
che sarà sempre di accesso, e prende come unico argomento, a parte il file descriptor, la ACL da
impostare.
Le funzioni viste finora operano a livello di una intera ACL, eseguendo in una sola volta
tutte le operazioni relative a tutte le voci in essa contenuta. In generale è possibile modificare
un singolo valore all’interno di una singola voce direttamente con le funzioni previste dallo
79
questo però è una estensione della implementazione delle ACL di Linux, la bozza di standard POSIX.1e
prevedeva l’uso della apposita funzione acl_delete_def_file, che prende come unico argomento il pathname
della directory di cui si vuole cancellare l’ACL di default, per i dettagli si ricorra alla pagina di manuale.

standard POSIX.1e. Queste funzioni però sono alquanto macchinose da utilizzare per cui è
molto più semplice operare direttamente sulla rappresentazione testuale. Questo è il motivo per
non tratteremo nei dettagli dette funzioni, fornendone solo una descrizione sommaria; chi fosse
interessato potrà ricorrere alle pagina di manuale.
Se si vuole operare direttamente sui contenuti di un oggetto di tipo acl_t infatti occor-
re fare riferimento alle singole voci tramite gli opportuni puntatori di tipo acl_entry_t, che
possono essere ottenuti dalla funzione acl_get_entry (per una voce esistente) o dalla funzio-
ne acl_create_entry per una voce da aggiungere. Nel caso della prima funzione si potrà poi
ripetere la lettura per ottenere i puntatori alle singole voci successive alla prima.
Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole voci; con le fun-
zioni acl_get_tag_type, acl_get_qualifier, acl_get_permset si potranno leggere rispetti-
vamente tipo, qualificatore e permessi mentre con le corrispondente funzioni acl_set_tag_type,
acl_set_qualifier, acl_set_permset si possono impostare i valori; in entrambi i casi vengono
utilizzati tipi di dato ad hoc.80 Si possono poi copiare i valori di una voce da una ACL ad un
altra con acl_copy_entry o eliminare una voce da una ACL con acl_delete_entry.
5.4.3 La gestione delle quote disco
Quella delle quote disco è una funzionalità introdotta inizialmente da BSD, e presente in Linux
fino dai kernel dalla serie 2.0, che consente di porre dei tetti massimi al consumo delle risorse di
un filesystem (spazio disco e inode) da parte di utenti e gruppi. Dato che la funzionalità ha senso
solo per i filesystem su cui si mantengono i dati degli utenti81 essa deve essere esplicitamente
richiesta; questo si fa tramite due distinte opzioni di montaggio, usrquota e grpquota che
abilitano le quote rispettivamente per gli utenti e per i gruppi. Grazie a questo è possibile usare
le limitazioni sulle quote solo sugli utenti o solo sui gruppi.
Il meccanismo prevede che per ciascun filesystem che supporta le quote disco (i vari extN,
btrfs, XFS, JFS, ReiserFS) il kernel provveda sia a mantenere aggiornati i dati relativi al consumo
delle risorse da parte di utenti e/o gruppi che a far rispettare i limiti imposti dal sistema, con
la generazione di un errore di EDQUOT per tutte le operazioni sui file che porterebbero ad un
superamento degli stessi. Si tenga presente che questi due compiti sono separati, il primo si attiva
al montaggio del filesystem con le quote attivate, il secondo deve essere abilitato esplicitamente.
Per il mantenimento dei dati di consumo delle risorse vengono usati due file riservati (uno
per le quote utente e l’altro per le quote gruppo) nella directory radice del filesystem su cui si
sono attivate le quote;82 con la versione 2 del supporto delle quote, l’unica rimasta in uso, questi
file sono aquota.user e aquota.group, in precedenza erano quota.user e quota.group. Dato
che i file vengono aggiornati soltanto se il filesystem è stato montato con il supporto delle quote,
se si abilita questo in un secondo tempo (o se si eseguono operazioni sul filesystem senza averlo
abilitato) i dati contenuti possono non corrispondere esattamente allo stato corrente del consumo
delle risorse; per questo in genere prima di montare in scrittura un filesystem su cui sono abilitate
le quote in genere viene utilizzato il comando quotacheck per verificare e aggiornare i dati.
Le restrizioni sul consumo delle risorse prevedono due limiti, il primo viene detto soft limit
e può essere superato per brevi periodi di tempo, il secondo viene detto hard limit non può mai
essere superato. Il periodo di tempo per cui è possibile superare il soft limit è detto “periodo di
grazia” (grace period), passato questo tempo il passaggio del soft limit viene trattato allo stesso
modo dell’hard limit. Questi limiti riguardano separatamente sia lo spazio disco (i blocchi) che
il numero di file (gli inode) e devono pertanto essere specificati per entrambe le risorse.
80
descritti nelle singole pagine di manuale.
81
in genere la si attiva sul filesystem che contiene le home degli utenti, dato che non avrebbe senso per i file di
sistema che in genere appartengono all’amministratore.
82
la cosa vale per tutti i filesystem tranne XFS che mantiene i dati internamente.

La funzione che consente di controllare tutti i vari aspetti della gestione delle quote è
quotactl, ed il suo prototipo è:
#include <sys/quota.h>
quotactl(int cmd, const char *dev, int id, caddr_t addr)
Esegue una operazione di controllo sulle quote disco.
uno dei valori:
EACCES il file delle quote non è un file ordinario.
EBUSY si è richiesto Q_QUOTAON ma le quote sono già attive.
EFAULT l’indirizzo addr non è valido.
EIO errore di lettura/scrittura sul file delle quote.
EMFILE non si può aprire il file delle quote avendo superato il limite sul numero di file aperti
nel sistema.
EINVAL o cmd non è un comando valido, o il dispositivo dev non esiste.
ENODEV dev non corrisponde ad un mount point attivo.
ENOPKG il kernel è stato compilato senza supporto per le quote.
ENOTBLK dev non è un dispositivo a blocchi.
EPERM non si hanno i permessi per l’operazione richiesta.
ESRCH è stato richiesto uno fra Q_GETQUOTA, Q_SETQUOTA, Q_SETUSE, Q_SETQLIM per un
filesystem senza quote attivate.
La funzione richiede che il filesystem sul quale si vuole operare sia montato con il supporto
delle quote abilitato; esso deve essere specificato con il nome del file di dispositivo nell’argomento
dev. Per le operazioni che lo richiedono inoltre si dovrà indicare con l’argomento id l’utente o
il gruppo (specificati rispettivamente per uid e gid) su cui si vuole operare. Alcune operazioni
usano l’argomento addr per indicare un indirizzo ad un area di memoria il cui utilizzo dipende
dall’operazione stessa.
Il tipo di operazione che si intende effettuare deve essere indicato tramite il primo argomento
cmd, questo in genere viene specificato con l’ausilio della macro QCMD:
int QCMD(subcmd,type)
Imposta il comando subcmd per il tipo di quote (utente o gruppo) type.
che consente di specificare, oltre al tipo di operazione, se questa deve applicarsi alle quote utente
o alle quote gruppo, nel qual caso type deve essere rispettivamente USRQUOTA o GRPQUOTA.
Le diverse operazioni supportate da quotactl, da indicare con l’argomento subcmd di QCMD,
sono riportate in tab. 5.15. In generale le operazione di attivazione, disattivazione e di modifica
dei limiti delle quote sono riservate e richiedono i privilegi di amministratore.83 Inoltre gli utenti
possono soltanto richiedere i dati relativi alle proprie quote, solo l’amministratore può ottenere
i dati di tutti.
Alcuni dei comandi di tab. 5.15 sono alquanto complessi e richiedono un approfondimento
maggiore, in particolare Q_GETQUOTA e Q_SETQUOTA fanno riferimento ad una specifica struttura
dqblk, la cui definizione è riportata in fig. 5.10,84 nella quale vengono inseriti i dati relativi alle
quote di un singolo utente.
La struttura viene usata sia con Q_GETQUOTA per ottenere i valori correnti dei limiti e dell’oc-
cupazione delle risorse, che con Q_SETQUOTA per effettuare modifiche ai limiti; come si può notare
83
per essere precisi tutte le operazioni indicate come privilegiate in tab. 5.15 richiedono la capability
CAP_SYS_ADMIN.
84
la definizione mostrata è quella usata fino dal kernel 2.4.22, non prenderemo in considerazione le versioni
obsolete.

Comando Descrizione
Q_QUOTAON Attiva l’applicazione delle quote disco per il filesystem indicato da dev,
si deve passare in addr il pathname al file che mantiene le quote, che
deve esistere, e id deve indicare la versione del formato con uno dei
valori di tab. 5.16; l’operazione richiede i privilegi di amministratore.
Q_QUOTAOFF Disattiva l’applicazione delle quote disco per il filesystem indicato da
dev, id e addr vengono ignorati; l’operazione richiede i privilegi di
amministratore.
Q_GETQUOTA Legge i limiti ed i valori correnti delle quote nel filesystem indicato da
dev per l’utente o il gruppo specificato da id; si devono avere i privilegi
di amministratore per leggere i dati relativi ad altri utenti o a gruppi di
cui non si fa parte, il risultato viene restituito in una struttura dqblk
all’indirizzo indicato da addr.
Q_SETQUOTA Imposta i limiti per le quote nel filesystem indicato da dev per l’u-
tente o il gruppo specificato da id secondo i valori ottenuti dalla
struttura dqblk puntata da addr; l’operazione richiede i privilegi di
amministratore.
Q_GETINFO Legge le informazioni (in sostanza i grace time) delle quote del filesy-
stem indicato da dev sulla struttura dqinfo puntata da addr, id viene
ignorato.
Q_SETINFO Imposta le informazioni delle quote del filesystem indicato da dev come
ottenuti dalla struttura dqinfo puntata da addr, id viene ignorato;
l’operazione richiede i privilegi di amministratore.
Q_GETFMT Richiede il valore identificativo (quello di tab. 5.16) per il formato del-
le quote attualmente in uso sul filesystem indicato da dev, che sarà
memorizzato sul buffer di 4 byte puntato da addr.
Q_SYNC Aggiorna la copia su disco dei dati delle quote del filesystem indicato
da dev; in questo caso dev può anche essere NULL nel qual caso verran-
no aggiornati i dati per tutti i filesystem con quote attive, id e addr
vengono comunque ignorati.
Q_GETSTATS Ottiene statistiche ed altre informazioni generali relative al sistema delle
quote per il filesystem indicato da dev, richiede che si passi come ar-
gomento addr l’indirizzo di una struttura dqstats, mentre i valori di
id e dev vengono ignorati; l’operazione è obsoleta e non supportata nei
kernel più recenti, che espongono la stessa informazione nei file sotto
/proc/self/fs/quota/.
Tabella 5.15: Possibili valori per l’argomento subcmd di QCMD.
struct dqblk
{
u_int64_t dqb_bhardlimit; /* absolute limit on disk quota blocks alloc */
u_int64_t dqb_bsoftlimit; /* preferred limit on disk quota blocks */
u_int64_t dqb_curspace; /* current quota block count */
u_int64_t dqb_ihardlimit; /* maximum # allocated inodes */
u_int64_t dqb_isoftlimit; /* preferred inode limit */
u_int64_t dqb_curinodes; /* current # allocated inodes */
u_int64_t dqb_btime; /* time limit for excessive disk use */
u_int64_t dqb_itime; /* time limit for excessive files */
u_int32_t dqb_valid; /* bitmask of QIF_* constants */
};
Figura 5.10: La struttura dqblk per i dati delle quote disco.
ci sono alcuni campi (in sostanza dqb_curspace, dqb_curinodes, dqb_btime, dqb_itime) che
hanno senso solo in lettura in quanto riportano uno stato non modificabile da quotactl, come
l’uso corrente di spazio e inode o il tempo che resta nel caso si sia superato un soft limit.
Inoltre in caso di modifica di un limite si può voler operare solo su una delle risorse (blocchi

Identificatore Descrizione
QFMT_VFS_OLD il vecchio (ed obsoleto) formato delle quote.
QFMT_VFS_V0 la versione 0 usata dal VFS di Linux (supporta uid e gid a 32 bit e
limiti fino a 242
byte e 232
file.
QFMT_VFS_V1 la versione 1 usata dal VFS di Linux (supporta uid e GID a 32 bit e
limiti fino a 264
byte e 264
file.
Tabella 5.16: Valori di identificazione del formato delle quote.
Costante Descrizione
QIF_BLIMITS Limiti sui blocchi di spazio disco (dqb_bhardlimit e dqb_bsoftlimit).
QIF_SPACE Uso corrente dello spazio disco (dqb_curspace).
QIF_ILIMITS Limiti sugli inode (dqb_ihardlimit e dqb_isoftlimit).
QIF_INODES Uso corrente degli inode (dqb_curinodes).
QIF_BTIME Tempo di sforamento del soft limit sul numero di blocchi (dqb_btime).
QIF_ITIME Tempo di sforamento del soft limit sul numero di inode (dqb_itime).
QIF_LIMITS L’insieme di QIF_BLIMITS e QIF_ILIMITS.
QIF_USAGE L’insieme di QIF_SPACE e QIF_INODES.
QIF_TIMES L’insieme di QIF_BTIME e QIF_ITIME.
QIF_ALL Tutti i precedenti.
Tabella 5.17: Costanti per il campo dqb_valid di dqblk.
o inode);85 per questo la struttura prevede un campo apposito, dqb_valid, il cui scopo è quello
di indicare quali sono gli altri campi che devono essere considerati validi. Questo campo è una
maschera binaria che deve essere espressa nei termini di OR aritmetico delle apposite costanti di
tab. 5.17, dove si è riportato il significato di ciascuna di esse ed i campi a cui fanno riferimento.
In lettura con Q_SETQUOTA eventuali valori presenti in dqblk vengono comunque ignorati, al
momento la funzione sovrascrive tutti i campi e li marca come validi in dqb_valid. Si possono
invece usare QIF_BLIMITS o QIF_ILIMITS per richiedere di impostare solo la rispettiva tipologia
di limiti con Q_SETQUOTA. Si tenga presente che il sistema delle quote richiede che l’occupazione
di spazio disco sia indicata in termini di blocchi e non di byte; dato che questo dipende da come
si è creato il filesystem potrà essere necessario effettuare qualche controllo.86
Altre due operazioni che necessitano di un approfondimento sono Q_GETINFO e Q_SETINFO,
che sostanzialmente consentono di ottenere i dati relativi alle impostazioni delle altre proprietà
delle quote, che si riducono poi alla durata del grace time per i due tipi di limiti. In questo caso
queste si proprietà generali sono identiche per tutti gli utenti, per cui viene usata una operazione
distinta dalle precedenti. Anche in questo caso le due operazioni richiedono l’uso di una apposita
struttura dqinfo, la cui definizione è riportata in fig. 5.11.
struct dqinfo
{
u_int64_t dqi_bgrace;
u_int64_t dqi_igrace;
u_int32_t dqi_flags;
u_int32_t dqi_valid;
};
Figura 5.11: La struttura dqinfo per i dati delle quote disco.
85
non è possibile modificare soltanto uno dei limiti (hard o soft) occorre sempre rispecificarli entrambi.
86
in genere viene usato un default di 1024 byte per blocco, ma quando si hanno file di dimensioni medie maggiori
può convenire usare valori più alti per ottenere prestazioni migliori in conseguenza di un minore frazionamento
dei dati e di indici più corti.

Come per dqblk anche in questo caso viene usato un campo della struttura, dqi_valid
come maschera binaria per dichiarare quale degli altri campi sono validi; le costanti usate per
comporre questo valore sono riportate in tab. 5.18 dove si è riportato il significato di ciascuna
di esse ed i campi a cui fanno riferimento.
Costante Descrizione
IIF_BGRACE Il grace period per i blocchi (dqi_bgrace).
IIF_IGRACE Il grace period per gli inode (dqi_igrace).
IIF_FLAGS I flag delle quote (dqi_flags) (inusato ?).
IIF_ALL Tutti i precedenti.
Tabella 5.18: Costanti per il campo dqi_valid di dqinfo.
Come in precedenza con Q_GETINFO tutti i valori vengono letti sovrascrivendo il contenuto
di dqinfo e marcati come validi in dqi_valid. In scrittura con Q_SETINFO si può scegliere quali
impostare, si tenga presente che i tempi dei campi dqi_bgrace e dqi_igrace devono essere
specificati in secondi.
Come esempi dell’uso di quotactl utilizzeremo estratti del codice di un modulo Python usato
per fornire una interfaccia diretta a quotactl senza dover passare dalla scansione dei risultati
di un comando. Il modulo si trova fra i pacchetti Debian messi a disposizione da Truelite Srl,
all’indirizzo http://labs.truelite.it/projects/packages.87
1 PyObject * get_quota(int who , int id , const char *dev)
2 {
3 struct dqblk dq;
4
5 if (! quotactl(QCMD(Q_GETQUOTA ,who), dev , id , (caddr_t) &dq)) {
6 return Py_BuildValue("({s:K,s:(KK),s:K},{s:K,s:(KK),s:K})",
7 "used", dq.dqb_curspace ,
8 "quota", dq.dqb_bsoftlimit , dq.dqb_bhardlimit ,
9 "grace", dq.dqb_btime ,
10 "used", dq.dqb_curinodes ,
11 "quota", dq.dqb_isoftlimit , dq.dqb_ihardlimit ,
12 "grace", dq.dqb_itime );
13 } else {
14 PyErr_SetFromErrno (PyExc_OSError );
15 return NULL;
16 }
17 }
Figura 5.12: Esempio di codice per ottenere i dati delle quote.
Il primo esempio, riportato in fig. 5.12, riporta il codice della funzione che consente di leggere
le quote. La funzione fa uso dell’interfaccia dal C verso Python, che definisce i vari simboli Py*
(tipi di dato e funzioni). Non staremo ad approfondire i dettagli di questa interfaccia, per la
quale esistono numerose trattazioni dettagliate, ci interessa solo esaminare l’uso di quotactl.
In questo caso la funzione prende come argomenti (1) l’intero who che indica se si vuole
operare sulle quote utente o gruppo, l’identificatore id dell’utente o del gruppo scelto, ed il
nome del file di dispositivo del filesystem su cui si sono attivate le quote.88 Questi argomenti
vengono passati direttamente alla chiamata a quotactl (5), a parte who che viene abbinato con
QCMD al comando Q_GETQUOTA per ottenere i dati.
87
in particolare il codice C del modulo è nel file quotamodule.c visionabile a partire dall’indirizzo indicato nella
sezione Repository.
88
questi vengono passati come argomenti dalle funzioni mappate come interfaccia pubblica del modulo (una per
gruppi ed una per gli utenti) che si incaricano di decodificare i dati passati da una chiamata nel codice Python.

La funzione viene eseguita all’interno di un condizionale (5-16) che in caso di successo prov-
vede a costruire (6-12) opportunamente una risposta restituendo tramite la opportuna funzione
di interfaccia un oggetto Python contenente i dati della struttura dqblk relativi a uso corrente
e limiti sia per i blocchi che per gli inode. In caso di errore (13-15) si usa un’altra funzione
dell’interfaccia per passare il valore di errno come eccezione.
1 PyObject *set_block_quota (int who , int id , const char *dev , int soft , int hard)
2 {
3 struct dqblk dq;
4
5 dq.dqb_bsoftlimit = soft;
6 dq.dqb_bhardlimit = hard;
7 dq.dqb_valid = QIF_BLIMITS;
8
9 if (! quotactl(QCMD(Q_SETQUOTA ,who), dev , id , (caddr_t) &dq)) {
10 Py_RETURN_NONE;
11 } else {
12 PyErr_SetFromErrno (PyExc_OSError );
13 return NULL;
14 }
15 }
Figura 5.13: Esempio di codice per impostare i limiti sullo spazio disco.
Per impostare i limiti sullo spazio disco si potrà usare una seconda funzione, riportata in
fig. 5.13, che prende gli stessi argomenti della precedente, con lo stesso significato, a cui si aggiun-
gono i valori per il soft limit e l’hard limit. In questo caso occorrerà, prima di chiamare quotactl,
inizializzare opportunamente (5-7) i campi della struttura dqblk che si vogliono utilizzare (quelli
relativi ai limiti sui blocchi) e specificare gli stessi con QIF_BLIMITS in dq.dqb_valid.
Fatto questo la chiamata a quotactl, stavolta con il comando Q_SETQUOTA, viene eseguita
come in precedenza all’interno di un condizionale (9-14). In questo caso non essendovi da re-
stituire nessun dato in caso di successo si usa (10) una apposita funzione di uscita, mentre si
restituisce come prima una eccezione con il valore di errno in caso di errore (12-13).
5.4.4 La gestione delle capabilities
Come accennato in sez. 3.3.1 l’architettura classica della gestione dei privilegi in un sistema
unix-like ha il sostanziale problema di fornire all’amministratore dei poteri troppo ampi, questo
comporta che anche quando si siano predisposte delle misure di protezione per in essere in grado
di difendersi dagli effetti di una eventuale compromissione del sistema,89 una volta che questa sia
stata effettuata e si siano ottenuti i privilegi di amministratore, queste potranno essere comunque
rimosse.90
Il problema consiste nel fatto che nell’architettura tradizionale di un sistema unix-like i
controlli di accesso sono basati su un solo livello di separazione: per i processi normali essi sono
posti in atto, mentre per i processi con i privilegi di amministratore essi non vengono neppure
eseguiti; per questo motivo non era previsto alcun modo per evitare che un processo con diritti
di amministratore non potesse eseguire certe operazioni, o per cedere definitivamente alcuni
privilegi da un certo momento in poi.
Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato introdotto un meccani-
smo, detto capabilities, che consentisse di suddividere i vari privilegi tradizionalmente associati
89
come montare un filesystem in sola lettura per impedirne modifiche, o marcare un file come immutabile.
90
nei casi elencati nella precedente nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere la
marcatura di immutabilità.

all’amministratore in un insieme di capacità distinte. L’idea era che queste capacità potessero
essere abilitate e disabilitate in maniera indipendente per ciascun processo con privilegi di am-
ministratore, permettendo cos`ı una granularità molto più fine nella distribuzione degli stessi che
evitasse la originaria situazione di “tutto o nulla”.
Il meccanismo completo delle capabilities91 prevede inoltre la possibilità di associare le stesse
ai singoli file eseguibili, in modo da poter stabilire quali capacità possono essere utilizzate quando
viene messo in esecuzione uno specifico programma; ma il supporto per questa funzionalità,
chiamata file capabilities, è stato introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora
doveva essere il programma stesso ad eseguire una riduzione esplicita delle sue capacità, cosa
che ha reso l’uso di questa funzionalità poco diffuso, vista la presenza di meccanismi alternativi
per ottenere limitazioni delle capacità dell’amministratore a livello di sistema operativo, come
SELinux.
Con questo supporto e con le ulteriori modifiche introdotte con il kernel 2.6.25 il meccanismo
delle capabilities è stato totalmente rivoluzionato, rendendolo più aderente alle intenzioni origi-
nali dello standard POSIX, rimuovendo il significato che fino ad allora aveva avuto la capacità
CAP_SETPCAP e cambiando le modalità di funzionamento del cosiddetto capabilities bounding set.
Ulteriori modifiche sono state apportate con il kernel 2.6.26 per consentire la rimozione non
ripristinabile dei privilegi di amministratore. Questo fa s`ı che il significato ed il comportamento
del kernel finisca per dipendere dalla versione dello stesso e dal fatto che le nuove file capabilities
siano abilitate o meno. Per capire meglio la situazione e cosa è cambiato conviene allora spiegare
con maggiori dettagli come funziona il meccanismo delle capabilities.
Il primo passo per frazionare i privilegi garantiti all’amministratore, supportato fin dalla
introduzione iniziale del kernel 2.2, è stato quello in cui a ciascun processo sono stati associati
tre distinti insiemi di capabilities, denominati rispettivamente permitted, inheritable ed effective.
Questi insiemi vengono mantenuti in forma di tre diverse maschere binarie,92 in cui ciascun bit
corrisponde ad una capacità diversa.
L’utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile per l’uso delle ca-
pabilities, con scopi analoghi a quelli per cui sono mantenuti i diversi insiemi di identificatori
di sez. 3.3.2; il loro significato, che è rimasto sostanzialmente lo stesso anche dopo le modifiche
seguite alla introduzione delle file capabilities è il seguente:
permitted l’insieme delle capabilities “permesse”, cioè l’insieme di quelle capacità che un pro-
cesso può impostare come effettive o come ereditabili. Se un processo cancella una
capacità da questo insieme non potrà più riassumerla.93
inheritable l’insieme delle capabilities “ereditabili”, cioè di quelle che verranno trasmesse come
insieme delle permesse ad un nuovo programma eseguito attraverso una chiamata
ad exec.
effective l’insieme delle capabilities “effettive”, cioè di quelle che vengono effettivamente
usate dal kernel quando deve eseguire il controllo di accesso per le varie operazioni
compiute dal processo.
Con l’introduzione delle file capabilities sono stati introdotti altri tre insiemi associabili a
ciascun file.94 Le file capabilities hanno effetto soltanto quando il file che le porta viene eseguito
91
l’implementazione si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e, poi abbandonato.
92
il kernel li mantiene, come i vari identificatori di sez. 3.3.2, all’interno della task_struct di ciascun processo
(vedi fig. 3.2), nei tre campi cap_effective, cap_inheritable, cap_permitted del tipo kernel_cap_t; questo
era, fino al kernel 2.6.25 definito come intero a 32 bit per un massimo di 32 capabilities distinte, attualmente è
stato aggiornato ad un vettore in grado di mantenerne fino a 64.
93
questo nei casi ordinari, sono previste però una serie di eccezioni, dipendenti anche dal tipo di supporto, che
vedremo meglio in seguito dato il notevole intreccio nella casistica.
94
la realizzazione viene eseguita con l’uso di uno specifico attributo esteso, security.capability, la cui modifica
è riservata, (come illustrato in sez. 5.4.1) ai processi dotato della capacità CAP_SYS_ADMIN.

come programma con una exec, e forniscono un meccanismo che consente l’esecuzione dello
stesso con maggiori privilegi; in sostanza sono una sorta di estensione del suid bit limitato ai
privilegi di amministratore. Anche questi tre insiemi sono identificati con gli stessi nomi di quello
dei processi, ma il loro significato è diverso:
permitted (chiamato originariamente forced) l’insieme delle capacità che con l’esecuzione del
programma verranno aggiunte alle capacità permesse del processo.
inheritable (chiamato originariamente allowed) l’insieme delle capacità che con l’esecuzione del
programma possono essere ereditate dal processo originario (che cioè non vengono
tolte dall’inheritable set del processo originale all’esecuzione di exec).
effective in questo caso non si tratta di un insieme ma di un unico valore logico; se attivo al-
l’esecuzione del programma tutte le capacità che risulterebbero permesse verranno
pure attivate, inserendole automaticamente nelle effettive, se disattivato nessuna
capacità verrà attivata (cioè l’effective set resterà vuoto).
Infine come accennato, esiste un ulteriore insieme, chiamato capabilities bounding set, il cui
scopo è quello di costituire un limite alle capacità che possono essere attivate per un programma.
Il suo funzionamento però è stato notevolmente modificato con l’introduzione delle file capabilities
e si deve pertanto prendere in considerazione una casistica assai complessa.
Per i kernel fino al 2.6.25, o se non si attiva il supporto per le file capabilities, il capa-
bilities bounding set è un parametro generale di sistema, il cui valore viene riportato nel file
/proc/sys/kernel/cap-bound. Il suo valore iniziale è definito in sede di compilazione del kernel,
e da sempre ha previsto come default la presenza di tutte le capabilities eccetto CAP_SETPCAP.
In questa situazione solo il primo processo eseguito nel sistema (quello con pid 1, di norma
/sbin/init) ha la possibilità di modificarlo; ogni processo eseguito successivamente, se dotato
dei privilegi di amministratore, è in grado soltanto di rimuovere una delle capabilities già presenti
dell’insieme.95
In questo caso l’effetto complessivo del capabilities bounding set è che solo le capacità in
esso presenti possono essere trasmesse ad un altro programma attraverso una exec. Questo in
sostanza significa che se un qualunque programma elimina da esso una capacità, considerato che
init (almeno nelle versioni ordinarie) non supporta la reimpostazione del bounding set, questa
non sarà più disponibile per nessun processo a meno di un riavvio, eliminando cos`ı in forma
definitiva quella capacità per tutti, compreso l’amministratore.96
Con il kernel 2.6.25 e le file capabilities il bounding set è diventato una proprietà di ciascun
processo, che viene propagata invariata sia attraverso una fork che una exec. In questo caso il file
/proc/sys/kernel/cap-bound non esiste e init non ha nessun ruolo speciale, inoltre in questo
caso all’avvio il valore iniziale prevede la presenza di tutte le capacità (compresa CAP_SETPCAP).
Con questo nuovo meccanismo il bounding set continua a ricoprire un ruolo analogo al prece-
dente nel passaggio attraverso una exec, come limite alle capacità che possono essere aggiunte
al processo in quanto presenti nel permitted set del programma messo in esecuzione, in sostanza
il nuovo programma eseguito potrà ricevere una capacità presente nel suo permitted set (quello
del file) solo se questa è anche nel bounding set (del processo). In questo modo si possono ri-
muovere definitivamente certe capacità da un processo, anche qualora questo dovesse eseguire
un programma privilegiato che prevede di riassegnarle.
Si tenga presente però che in questo caso il bounding set blocca esclusivamente le capacità
indicate nel permitted set del programma che verrebbero attivate in caso di esecuzione, e non
quelle eventualmente già presenti nell’inheritable set del processo (ad esempio perché presenti
95
per essere precisi occorreva la capacità CAP_SYS_MODULE.
96
la qual cosa, visto il default usato per il capabilities bounding set, significa anche che CAP_SETPCAP non è stata
praticamente mai usata nella sua forma originale.

prima di averle rimosse dal bounding set). In questo caso eseguendo un programma che abbia
anche lui dette capacità nel suo inheritable set queste verrebbero assegnate.
In questa seconda versione inoltre il bounding set costituisce anche un limite per le capacità
che possono essere aggiunte all’inheritable set del processo stesso con capset, sempre nel senso
che queste devono essere presenti nel bounding set oltre che nel permitted set del processo.
Questo limite vale anche per processi con i privilegi di amministratore,97 per i quali invece non
vale la condizione che le capabilities da aggiungere nell’inheritable set debbano essere presenti
nel proprio permitted set.98
Come si può notare per fare ricorso alle capabilities occorre comunque farsi carico di una
notevole complessità di gestione, aggravata dalla presenza di una radicale modifica del loro
funzionamento con l’introduzione delle file capabilities. Considerato che il meccanismo originale
era incompleto e decisamente problematico nel caso di programmi che non ne sapessero tener
conto,99 ci soffermeremo solo sulla implementazione completa presente a partire dal kernel 2.6.25,
tralasciando ulteriori dettagli riguardo la versione precedente.
Riassumendo le regole finora illustrate tutte le capabilities vengono ereditate senza modifiche
attraverso una fork mentre, indicati con orig_* i valori degli insiemi del processo chiamante,
con file_* quelli del file eseguito e con bound_set il capabilities bounding set, dopo l’invocazione
di exec il processo otterrà dei nuovi insiemi di capacità new_* secondo la formula (espressa in
pseudo-codice C) di fig. 5.14; si noti come in particolare il capabilities bounding set non viene
comunque modificato e resta lo stesso sia attraverso una fork che attraverso una exec.
new_perm = ( orig_inh & file_inh ) | ( file_perm & bound_set) ;
new_inh = orig_inh ;
new_eff = file_eff ? new_perm : 0 ;
new_bound_set = bound_set ;
Figura 5.14: Espressione della modifica delle capabilities attraverso una exec.
A queste regole se ne aggiungono delle altre che servono a riprodurre il comportamento
tradizionale di un sistema unix-like in tutta una serie di circostanze. La prima di queste è
relativa a quello che avviene quando si esegue un file senza capabilities; se infatti si considerasse
questo equivalente al non averne assegnata alcuna, non essendo presenti capacità né nel permitted
set né nell’inheritable set del file, nell’esecuzione di un qualunque programma l’amministratore
perderebbe tutti i privilegi originali dal processo.
Per questo motivo se un programma senza capabilities assegnate viene eseguito da un processo
con real user-ID 0, esso verrà trattato come se tanto il permitted set che l’inheritable set fossero
con tutte le capabilities abilitate, con l’effective set attivo, col risultato di fornire comunque al
processo tutte le capacità presenti nel proprio bounding set. Lo stesso avviene quando l’eseguibile
ha attivo il suid bit ed appartiene all’amministratore, in entrambi i casi si riesce cos`ı a riottenere
il comportamento classico di un sistema unix-like.
Una seconda circostanza è quella relativa a cosa succede alle capabilities di un processo nelle
possibili transizioni da user-ID nullo a user-ID non nullo o viceversa (corrispondenti rispettiva-
mente a cedere o riottenere i i privilegi di amministratore) che si possono effettuare con le varie
funzioni viste in sez. 3.3.2. In questo caso la casistica è di nuovo alquanto complessa, considerata
anche la presenza dei diversi gruppi di identificatori illustrati in tab. 3.7, si avrà allora che:
97
si tratta sempre di avere la capability CAP_SETPCAP.
98
lo scopo anche in questo caso è ottenere una rimozione definitiva della possibilità di passare una capacità
rimossa dal bounding set.
99
c’è stato un grosso problema di sicurezza con sendmail, riuscendo a rimuovere CAP_SETGID dall’inheritable set
di un processo si ottenne di far fallire setuid in maniera inaspettata per il programma (che aspettandosi sempre il
successo della funzione non ne controllava lo stato di uscita) con la conseguenza di effettuare come amministratore
operazioni che altrimenti sarebbero state eseguite, senza poter apportare danni, da utente normale.

1. se si passa da effective user-ID nullo a non nullo l’effective set del processo viene totalmente
azzerato, se viceversa si passa da effective user-ID non nullo a nullo il permitted set viene
copiato nell’effective set;
2. se si passa da file system user-ID nullo a non nullo verranno cancellate dall’effective set
del processo tutte le capacità attinenti i file, e cioè CAP_LINUX_IMMUTABLE, CAP_MKNOD,
CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_MAC_OVERRIDE, CAP_CHOWN, CAP_FSETID
e CAP_FOWNER (le prime due a partire dal kernel 2.2.30), nella transizione inversa verranno
invece inserite nell’effective set quelle capacità della precedente lista che sono presenti nel
suo permitted set.
3. se come risultato di una transizione riguardante gli identificativi dei gruppi real, saved ed
effective in cui si passa da una situazione in cui uno di questi era nullo ad una in cui sono
tutti non nulli,100 verranno azzerati completamente sia il permitted set che l’effective set.
La combinazione di tutte queste regole consente di riprodurre il comportamento ordinario di
un sistema di tipo Unix tradizionale, ma può risultare problematica qualora si voglia passare ad
una configurazione di sistema totalmente basata sull’applicazione delle capabilities; in tal caso
infatti basta ad esempio eseguire un programma con suid bit di proprietà dell’amministratore
per far riottenere ad un processo tutte le capacità presenti nel suo bounding set, anche se si era
avuta la cura di cancellarle dal permitted set.
Per questo motivo a partire dal kernel 2.6.26, se le file capabilities sono abilitate, ad ogni
processo viene stata associata una ulteriore maschera binaria, chiamata securebits flags, su cui
sono mantenuti una serie di flag (vedi tab. 5.19) il cui valore consente di modificare que-
ste regole speciali che si applicano ai processi con user-ID nullo. La maschera viene sempre
mantenuta attraverso una fork, mentre attraverso una exec viene sempre cancellato il flag
SECURE_KEEP_CAPS.
Flag Descrizione
SECURE_KEEP_CAPS Il processo non subisce la cancellazione delle sue capabilities quando
tutti i suoi user-ID passano ad un valore non nullo (regola di compa-
tibilità per il cambio di user-ID n. 3 del precedente elenco), sostituisce
il precedente uso dell’operazione PR_SET_KEEPCAPS di prctl.
SECURE_NO_SETUID_FIXUP Il processo non subisce le modifiche delle sue capabilities nel passaggio
da nullo a non nullo degli user-ID dei gruppi effective e file system
(regole di compatibilità per il cambio di user-ID nn. 1 e 2 del precedente
elenco).
SECURE_NOROOT Il processo non assume nessuna capacità aggiuntiva quando esegue un
programma, anche se ha user-ID nullo o il programma ha il suid bit
attivo ed appartiene all’amministratore (regola di compatibilità per
l’esecuzione di programmi senza capabilities).
Tabella 5.19: Costanti identificative dei flag che compongono la maschera dei securebits.
A ciascuno dei flag di tab. 5.19 è inoltre abbinato un corrispondente flag di blocco, identi-
ficato da una costante omonima con l’estensione _LOCKED, la cui attivazione è irreversibile ed
ha l’effetto di rendere permanente l’impostazione corrente del corrispondente flag ordinario; in
sostanza con SECURE_KEEP_CAPS_LOCKED si rende non più modificabile SECURE_KEEP_CAPS, ed
analogamente avviene con SECURE_NO_SETUID_FIXUP_LOCKED per SECURE_NO_SETUID_FIXUP e
con SECURE_NOROOT_LOCKED per SECURE_NOROOT.
Per l’impostazione di questi flag sono stata predisposte due specifiche operazioni di prctl
(vedi sez. 3.5.2), PR_GET_SECUREBITS, che consente di ottenerne il valore, e PR_SET_SECUREBITS,
che consente di modificarne il valore; per quest’ultima sono comunque necessari i privilegi di
amministratore ed in particolare la capacità CAP_SETPCAP. Prima dell’introduzione dei securebits
100
in sostanza questo è il caso di quando si chiama setuid per rimuovere definitivamente i privilegi di
amministratore da un processo.

era comunque possibile ottenere lo stesso effetto di SECURE_KEEP_CAPS attraverso l’uso di un’altra
operazione di prctl, PR_SET_KEEPCAPS.
Oltre alla gestione dei securebits la nuova versione delle file capabilities prevede l’uso di
prctl anche per la gestione del capabilities bounding set, attraverso altre due operazioni dedicate,
PR_CAPBSET_READ per controllarne il valore e PR_CAPBSET_DROP per modificarlo; quest’ultima
di nuovo è una operazione privilegiata che richiede la capacità CAP_SETPCAP e che, come indica
chiaramente il nome, permette solo la rimozione di una capability dall’insieme; per i dettagli
sull’uso di tutte queste operazioni si rimanda alla rilettura di sez. 3.5.2.
Un elenco delle delle capabilities disponibili su Linux, con una breve descrizione ed il nome
delle costanti che le identificano, è riportato in tab. 5.20;101 la tabella è divisa in due parti,
la prima riporta le capabilities previste anche nella bozza dello standard POSIX1.e, la seconda
quelle specifiche di Linux. Come si può notare dalla tabella alcune capabilities attengono a
singole funzionalità e sono molto specializzate, mentre altre hanno un campo di applicazione
molto vasto, che è opportuno dettagliare maggiormente.
Prima di dettagliare il significato della capacità più generiche, conviene però dedicare un
discorso a parte a CAP_SETPCAP, il cui significato è stato completamente cambiato con l’intro-
duzione delle file capabilities nel kernel 2.6.24. In precedenza questa capacità era quella che
permetteva al processo che la possedeva di impostare o rimuovere le capabilities che fossero pre-
senti nel permitted set del chiamante di un qualunque altro processo. In realtà questo non è mai
stato l’uso inteso nelle bozze dallo standard POSIX, ed inoltre, come si è già accennato, dato
che questa capacità è assente nel capabilities bounding set usato di default, essa non è neanche
mai stata realmente disponibile.
Con l’introduzione file capabilities e il cambiamento del significato del capabilities bounding
set la possibilità di modificare le capacità di altri processi è stata completamente rimossa, e
CAP_SETPCAP ha acquisito quello che avrebbe dovuto essere il suo significato originario, e cioè
la capacità del processo di poter inserire nel suo inheritable set qualunque capacità presente
nel bounding set. Oltre a questo la disponibilità di CAP_SETPCAP consente ad un processo di
eliminare una capacità dal proprio bounding set (con la conseguente impossibilità successiva di
eseguire programmi con quella capacità), o di impostare i securebits delle capabilities.
La prima fra le capacità “ampie” che occorre dettagliare maggiormente è CAP_FOWNER, che
rimuove le restrizioni poste ad un processo che non ha la proprietà di un file in un vasto campo di
operazioni;103 queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi sez. 5.3.3
e sez. 5.2.4), le impostazioni degli attributi dei file (vedi sez. 6.3.7) e delle ACL (vedi sez. 5.4.1
e 5.4.2), poter ignorare lo sticky bit nella cancellazione dei file (vedi sez. 5.3.2), la possibilità di
impostare il flag di O_NOATIME con open e fcntl (vedi sez. 6.2.1 e sez. 6.3.6) senza restrizioni.
Una seconda capacità che copre diverse operazioni, in questo caso riguardanti la rete, è
CAP_NET_ADMIN, che consente di impostare le opzioni privilegiate dei socket (vedi sez. 17.2.2),
abilitare il multicasting, eseguire la configurazione delle interfacce di rete (vedi sez. 17.3.2) ed
impostare la tabella di instradamento.
Una terza capability con vasto campo di applicazione è CAP_SYS_ADMIN, che copre una serie di
operazioni amministrative, come impostare le quote disco (vedi sez.5.4.3), attivare e disattivare la
swap, montare, rimontare e smontare filesystem (vedi sez. 8.2.2), effettuare operazioni di controllo
su qualunque oggetto dell’IPC di SysV (vedi sez. 11.2), operare sugli attributi estesi dei file di
classe security o trusted (vedi sez. 5.4.1), specificare un user-ID arbitrario nella trasmissione
delle credenziali dei socket (vedi sez. ??), assegnare classi privilegiate (IOPRIO_CLASS_RT e prima
101
l’elenco presentato questa tabella, ripreso dalla pagina di manuale (accessibile con man capabilities) e dalle
definizioni in linux/capabilities.h, è aggiornato al kernel 2.6.26.
102
vale a dire i permessi caratteristici del modello classico del controllo di accesso chiamato Discrectionary Access
Control (da cui il nome DAC).
103
vale a dire la richiesta che l’user-ID effettivo del processo (o meglio il filesystem user-ID, vedi sez. 3.3.2)
coincida con quello del proprietario.

Capacità Descrizione
CAP_AUDIT_CONTROL La capacità di abilitare e disabilitare il controllo dell’auditing (dal kernel 2.6.11).
CAP_AUDIT_WRITE La capacità di scrivere dati nel giornale di auditing del kernel (dal kernel 2.6.11).
CAP_CHOWN La capacità di cambiare proprietario e gruppo proprietario di un file (vedi sez. 5.3.4).
CAP_DAC_OVERRIDE La capacità di evitare il controllo dei permessi di lettura, scrittura ed esecuzione dei
file,102
(vedi sez. 5.3).
CAP_DAC_READ_SEARCH La capacità di evitare il controllo dei permessi di lettura ed esecuzione per le directory
(vedi sez. 5.3).
CAP_FOWNER La capacità di evitare il controllo della proprietà di un file per tutte le operazioni
privilegiate non coperte dalle precedenti CAP_DAC_OVERRIDE e CAP_DAC_READ_SEARCH.
CAP_FSETID La capacità di evitare la cancellazione automatica dei bit suid e sgid quando un file
per i quali sono impostati viene modificato da un processo senza questa capacità e
la capacità di impostare il bit sgid su un file anche quando questo è relativo ad un
gruppo cui non si appartiene (vedi sez. 5.3.3).
CAP_KILL La capacità di mandare segnali a qualunque processo (vedi sez. 9.3.3).
CAP_SETFCAP La capacità di impostare le capabilities di un file (dal kernel 2.6.24).
CAP_SETGID La capacità di manipolare i group ID dei processi, sia il principale che i supplementari,
(vedi sez. 3.3.3) che quelli trasmessi tramite i socket unix domain (vedi sez. 18.2).
CAP_SETUID La capacità di manipolare gli user ID del processo (vedi sez. 3.3.2) e di trasmettere
un user ID arbitrario nel passaggio delle credenziali coi socket unix domain (vedi
sez. 18.2).
CAP_IPC_LOCK La capacità di effettuare il memory locking con le funzioni mlock, mlockall, shmctl,
mmap (vedi sez. 2.2.4 e sez. 12.4.1).
CAP_IPC_OWNER La capacità di evitare il controllo dei permessi per le operazioni sugli oggetti di
intercomunicazione fra processi (vedi sez. 11.2).
CAP_LEASE La capacità di creare dei file lease (vedi sez. 12.3.2) pur non essendo proprietari del
file (dal kernel 2.4).
CAP_LINUX_IMMUTABLE La capacità di impostare sui file gli attributi immutable e append only (se supportati).
CAP_MKNOD La capacità di creare file di dispositivo con mknod (vedi sez. 5.1.5) (dal kernel 2.4).
CAP_NET_ADMIN La capacità di eseguire alcune operazioni privilegiate sulla rete.
CAP_NET_BIND_SERVICE La capacità di porsi in ascolto su porte riservate (vedi sez. 16.2.1).
CAP_NET_BROADCAST La capacità di consentire l’uso di socket in broadcast e multicast.
CAP_NET_RAW La capacità di usare socket RAW e PACKET (vedi sez. 15.2.3).
CAP_SETPCAP La capacità di modifiche privilegiate alle capabilities.
CAP_SYS_ADMIN La capacità di eseguire una serie di compiti amministrativi.
CAP_SYS_BOOT La capacità di fare eseguire un riavvio del sistema (vedi sez. ??).
CAP_SYS_CHROOT La capacità di eseguire la funzione chroot (vedi sez. 5.4.5).
CAP_MAC_ADMIN La capacità amministrare il Mandatory Access Control di Smack (dal kernel 2.6.25).
CAP_MAC_OVERRIDE La capacità evitare il Mandatory Access Control di Smack (dal kernel 2.6.25).
CAP_SYS_MODULE La capacità di caricare e rimuovere moduli del kernel.
CAP_SYS_NICE La capacità di modificare le varie priorità dei processi (vedi sez. 3.4).
CAP_SYS_PACCT La capacità di usare le funzioni di accounting dei processi (vedi sez. 8.3.4).
CAP_SYS_PTRACE La capacità di tracciare qualunque processo con ptrace (vedi sez. 3.5.3).
CAP_SYS_RAWIO La capacità di operare sulle porte di I/O con ioperm e iopl (vedi sez. 3.5.4).
CAP_SYS_RESOURCE La capacità di superare le varie limitazioni sulle risorse.
CAP_SYS_TIME La capacità di modificare il tempo di sistema (vedi sez. 8.4).
CAP_SYS_TTY_CONFIG La capacità di simulare un hangup della console, con la funzione vhangup.
CAP_SYSLOG La capacità di gestire il buffer dei messaggi del kernel, (vedi sez. 10.1.5), introdotta
dal kernel 2.6.38 come capacità separata da CAP_SYS_ADMIN.
CAP_WAKE_ALARM La capacità di usare i timer di tipo CLOCK_BOOTTIME_ALARM e CLOCK_REALTIME_ALARM,
vedi sez. 9.5.2 (dal kernel 3.0).
Tabella 5.20: Le costanti che identificano le capabilities presenti nel kernel.

del kernel 2.6.25 anche IOPRIO_CLASS_IDLE) per lo scheduling dell’I/O (vedi sez. 3.4.5), superare
il limite di sistema sul numero massimo di file aperti,104 effettuare operazioni privilegiate sulle
chiavi mantenute dal kernel (vedi sez. ??), usare la funzione lookup_dcookie, usare CLONE_NEWNS
con unshare e clone, (vedi sez. 3.5.1).
Originariamente CAP_SYS_NICE riguardava soltanto la capacità di aumentare le priorità di
esecuzione dei processi, come la diminuzione del valore di nice (vedi sez. 3.4.2), l’uso delle priorità
real-time (vedi sez. 3.4.3), o l’impostazione delle affinità di processore (vedi sez. 3.4.4); ma con
l’introduzione di priorità anche riguardo le operazioni di accesso al disco, e, nel caso di sistemi
NUMA, alla memoria, essa viene a coprire anche la possibilità di assegnare priorità arbitrarie
nell’accesso a disco (vedi sez. 3.4.5) e nelle politiche di allocazione delle pagine di memoria ai
nodi di un sistema NUMA.
Infine la capability CAP_SYS_RESOURCE attiene alla possibilità di superare i limiti imposti
sulle risorse di sistema, come usare lo spazio disco riservato all’amministratore sui filesystem
che lo supportano, usare la funzione ioctl per controllare il journaling sul filesystem ext3, non
subire le quote disco, aumentare i limiti sulle risorse di un processo (vedi sez. 8.3.2) e quelle
sul numero di processi, ed i limiti sulle dimensioni dei messaggi delle code del SysV IPC (vedi
sez. 11.2.4).
Per la gestione delle capabilities il kernel mette a disposizione due funzioni che permettono
rispettivamente di leggere ed impostare i valori dei tre insiemi illustrati in precedenza. Queste
due funzioni sono capget e capset e costituiscono l’interfaccia di gestione basso livello; i loro
#include <sys/capability.h>
int capget(cap_user_header_t hdrp, cap_user_data_t datap)
Legge le capabilities.
int capset(cap_user_header_t hdrp, const cap_user_data_t datap)
Imposta le capabilities.
Entrambe le funzioni ritornano 0 in caso di successo e -1 in caso di errore, nel qual caso errno
può assumere i valori:
ESRCH si è fatto riferimento ad un processo inesistente.
EPERM si è tentato di aggiungere una capacità nell’insieme delle capabilities permesse, o di
impostare una capacità non presente nell’insieme di quelle permesse negli insieme delle
effettive o ereditate, o si è cercato di impostare una capability di un altro processo
senza avare CAP_SETPCAP.
ed inoltre EFAULT ed EINVAL.
Queste due funzioni prendono come argomenti due tipi di dati dedicati, definiti come pun-
tatori a due strutture specifiche di Linux, illustrate in fig. 5.15. Per un certo periodo di tempo
era anche indicato che per poterle utilizzare fosse necessario che la macro _POSIX_SOURCE risul-
tasse non definita (ed era richiesto di inserire una istruzione #undef _POSIX_SOURCE prima di
includere sys/capability.h) requisito che non risulta più presente.105
Si tenga presente che le strutture di fig. 5.15, come i prototipi delle due funzioni capget e
capset, sono soggette ad essere modificate con il cambiamento del kernel (in particolare i tipi
di dati delle strutture) ed anche se finora l’interfaccia è risultata stabile, non c’è nessuna assi-
curazione che questa venga mantenuta,106 Pertanto se si vogliono scrivere programmi portabili
che possano essere eseguiti senza modifiche o adeguamenti su qualunque versione del kernel è
opportuno utilizzare le interfacce di alto livello che vedremo più avanti.
La struttura a cui deve puntare l’argomento hdrp serve ad indicare, tramite il campo pid, il
PID del processo del quale si vogliono leggere o modificare le capabilities. Con capset questo,
104
quello indicato da /proc/sys/fs/file-max.
105
e non è chiaro neanche quanto sia mai stato davvero necessario.
106
viene però garantito che le vecchie funzioni continuino a funzionare.

#define _LINUX_CAPABILITY_VERSION_1 0x19980330
#define _LINUX_CAPABILITY_U32S_1 1
#define _LINUX_CAPABILITY_VERSION_2 0x20071026 /* deprecated - use v3 */
#define _LINUX_CAPABILITY_VERSION_3 0x20080522
typedef struct __user_cap_header_struct {
__u32 version;
int pid;
} * cap_user_header_t ;
typedef struct __user_cap_data_struct {
__u32 effective;
__u32 permitted;
__u32 inheritable;
} *cap_user_data_t;
Figura 5.15: Definizione delle strutture a cui fanno riferimento i puntatori cap_user_header_t e
cap_user_data_t usati per l’interfaccia di gestione di basso livello delle capabilities.
se si usano le file capabilities, può essere solo 0 o PID del processo chiamante, che sono equi-
valenti. Il campo version deve essere impostato al valore della versione delle stesse usata dal
kernel (quello indicato da una delle costanti _LINUX_CAPABILITY_VERSION_n di fig. 5.15) altri-
menti le funzioni ritorneranno con un errore di EINVAL, restituendo nel campo stesso il valore
corretto della versione in uso. La versione due è comunque deprecata e non deve essere usata
(il kernel stamperà un avviso). I valori delle capabilities devono essere passati come maschere
binarie;107 con l’introduzione delle capabilities a 64 bit inoltre il puntatore datap non può essere
più considerato come relativo ad una singola struttura, ma ad un vettore di due strutture.108
Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non garantiscono la
stabilità nell’interfaccia, è sempre opportuno effettuare la gestione delle capabilities utilizzando
le funzioni di libreria a questo dedicate. Queste funzioni, che seguono quanto previsto nelle bozze
dello standard POSIX.1e, non fanno parte delle glibc e sono fornite in una libreria a parte,109
pertanto se un programma le utilizza si dovrà indicare esplicitamente l’uso della suddetta libreria
attraverso l’opzione -lcap del compilatore.
Le funzioni dell’interfaccia delle bozze di POSIX.1e prevedono l’uso di uno tipo di dato opaco,
cap_t, come puntatore ai dati mantenuti nel cosiddetto capability state,110 in sono memorizzati
tutti i dati delle capabilities. In questo modo è possibile mascherare i dettagli della gestione di
basso livello, che potranno essere modificati senza dover cambiare le funzioni dell’interfaccia,
che faranno riferimento soltanto ad oggetti di questo tipo. L’interfaccia pertanto non soltanto
fornisce le funzioni per modificare e leggere le capabilities, ma anche quelle per gestire i dati
attraverso cap_t.
La prima funzione dell’interfaccia è quella che permette di inizializzare un capability state,
107
e si tenga presente che i valori di tab. 5.20 non possono essere combinati direttamente, indicando il numero
progressivo del bit associato alla relativa capacità.
108
è questo cambio di significato che ha portato a deprecare la versione 2, che con capget poteva portare ad
un buffer overflow per vecchie applicazioni che continuavano a considerare datap come puntatore ad una singola
struttura.
109
la libreria è libcap2, nel caso di Debian può essere installata con il pacchetto omonimo.
110
si tratta in sostanza di un puntatore ad una struttura interna utilizzata dalle librerie, i cui campi non devono
mai essere acceduti direttamente.

allocando al contempo la memoria necessaria per i relativi dati. La funzione è cap_init ed il
suo prototipo è:
cap_t cap_init(void)
Crea ed inizializza un capability state.
La funzione ritorna un valore non nullo in caso di successo e NULL in caso di errore, nel qual caso
errno assumerà il valore ENOMEM.
La funzione restituisce il puntatore cap_t ad uno stato inizializzato con tutte le capabilities
azzerate. In caso di errore (cioè quando non c’è memoria sufficiente ad allocare i dati) viene resti-
tuito NULL ed errno viene impostata a ENOMEM. La memoria necessaria a mantenere i dati viene
automaticamente allocata da cap_init, ma dovrà essere disallocata esplicitamente quando non
è più necessaria utilizzando, per questo l’interfaccia fornisce una apposita funzione, cap_free,
int cap_free(void *obj_d)
Disalloca la memoria allocata per i dati delle capabilities.
La funzione ritorna 0 in caso di successo e −1 in caso di errore, nel qual caso errno assumerà il
valore EINVAL.
La funzione permette di liberare la memoria allocata dalle altre funzioni della libreria sia per
un capability state, nel qual caso l’argomento dovrà essere un dato di tipo cap_t, che per una
descrizione testuale dello stesso,111 nel qual caso l’argomento dovrà essere un dato di tipo char
*. Per questo motivo l’argomento obj_d è dichiarato come void * e deve sempre corrispondere
ad un puntatore ottenuto tramite le altre funzioni della libreria, altrimenti la funzione fallirà
con un errore di EINVAL.
Infine si può creare una copia di un capability state ottenuto in precedenza tramite la funzione
cap_dup, il cui prototipo è:
cap_t cap_dup(cap_t cap_p)
Duplica un capability state restituendone una copia.
La funzione ritorna un valore non nullo in caso di successo e NULL in caso di errore, nel qual caso
errno potrà assumere i valori ENOMEM o EINVAL.
La funzione crea una copia del capability state posto all’indirizzo cap_p che si è passato
come argomento, restituendo il puntatore alla copia, che conterrà gli stessi valori delle capabi-
lities presenti nell’originale. La memoria necessaria viene allocata automaticamente dalla fun-
zione. Una volta effettuata la copia i due capability state potranno essere modificati in maniera
completamente indipendente.112
Una seconda classe di funzioni di servizio previste dall’interfaccia sono quelle per la gestio-
ne dei dati contenuti all’interno di un capability state; la prima di queste è cap_clear, il cui
prototipo è:
int cap_clear(cap_t cap_p)
Inizializza un capability state cancellando tutte le capabilities.
valore EINVAL.
La funzione si limita ad azzerare tutte le capabilities presenti nel capability state all’indirizzo
cap_p passato come argomento, restituendo uno stato vuoto, analogo a quello che si ottiene nella
creazione con cap_init.
111
cioè quanto ottenuto tramite la funzione cap_to_text.
112
alla fine delle operazioni si ricordi però di disallocare anche la copia, oltre all’originale.

Valore Significato
CAP_EFFECTIVE Capacità dell’insieme effettivo.
CAP_PERMITTED Capacità dell’insieme permesso.
CAP_INHERITABLE Capacità dell’insieme ereditabile.
Tabella 5.21: Valori possibili per il tipo di dato cap_flag_t che identifica gli insiemi delle capabilities.
Una variante di cap_clear è cap_clear_flag che cancella da un capability state tutte le
capabilities di un certo insieme fra quelli di pag. 166, il suo prototipo è:
int cap_clear_flag(cap_t cap_p, cap_flag_t flag)
Cancella dal capability state cap_p tutte le capabilities dell’insieme flag.
valore EINVAL.
La funzione richiede che si indichi quale degli insiemi si intente cancellare con l’argomento
flag. Questo deve essere specificato con una variabile di tipo cap_flag_t che può assumere
esclusivamente113 uno dei valori illustrati in tab. 5.21.
Si possono inoltre confrontare in maniera diretta due diversi capability state con la funzione
cap_compare; il suo prototipo è:
int cap_compare(cap_t cap_a, cap_t cap_b)
Confronta due capability state.
La funzione ritorna 0 se i capability state sono identici ed un valore positivo se differiscono, non
sono previsti errori.
La funzione esegue un confronto fra i due capability state passati come argomenti e ritorna in
un valore intero il risultato, questo è nullo se sono identici o positivo se vi sono delle differenze.
Il valore di ritorno della funzione consente inoltre di per ottenere ulteriori informazioni su quali
sono gli insiemi di capabilities che risultano differenti. Per questo si può infatti usare la apposita
macro CAP_DIFFERS:
int CAP_DIFFERS(value, flag)
Controlla lo stato di eventuali differenze delle capabilities nell’insieme flag.
La macro che richiede si passi nell’argomento value il risultato della funzione cap_compare
e in flag l’indicazione (coi valori di tab. 5.21) dell’insieme che si intende controllare; restituirà
un valore diverso da zero se le differenze rilevate da cap_compare sono presenti nell’insieme
indicato.
Per la gestione dei singoli valori delle capabilities presenti in un capability state l’interfaccia
prevede due funzioni specifiche, cap_get_flag e cap_set_flag, che permettono rispettivamente
di leggere o impostare il valore di una capacità all’interno in uno dei tre insiemi già citati; i
int cap_get_flag(cap_t cap_p, cap_value_t cap, cap_flag_t flag, cap_flag_value_t
*value_p)
Legge il valore di una capability.
int cap_set_flag(cap_t cap_p, cap_flag_t flag, int ncap, cap_value_t *caps,
cap_flag_value_t value)
Imposta il valore di una capability.
Le funzioni ritornano 0 in caso di successo e −1 in caso di errore, nel qual caso errno assumerà il
valore EINVAL.
113
si tratta in effetti di un tipo enumerato, come si può verificare dalla sua definizione che si trova in
/usr/include/sys/capability.h.

In entrambe le funzioni l’argomento cap_p indica il puntatore al capability state su cui ope-
rare, mentre l’argomento flag indica su quale dei tre insiemi si intende operare, sempre con i
valori di tab. 5.21.
La capacità che si intende controllare o impostare invece deve essere specificata attraverso una
variabile di tipo cap_value_t, che può prendere come valore uno qualunque di quelli riportati in
tab. 5.20, in questo caso però non è possibile combinare diversi valori in una maschera binaria,
una variabile di tipo cap_value_t può indicare una sola capacità.114
Infine lo stato di una capacità è descritto ad una variabile di tipo cap_flag_value_t, che a
sua volta può assumere soltanto uno115 dei valori di tab. 5.22.
Valore Significato
CAP_CLEAR La capacità non è impostata.
CAP_SET La capacità è impostata.
Tabella 5.22: Valori possibili per il tipo di dato cap_flag_value_t che indica lo stato di una capacità.
La funzione cap_get_flag legge lo stato della capacità indicata dall’argomento cap all’inter-
no dell’insieme indicato dall’argomento flag lo restituisce nella variabile puntata dall’argomento
value_p. Questa deve essere di tipo cap_flag_value_t ed assumerà uno dei valori di tab. 5.22.
La funzione consente pertanto di leggere solo lo stato di una capacità alla volta.
La funzione cap_set_flag può invece impostare in una sola chiamata più capabilities, anche
se solo all’interno dello stesso insieme ed allo stesso valore. Per questo motivo essa prende un
vettore di valori di tipo cap_value_t nell’argomento caps, la cui dimensione viene specificata
dall’argomento ncap. Il tipo di impostazione da eseguire (cancellazione o impostazione) per le
capacità elencate in caps viene indicato dall’argomento value sempre con i valori di tab. 5.22.
Per semplificare la gestione delle capabilities l’interfaccia prevede che sia possibile utilizzare
anche una rappresentazione testuale del contenuto di un capability state e fornisce le opportune
funzioni di gestione;116 la prima di queste, che consente di ottenere la rappresentazione testuale,
è cap_to_text, il cui prototipo è:
char * cap_to_text(cap_t caps, ssize_t * length_p)
Genera una visualizzazione testuale delle capabilities.
La funzione ritorna un puntatore alla stringa con la descrizione delle capabilities in caso di successo
e NULL in caso di errore, nel qual caso errno può assumere i valori EINVAL o ENOMEM.
La funzione ritorna l’indirizzo di una stringa contente la descrizione testuale del contenuto del
capability state caps passato come argomento, e, qualora l’argomento length_p sia diverso da
NULL, restituisce nella variabile intera da questo puntata la lunghezza della stringa. La stringa
restituita viene allocata automaticamente dalla funzione e pertanto dovrà essere liberata con
cap_free.
La rappresentazione testuale, che viene usata anche di programmi di gestione a riga di co-
mando, prevede che lo stato venga rappresentato con una stringa di testo composta da una serie
di proposizioni separate da spazi, ciascuna delle quali specifica una operazione da eseguire per
creare lo stato finale. Nella rappresentazione si fa sempre conto di partire da uno stato in cui
tutti gli insiemi sono vuoti e si provvede a impostarne i contenuti.
Ciascuna proposizione è nella forma di un elenco di capacità, espresso con i nomi di tab. 5.20
separati da virgole, seguito da un operatore, e dall’indicazione degli insiemi a cui l’operazione
si applica. I nomi delle capacità possono essere scritti sia maiuscoli che minuscoli, viene inoltre
114
in sys/capability.h il tipo cap_value_t è definito come int, ma i valori validi sono soltanto quelli di
tab. 5.20.
115
anche questo è un tipo enumerato.
116
entrambe erano previste dalla bozza dello standard POSIX.1e.

riconosciuto il nome speciale all che è equivalente a scrivere la lista completa. Gli insiemi sono
identificati dalle tre lettere iniziali: “p” per il permitted, “i” per l’inheritable ed “e” per l’effective
che devono essere sempre minuscole e se ne può indicare più di uno.
Gli operatori possibili sono solo tre:“+”che aggiunge le capacità elencate agli insiemi indicati,
“-” che le toglie e “=” che le assegna esattamente. I primi due richiedono che sia sempre indicato
sia un elenco di capacità che gli insiemi a cui esse devono applicarsi, e rispettivamente attiveranno
o disattiveranno le capacità elencate nell’insieme o negli insiemi specificati, ignorando tutto il
resto. I due operatori possono anche essere combinati nella stessa proposizione, per aggiungere
e togliere le capacità dell’elenco da insiemi diversi.
L’assegnazione si applica invece su tutti gli insiemi allo stesso tempo, pertanto l’uso di “=”
è equivalente alla cancellazione preventiva di tutte le capacità ed alla impostazione di quelle
elencate negli insiemi specificati, questo significa che in genere lo si usa una sola volta all’inizio
della stringa. In tal caso l’elenco delle capacità può non essere indicato e viene assunto che si
stia facendo riferimento a tutte quante senza doverlo scrivere esplicitamente.
Come esempi avremo allora che un processo non privilegiato di un utente, che non ha nessuna
capacità attiva, avrà una rappresentazione nella forma “=” che corrisponde al fatto che nessuna
capacità viene assegnata a nessun insieme (vale la cancellazione preventiva), mentre un processo
con privilegi di amministratore avrà una rappresentazione nella forma “=ep” in cui tutte le
capacità vengono assegnate agli insiemi permitted ed effective (e l’inheritable è ignorato in quanto
per le regole viste a pag. 5.4.4 le capacità verranno comunque attivate attraverso una exec).
Infine, come esempio meno banale dei precedenti, otterremo per init una rappresentazione nella
forma “=ep cap_setpcap-e” dato che come accennato tradizionalmente CAP_SETPCAP è sempre
stata rimossa da detto processo.
Viceversa per passare ottenere un capability state dalla sua rappresentazione testuale si può
usare cap_from_text, il cui prototipo è:
cap_t cap_from_text(const char *string)
Crea un capability state dalla sua rappresentazione testuale.
La funzione ritorna un puntatore valido in caso di successo e NULL in caso di errore, nel qual caso
errno può assumere i valori EINVAL o ENOMEM.
La funzione restituisce il puntatore ad un capability state inizializzato con i valori indicati
nella stringa string che ne contiene la rappresentazione testuale. La memoria per il capability
state viene allocata automaticamente dalla funzione e dovrà essere liberata con cap_free.
Alle due funzioni citate se ne aggiungono altre due che consentono di convertire i valori
delle costanti di tab. 5.20 nelle stringhe usate nelle rispettive rappresentazioni e viceversa. Le
due funzioni, cap_to_name e cap_from_name, sono estensioni specifiche di Linux ed i rispettivi
prototipi sono:
char * cap_to_name(cap_value_t cap)
int cap_from_name(const char *name, cap_value_t *cap_p)
Convertono le capabilities dalle costanti alla rappresentazione testuale e viceversa.
La funzione cap_to_name ritorna un valore diverso da NULL in caso di successo e NULL in caso di
errore, mentre cap_to_name ritorna rispettivamente 0 e −1; per entrambe in caso di errore errno
può assumere i valori EINVAL o ENOMEM.
La prima funzione restituisce la stringa (allocata automaticamente e che dovrà essere liberata
con cap_free) che corrisponde al valore della capacità cap, mentre la seconda restituisce nella
variabile puntata da cap_p il valore della capacità rappresentata dalla stringa name.
Fin quei abbiamo trattato solo le funzioni di servizio relative alla manipolazione dei capability
state come strutture di dati; l’interfaccia di gestione prevede però anche le funzioni per trattare

le capabilities presenti nei processi. La prima di queste funzioni è cap_get_proc che consente la
lettura delle capabilities del processo corrente, il suo prototipo è:
cap_t cap_get_proc(void)
Legge le capabilities del processo corrente.
La funzione ritorna un valore diverso da NULL in caso di successo e NULL in caso di errore, nel qual
caso errno può assumere i valori EINVAL, EPERM o ENOMEM.
La funzione legge il valore delle capabilities associate al processo da cui viene invocata,
restituendo il risultato tramite il puntatore ad un capability state contenente tutti i dati che
provvede ad allocare autonomamente e che di nuovo occorrerà liberare con cap_free quando
non sarà più utilizzato.
Se invece si vogliono leggere le capabilities di un processo specifico occorre usare la funzione
capgetp, il cui prototipo117 è:
int capgetp(pid_t pid, cap_t cap_d)
Legge le capabilities del processo indicato da pid.
i valori EINVAL, EPERM o ENOMEM.
La funzione legge il valore delle capabilities del processo indicato con l’argomento pid, e
restituisce il risultato nel capability state posto all’indirizzo indicato con l’argomento cap_d; a
differenza della precedente in questo caso il capability state deve essere stato creato in precedenza.
Qualora il processo indicato non esista si avrà un errore di ESRCH. Gli stessi valori possono
essere letti direttamente nel filesystem proc, nei file /proc/<pid>/status; ad esempio per init
si otterrà qualcosa del tipo:
...
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff
...
Infine per impostare le capabilities del processo corrente (non esiste una funzione che per-
metta di cambiare le capabilities di un altro processo) si deve usare la funzione cap_set_proc,
int cap_set_proc(cap_t cap_p)
Imposta le capabilities del processo corrente.
i valori EINVAL, EPERM o ENOMEM.
La funzione modifica le capabilities del processo corrente secondo quanto specificato con
l’argomento cap_p, posto che questo sia possibile nei termini spiegati in precedenza (non sarà
ad esempio possibile impostare capacità non presenti nell’insieme di quelle permesse). In caso di
successo i nuovi valori saranno effettivi al ritorno della funzione, in caso di fallimento invece lo
stato delle capacità resterà invariato. Si tenga presente che tutte le capacità specificate tramite
cap_p devono essere permesse; se anche una sola non lo è la funzione fallirà, e per quanto
117
su alcune pagine di manuale la funzione è descritta con un prototipo sbagliato, che prevede un valore di
ritorno di tipo cap_t, ma il valore di ritorno è intero, come si può verificare anche dalla dichiarazione della stessa
in sys/capability.h.

appena detto, lo stato delle capabilities non verrà modificato (neanche per le parti eventualmente
permesse).
Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida si è distribuito
il programma getcap.c, che consente di leggere le capabilities del processo corrente118 o tra-
mite l’opzione -p, quelle di un processo qualunque il cui pid viene passato come parametro
dell’opzione.
1 if (!pid) {
2 capab = cap_get_proc ();
3 if (capab == NULL) {
4 perror("cannot get current process capabilities");
5 return 1;
6 }
7 } else {
8 capab = cap_init ();
9 res = capgetp(pid , capab );
10 if (res) {
11 perror("cannot get process capabilities");
12 return 1;
13 }
14 }
15
16 string = cap_to_text(capab , NULL );
17 printf("Capability: %sn", string );
18
19 cap_free(capab );
20 cap_free(string );
21 return 0;
Figura 5.16: Corpo principale del programma getcap.c.
La sezione principale del programma è riportata in fig. 5.16, e si basa su una condizione sulla
variabile pid che se si è usato l’opzione -p è impostata (nella sezione di gestione delle opzioni,
che si è tralasciata) al valore del pid del processo di cui si vuole leggere le capabilities e nulla
altrimenti. Nel primo caso (1-6) si utilizza direttamente (2) cap_get_proc per ottenere lo stato
delle capacità del processo, nel secondo (7-14) prima si inizializza (8) uno stato vuoto e poi (9)
si legge il valore delle capacità del processo indicato.
Il passo successivo è utilizzare (16) cap_to_text per tradurre in una stringa lo stato, e
poi (17) stamparlo; infine (19-20) si libera la memoria allocata dalle precedenti funzioni con
cap_free per poi ritornare dal ciclo principale della funzione.
5.4.5 La funzione chroot
Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione chroot viene
usata spesso per restringere le capacità di accesso di un programma ad una sezione limitata del
filesystem, per cui ne parleremo in questa sezione.
Come accennato in sez. 3.2.2 ogni processo oltre ad una directory di lavoro, ha anche una
directory radice119 che, pur essendo di norma corrispondente alla radice dell’albero di file e
directory come visto dal kernel (ed illustrato in sez. 4.1.1), ha per il processo il significato specifico
118
vale a dire di sé stesso, quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali sono le
capabilities standard che ottiene un processo lanciato dalla riga di comando.
119
entrambe sono contenute in due campi (rispettivamente pwd e root) di fs_struct; vedi fig. 3.2.

di directory rispetto alla quale vengono risolti i pathname assoluti.120 Il fatto che questo valore
sia specificato per ogni processo apre allora la possibilità di modificare le modalità di risoluzione
dei pathname assoluti da parte di un processo cambiando questa directory, cos`ı come si fa coi
pathname relativi cambiando la directory di lavoro.
Normalmente la directory radice di un processo coincide anche con la radice del filesystem
usata dal kernel, e dato che il suo valore viene ereditato dal padre da ogni processo figlio, in
generale i processi risolvono i pathname assoluti a partire sempre dalla stessa directory, che
corrisponde alla radice del sistema.
In certe situazioni però è utile poter impedire che un processo possa accedere a tutto il
filesystem; per far questo si può cambiare la sua directory radice con la funzione chroot, il cui
prototipo è:
#include <unistd.h>
int chroot(const char *path)
Cambia la directory radice del processo a quella specificata da path.
La funzione restituisce zero in caso di successo e -1 per un errore, in caso di errore errno può
assumere i valori:
EPERM l’user-ID effettivo del processo non è zero.
ed inoltre EFAULT, ENAMETOOLONG, ENOENT, ENOMEM, ENOTDIR, EACCES, ELOOP; EROFS e EIO.
in questo modo la directory radice del processo diventerà path (che ovviamente deve esistere)
ed ogni pathname assoluto usato dalle funzioni chiamate nel processo sarà risolto a partire da
essa, rendendo impossibile accedere alla parte di albero sovrastante. Si ha cos`ı quella che viene
chiamata una chroot jail, in quanto il processo non può più accedere a file al di fuori della sezione
di albero in cui è stato imprigionato.
Solo un processo con i privilegi di amministratore può usare questa funzione, e la nuova radice,
per quanto detto in sez. 3.2.2, sarà ereditata da tutti i suoi processi figli. Si tenga presente però
che la funzione non cambia la directory di lavoro, che potrebbe restare fuori dalla chroot jail.
Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita si cedono i
privilegi di root. Infatti se per un qualche motivo il processo resta con la directory di lavoro
fuori dalla chroot jail, potrà comunque accedere a tutto il resto del filesystem usando pathname
relativi, i quali, partendo dalla directory di lavoro che è fuori della chroot jail, potranno (con
l’uso di “..”) risalire fino alla radice effettiva del filesystem.
Ma se ad un processo restano i privilegi di amministratore esso potrà comunque portare la
sua directory di lavoro fuori dalla chroot jail in cui si trova. Basta infatti creare una nuova chroot
jail con l’uso di chroot su una qualunque directory contenuta nell’attuale directory di lavoro.
Per questo motivo l’uso di questa funzione non ha molto senso quando un processo necessita dei
privilegi di root per le sue normali operazioni.
Un caso tipico di uso di chroot è quello di un server FTP anonimo, in questo caso infatti
si vuole che il server veda solo i file che deve trasferire, per cui in genere si esegue una chroot
sulla directory che contiene i file. Si tenga presente però che in questo caso occorrerà replicare
all’interno della chroot jail tutti i file (in genere programmi e librerie) di cui il server potrebbe
avere bisogno.
120
cioè quando un processo chiede la risoluzione di un pathname, il kernel usa sempre questa directory come
punto di partenza.

Capitolo 6
I file: l’interfaccia standard Unix
Esamineremo in questo capitolo la prima delle due interfacce di programmazione per i file, quella
dei file descriptor, nativa di Unix. Questa è l’interfaccia di basso livello provvista direttamente
dalle system call, che non prevede funzionalità evolute come la bufferizzazione o funzioni di
lettura o scrittura formattata, e sulla quale è costruita anche l’interfaccia definita dallo standard
ANSI C che affronteremo al cap. 7.
6.1 L’architettura di base
In questa sezione faremo una breve introduzione sull’architettura su cui è basata dell’interfaccia
dei file descriptor, che, sia pure con differenze nella realizzazione pratica, resta sostanzialmente
la stessa in tutte le implementazione di un sistema unix-like.
6.1.1 L’architettura dei file descriptor
Per poter accedere al contenuto di un file occorre creare un canale di comunicazione con il kernel
che renda possibile operare su di esso (si ricordi quanto visto in sez. 4.2.2). Questo si fa aprendo il
file con la funzione open che provvederà a localizzare l’inode del file e inizializzare i puntatori che
rendono disponibili le funzioni che il VFS mette a disposizione (riportate in tab. 4.2). Una volta
terminate le operazioni, il file dovrà essere chiuso, e questo chiuderà il canale di comunicazione
impedendo ogni ulteriore operazione.
All’interno di ogni processo i file aperti sono identificati da un intero non negativo, chiamato
appunto file descriptor. Quando un file viene aperto la funzione open restituisce questo numero,
tutte le ulteriori operazioni saranno compiute specificando questo stesso valore come argomento
alle varie funzioni dell’interfaccia.
Per capire come funziona il meccanismo occorre spiegare a grandi linee come il kernel gestisce
l’interazione fra processi e file. Il kernel mantiene sempre un elenco dei processi attivi nella
cosiddetta process table ed un elenco dei file aperti nella file table.
La process table è una tabella che contiene una voce per ciascun processo attivo nel sistema.
In Linux ciascuna voce è costituita da una struttura di tipo task_struct nella quale sono
raccolte tutte le informazioni relative al processo; fra queste informazioni c’è anche il puntatore
ad una ulteriore struttura di tipo files_struct, in cui sono contenute le informazioni relative
ai file che il processo ha aperto, ed in particolare:
• i flag relativi ai file descriptor.
• il numero di file aperti.
• una tabella che contiene un puntatore alla relativa voce nella file table per ogni file aperto.
il file descriptor in sostanza è l’intero positivo che indicizza quest’ultima tabella.
181

182 CAPITOLO 6. I FILE: L’INTERFACCIA STANDARD UNIX
La file table è una tabella che contiene una voce per ciascun file che è stato aperto nel sistema.
In Linux è costituita da strutture di tipo file; in ciascuna di esse sono tenute varie informazioni
relative al file, fra cui:
• lo stato del file (nel campo f_flags).
• il valore della posizione corrente (l’offset) nel file (nel campo f_pos).
• un puntatore all’inode1 del file.
In fig. 6.1 si è riportato uno schema in cui è illustrata questa architettura, ed in cui si sono
evidenziate le interrelazioni fra le varie strutture di dati sulla quale essa è basata. Ritorneremo
su questo schema più volte, dato che esso è fondamentale per capire i dettagli del funzionamento
dell’interfaccia dei file descriptor.
Figura 6.1: Schema della architettura dell’accesso ai file attraverso l’interfaccia dei file descriptor.
6.1.2 I file standard
Come accennato i file descriptor non sono altro che un indice nella tabella dei file aperti di
ciascun processo; per questo motivo essi vengono assegnati in successione tutte le volte che si
apre un nuovo file (se non ne è stato chiuso nessuno in precedenza).
In tutti i sistemi unix-like esiste una convenzione generale per cui ogni processo viene lan-
ciato dalla shell con almeno tre file aperti. Questi, per quanto appena detto, avranno come file
descriptor i valori 0, 1 e 2. Benché questa sia soltanto una convenzione, essa è seguita dalla gran
parte delle applicazioni, e non aderirvi potrebbe portare a gravi problemi di interoperabilità.
Il primo file è sempre associato al cosiddetto standard input; è cioè il file da cui il processo si
aspetta di ricevere i dati in ingresso. Il secondo file è il cosiddetto standard output, cioè quello su
cui ci si aspetta debbano essere inviati i dati in uscita. Il terzo è lo standard error, su cui viene
inviata l’uscita relativa agli errori. Nel caso della shell tutti questi file sono associati al terminale
di controllo, e corrispondono quindi alla lettura della tastiera per l’ingresso e alla scrittura sul
1
nel kernel 2.4.x si è in realtà passati ad un puntatore ad una struttura dentry che punta a sua volta all’inode
passando per la nuova struttura del VFS.

6.2. LE FUNZIONI BASE 183
terminale per l’uscita. Lo standard POSIX.1 provvede, al posto dei valori numerici, tre costanti
simboliche, definite in tab. 6.1.
Costante Significato
STDIN_FILENO file descriptor dello standard input
STDOUT_FILENO file descriptor dello standard output
STDERR_FILENO file descriptor dello standard error
Tabella 6.1: Costanti definite in unistd.h per i file standard aperti alla creazione di ogni processo.
In fig. 6.1 si è rappresentata una situazione diversa, facendo riferimento ad un programma in
cui lo standard input è associato ad un file mentre lo standard output e lo standard error sono
entrambi associati ad un altro file (e quindi utilizzano lo stesso inode).
Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il numero di file aperti
era anche soggetto ad un limite massimo dato dalle dimensioni del vettore di puntatori con
cui era realizzata la tabella dei file descriptor dentro file_struct; questo limite intrinseco nei
kernel più recenti non sussiste più, dato che si è passati da un vettore ad una lista, ma restano
i limiti imposti dall’amministratore (vedi sez. 8.1.1).
6.2 Le funzioni base
L’interfaccia standard Unix per l’input/output sui file è basata su cinque funzioni fondamentali:
open, read, write, lseek e close, usate rispettivamente per aprire, leggere, scrivere, spostarsi
e chiudere un file. La gran parte delle operazioni sui file si effettua attraverso queste cinque
funzioni, esse vengono chiamate anche funzioni di I/O non bufferizzato dato che effettuano le
operazioni di lettura e scrittura usando direttamente le system call del kernel.
6.2.1 La funzione open
La funzione open è la funzione fondamentale per accedere ai file, ed è quella che crea l’associazione
fra un pathname ed un file descriptor, il suo prototipo è:
#include <fcntl.h>
int open(const char *pathname, int flags)
int open(const char *pathname, int flags, mode_t mode)
Apre il file indicato da pathname nella modalità indicata da flags, e, nel caso il file sia
creato, con gli eventuali permessi specificati da mode.
La funzione ritorna il file descriptor in caso di successo e −1 in caso di errore. In questo caso la
variabile errno assumerà uno dei valori:
EEXIST pathname esiste e si è specificato O_CREAT e O_EXCL.
EISDIR pathname indica una directory e si è tentato l’accesso in scrittura.
ENOTDIR si è specificato O_DIRECTORY e pathname non è una directory.
ENXIO si sono impostati O_NOBLOCK o O_WRONLY ed il file è una fifo che non viene letta da
nessun processo o pathname è un file di dispositivo ma il dispositivo è assente.
ENODEV pathname si riferisce a un file di dispositivo che non esiste.
ETXTBSY si è cercato di accedere in scrittura all’immagine di un programma in esecuzione.
ELOOP si sono incontrati troppi link simbolici nel risolvere il pathname o si è indicato
O_NOFOLLOW e pathname è un link simbolico.
ed inoltre EACCES, ENAMETOOLONG, ENOENT, EROFS, EFAULT, ENOSPC, ENOMEM, EMFILE e ENFILE.

La funzione apre il file usando il primo file descriptor libero, e crea l’opportuna voce, cioè la
struttura file, nella file table del processo. Viene sempre restituito come valore di ritorno il file
descriptor con il valore più basso disponibile.
Flag Descrizione
O_RDONLY Apre il file in sola lettura, le glibc definiscono anche O_READ come sinonimo.
O_WRONLY Apre il file in sola scrittura, le glibc definiscono anche O_WRITE come sinonimo.
O_RDWR Apre il file sia in lettura che in scrittura.
O_CREAT Se il file non esiste verrà creato, con le regole di titolarità del file viste in sez. 5.3.4. Con
questa opzione l’argomento mode deve essere specificato.
O_EXCL Usato in congiunzione con O_CREAT fa s`ı che la precedente esistenza del file diventi un errore2
che fa fallire open con EEXIST.
O_NONBLOCK Apre il file in modalità non bloccante, e comporta che open ritorni immediatamente anche
quando dovrebbe bloccarsi (l’opzione ha senso solo per le fifo, vedi sez. 11.1.4).
O_NOCTTY Se pathname si riferisce ad un dispositivo di terminale, questo non diventerà il terminale di
controllo, anche se il processo non ne ha ancora uno (si veda sez. 10.1.3).
O_SHLOCK Apre il file con uno shared lock (vedi sez. 12.1). Specifica di BSD, assente in Linux.
O_EXLOCK Apre il file con un lock esclusivo (vedi sez. 12.1). Specifica di BSD, assente in Linux.
O_TRUNC Se usato su un file di dati aperto in scrittura, ne tronca la lunghezza a zero; con un terminale
o una fifo viene ignorato, negli altri casi il comportamento non è specificato.
O_NOFOLLOW Se pathname è un link simbolico la chiamata fallisce. Questa è un’estensione BSD aggiunta
in Linux dal kernel 2.1.126. Nelle versioni precedenti i link simbolici sono sempre seguiti, e
questa opzione è ignorata.
O_DIRECTORY Se pathname non è una directory la chiamata fallisce. Questo flag è specifico di Linux ed è
stato introdotto con il kernel 2.1.126 per evitare dei DoS3
quando opendir viene chiamata
su una fifo o su un dispositivo associato ad una unità a nastri, non deve dispositivo a nastri;
non deve essere utilizzato al di fuori dell’implementazione di opendir.
O_LARGEFILE Nel caso di sistemi a 32 bit che supportano file di grandi dimensioni consente di aprire file
le cui dimensioni non possono essere rappresentate da numeri a 31 bit.
O_APPEND Il file viene aperto in append mode. Prima di ciascuna scrittura la posizione corrente viene
sempre impostata alla fine del file. Con NFS si può avere una corruzione del file se più di un
processo scrive allo stesso tempo.4
O_NONBLOCK Il file viene aperto in modalità non bloccante per le operazioni di I/O (che tratteremo in
sez. 12.2.1): questo significa il fallimento di read in assenza di dati da leggere e quello di
write in caso di impossibilità di scrivere immediatamente. Questa modalità ha senso solo
per le fifo e per alcuni file di dispositivo.
O_NDELAY In Linux5
è sinonimo di O_NONBLOCK.
O_ASYNC Apre il file per l’I/O in modalità asincrona (vedi sez. 12.3.3). Quando è impostato viene
generato il segnale SIGIO tutte le volte che sono disponibili dati in input sul file.
O_SYNC Apre il file per l’input/output sincrono: ogni write bloccherà fino al completamento della
scrittura di tutti i dati sull’hardware sottostante.
O_FSYNC Sinonimo di O_SYNC, usato da BSD.
O_DSYNC Variante di I/O sincrono definita da POSIX; presente dal kernel 2.1.130 come sinonimo di
O_SYNC.
O_RSYNC Variante analoga alla precedente, trattata allo stesso modo.
O_NOATIME Blocca l’aggiornamento dei tempi di accesso dei file (vedi sez. 5.2.4). Per molti filesystem
questa funzionalità non è disponibile per il singolo file ma come opzione generale da specificare
in fase di montaggio.
O_DIRECT Esegue l’I/O direttamente dai buffer in user space in maniera sincrona, in modo da scavalcare
i meccanismi di caching del kernel. In genere questo peggiora le prestazioni tranne quando le
applicazioni6
ottimizzano il proprio caching. Per i kernel della serie 2.4 si deve garantire che
i buffer in user space siano allineati alle dimensioni dei blocchi del filesystem; per il kernel
2.6 basta che siano allineati a multipli di 512 byte.
O_CLOEXEC Attiva la modalità di close-on-exec (vedi sez. 6.3.1 e 6.3.6).7
Tabella 6.2: Valori e significato dei vari bit del file status flag.
2
la pagina di manuale di open segnala che questa opzione è difettosa su NFS, e che i programmi che la usano
per stabilire un file di lock possono incorrere in una race condition. Si consiglia come alternativa di usare un file
con un nome univoco e la funzione link per verificarne l’esistenza (vedi sez. 11.3.2).

Questa caratteristica permette di prevedere qual è il valore del file descriptor che si otterrà al
ritorno di open, e viene talvolta usata da alcune applicazioni per sostituire i file corrispondenti
ai file standard visti in sez. 6.1.2: se ad esempio si chiude lo standard input e si apre subito dopo
un nuovo file questo diventerà il nuovo standard input (avrà cioè il file descriptor 0).
Il nuovo file descriptor non è condiviso con nessun altro processo (torneremo sulla condivisione
dei file, in genere accessibile dopo una fork, in sez. 6.3.1) ed è impostato per restare aperto
attraverso una exec (come accennato in sez. 3.2.5); l’offset è impostato all’inizio del file.
L’argomento mode indica i permessi con cui il file viene creato; i valori possibili sono gli stessi
già visti in sez. 5.3.1 e possono essere specificati come OR binario delle costanti descritte in
tab. 5.7. Questi permessi sono filtrati dal valore di umask (vedi sez. 5.3.3) per il processo.
La funzione prevede diverse opzioni, che vengono specificate usando vari bit dell’argomento
flags. Alcuni di questi bit vanno anche a costituire il flag di stato del file (o file status flag),
che è mantenuto nel campo f_flags della struttura file (al solito si veda lo schema di fig. 6.1).
Essi sono divisi in tre categorie principali:
• i bit delle modalità di accesso: specificano con quale modalità si accederà al file: i valori
possibili sono lettura, scrittura o lettura/scrittura. Uno di questi bit deve essere sempre
specificato quando si apre un file. Vengono impostati alla chiamata da open, e possono
essere riletti con fcntl (fanno parte del file status flag), ma non possono essere modificati.
• i bit delle modalità di apertura: permettono di specificare alcune delle caratteristiche
del comportamento di open quando viene eseguita. Hanno effetto solo al momento della
chiamata della funzione e non sono memorizzati né possono essere riletti.
• i bit delle modalità di operazione: permettono di specificare alcune caratteristiche del
comportamento delle future operazioni sul file (come read o write). Anch’essi fan parte
del file status flag. Il loro valore è impostato alla chiamata di open, ma possono essere
riletti e modificati (insieme alle caratteristiche operative che controllano) con una fcntl.
In tab. 6.2 sono riportate, ordinate e divise fra loro secondo le tre modalità appena elencate, le
costanti mnemoniche associate a ciascuno di questi bit. Dette costanti possono essere combinate
fra loro con un OR aritmetico per costruire il valore (in forma di maschera binaria) dell’argomento
flags da passare alla open. I due flag O_NOFOLLOW e O_DIRECTORY sono estensioni specifiche di
Linux, e deve essere definita la macro _GNU_SOURCE per poterli usare.
Nelle prime versioni di Unix i valori di flag specificabili per open erano solo quelli relativi
alle modalità di accesso del file. Per questo motivo per creare un nuovo file c’era una system call
apposita, creat, il cui prototipo è:
#include <fcntl.h>
int creat(const char *pathname, mode_t mode)
Crea un nuovo file vuoto, con i permessi specificati da mode. È del tutto equivalente a
open(filedes, O_CREAT|O_WRONLY|O_TRUNC, mode).
adesso questa funzione resta solo per compatibilità con i vecchi programmi.
3
acronimo di Denial of Service, si chiamano cos`ı attacchi miranti ad impedire un servizio causando una qualche
forma di carico eccessivo per il sistema, che resta bloccato nelle risposte all’attacco.
4
il problema è che NFS non supporta la scrittura in append, ed il kernel deve simularla, ma questo comporta
la possibilità di una race condition, vedi sez. 6.3.2.
5
l’opzione origina da SVr4, dove però causava il ritorno da una read con un valore nullo e non con un errore,
questo introduce un’ambiguità, dato che come vedremo in sez. 6.2.4 il ritorno di zero da parte di read ha il
significato di una end-of-file.
6
l’opzione è stata introdotta dalla SGI in IRIX, e serve sostanzialmente a permettere ad alcuni programmi (in
genere database) la gestione diretta della bufferizzazione dell’I/O in quanto essi sono in grado di ottimizzarla al
meglio per le loro prestazioni; l’opzione è presente anche in FreeBSD, senza limiti di allineamento dei buffer. In
Linux è stata introdotta con il kernel 2.4.10, le versioni precedenti la ignorano.
7
introdotto con il kernel 2.6.23, per evitare una race condition che si può verificare con i thread, fra l’apertura
del file e l’impostazione della suddetta modalità con fcntl.

6.2.2 La funzione close
La funzione close permette di chiudere un file, in questo modo il file descriptor ritorna dispo-
nibile; il suo prototipo è:
#include <unistd.h>
int close(int fd)
Chiude il descrittore fd.
La funzione ritorna 0 in caso di successo e −1 in caso di errore, con errno che assume i valori:
EBADF fd non è un descrittore valido.
ed inoltre EIO.
La chiusura di un file rilascia ogni blocco (il file locking è trattato in sez. 12.1) che il processo
poteva avere acquisito su di esso; se fd è l’ultimo riferimento (di eventuali copie) ad un file
aperto, tutte le risorse nella file table vengono rilasciate. Infine se il file descriptor era l’ultimo
riferimento ad un file su disco quest’ultimo viene cancellato.
Si ricordi che quando un processo termina anche tutti i suoi file descriptor vengono chiusi,
molti programmi sfruttano questa caratteristica e non usano esplicitamente close. In genere
comunque chiudere un file senza controllarne lo stato di uscita è errore; infatti molti filesystem
implementano la tecnica del write-behind, per cui una write può avere successo anche se i dati
non sono stati scritti, un eventuale errore di I/O allora può sfuggire, ma verrà riportato alla
chiusura del file: per questo motivo non effettuare il controllo può portare ad una perdita di dati
inavvertita.8
In ogni caso una close andata a buon fine non garantisce che i dati siano stati effettivamente
scritti su disco, perché il kernel può decidere di ottimizzare l’accesso a disco ritardandone la
scrittura. L’uso della funzione sync (vedi sez. 6.3.3) effettua esplicitamente il flush dei dati,
ma anche in questo caso resta l’incertezza dovuta al comportamento dell’hardware (che a sua
volta può introdurre ottimizzazioni dell’accesso al disco che ritardano la scrittura dei dati, da
cui l’abitudine di ripetere tre volte il comando prima di eseguire lo shutdown).
6.2.3 La funzione lseek
Come già accennato in sez. 6.1.1 a ciascun file aperto è associata una posizione corrente nel file (il
cosiddetto file offset, mantenuto nel campo f_pos di file) espressa da un numero intero positivo
come numero di byte dall’inizio del file. Tutte le operazioni di lettura e scrittura avvengono a
partire da questa posizione che viene automaticamente spostata in avanti del numero di byte
letti o scritti.
In genere (a meno di non avere richiesto la modalità O_APPEND) questa posizione viene im-
postata a zero all’apertura del file. È possibile impostarla ad un valore qualsiasi con la funzione
lseek, il cui prototipo è:
#include <unistd.h>
off_t lseek(int fd, off_t offset, int whence)
Imposta la posizione attuale nel file.
La funzione ritorna il valore della posizione corrente in caso di successo e −1 in caso di errore nel
qual caso errno assumerà uno dei valori:
ESPIPE fd è una pipe, un socket o una fifo.
EINVAL whence non è un valore valido.
EOVERFLOW offset non può essere rappresentato nel tipo off_t.
ed inoltre EBADF.
8
in Linux questo comportamento è stato osservato con NFS e le quote su disco.

La nuova posizione è impostata usando il valore specificato da offset, sommato al riferimento
dato da whence; quest’ultimo può assumere i seguenti valori9:
SEEK_SET si fa riferimento all’inizio del file: il valore (sempre positivo) di offset indica
direttamente la nuova posizione corrente.
SEEK_CUR si fa riferimento alla posizione corrente del file: ad essa viene sommato offset (che
può essere negativo e positivo) per ottenere la nuova posizione corrente.
SEEK_END si fa riferimento alla fine del file: alle dimensioni del file viene sommato offset (che
può essere negativo e positivo) per ottenere la nuova posizione corrente.
Si tenga presente che la chiamata a lseek non causa nessun accesso al file, si limita a
modificare la posizione corrente (cioè il valore f_pos in file, vedi fig. 6.1). Dato che la funzione
ritorna la nuova posizione, usando il valore zero per offset si può riottenere la posizione corrente
nel file chiamando la funzione con lseek(fd, 0, SEEK_CUR).
Si tenga presente inoltre che usare SEEK_END non assicura affatto che la successiva scrittura
avvenga alla fine del file, infatti se questo è stato aperto anche da un altro processo che vi
ha scritto, la fine del file può essersi spostata, ma noi scriveremo alla posizione impostata in
precedenza (questa è una potenziale sorgente di race condition, vedi sez. 6.3.2).
Non tutti i file supportano la capacità di eseguire una lseek, in questo caso la funzione
ritorna l’errore ESPIPE. Questo, oltre che per i tre casi citati nel prototipo, vale anche per tutti
quei dispositivi che non supportano questa funzione, come ad esempio per i file di terminale.10
Lo standard POSIX però non specifica niente in proposito. Inoltre alcuni file speciali, ad esempio
/dev/null, non causano un errore ma restituiscono un valore indefinito.
Infine si tenga presente che, come accennato in sez. 5.2.3, con lseek è possibile impostare
una posizione anche oltre la corrente fine del file; ed in tal caso alla successiva scrittura il file sarà
esteso a partire da detta posizione. In questo caso si ha quella che viene chiamata la creazione
di un buco nel file, accade cioè che nonostante la dimensione del file sia cresciuta in seguito alla
scrittura effettuata, lo spazio vuoto fra la precedente fine del file ed la nuova parte scritta dopo lo
spostamento, non corrisponda ad una allocazione effettiva di spazio su disco, che sarebbe inutile
dato che quella zona è effettivamente vuota.
Questa è una delle caratteristiche spcifiche della gestione dei file di un sistema unix-like, ed
in questo caso si ha appunto quello che in gergo si chiama un hole nel file e si dice che il file
in questione è uno sparse file. In sostanza, se si ricorda la struttura di un filesystem illustrata
in fig. 4.3, quello che accade è che nell’inode del file viene segnata l’allocazione di un blocco di
dati a partire dalla nuova posizione, ma non viene allocato nulla per le posizioni intermedie; in
caso di lettura sequenziale del contenuto del file il kernel si accorgerà della presenza del buco, e
restituirà degli zeri come contenuto di quella parte del file.
Questa funzionalità comporta una delle caratteristiche della gestione dei file su Unix che
spesso genera più confusione in chi non la conosce, per cui sommando le dimensioni dei file si
può ottenere, se si hanno molti sparse file, un totale anche maggiore della capacità del proprio
disco e comunque maggiore della dimensione che riporta un comando come du, che calcola lo
spazio disco occupato in base al numero dei blocchi effettivamente allocati per il file.
Questo avviene proprio perché in un sistema unix-like la dimensione di un file è una carat-
teristica del tutto indipendente dalla quantità di spazio disco effettivamente allocato, e viene
registrata sull’inode come le altre proprietà del file. La dimensione viene aggiornata automa-
ticamente quando si estende un file scrivendoci, e viene riportata dal campo st_size di una
struttura stat quando si effettua chiamata ad una delle funzioni *stat viste in sez. 5.2.1.
9
per compatibilità con alcune vecchie notazioni questi valori possono essere rimpiazzati rispettivamente con 0,
1 e 2 o con L_SET, L_INCR e L_XTND.
10
altri sistemi, usando SEEK_SET, in questo caso ritornano il numero di caratteri che vi sono stati scritti.

Questo comporta che in generale, fintanto che lo si è scritto sequenzialmente, la dimensione di
un file sarà più o meno corrispondente alla quantità di spazio disco da esso occupato, ma esistono
dei casi, come questo in cui ci si sposta in una posizione oltre la fine corrente del file, o come
quello accennato in in sez. 5.2.3 in cui si estende la dimensione di un file con una truncate,
in cui in sostanza di modifica il valore della dimensione di st_size senza allocare spazio su
disco. Questo consente di creare inizialmente file di dimensioni anche molto grandi, senza dover
occupare da subito dello spazio disco che in realtà sarebbe inutilizzato.
6.2.4 Le funzioni read e pread
Una volta che un file è stato aperto (con il permesso in lettura) si possono leggere i dati che
contiene utilizzando la funzione read, il cui prototipo è:
#include <unistd.h>
ssize_t read(int fd, void * buf, size_t count)
Cerca di leggere count byte dal file fd al buffer buf.
La funzione ritorna il numero di byte letti in caso di successo e −1 in caso di errore, nel qual caso
errno assumerà uno dei valori:
EINTR la funzione è stata interrotta da un segnale prima di aver potuto leggere qualsiasi dato.
EAGAIN la funzione non aveva nessun dato da restituire e si era aperto il file in modalità
O_NONBLOCK.
ed inoltre EBADF, EIO, EISDIR, EBADF, EINVAL e EFAULT ed eventuali altri errori dipendenti dalla
natura dell’oggetto connesso a fd.
La funzione tenta di leggere count byte a partire dalla posizione corrente nel file. Dopo
la lettura la posizione sul file è spostata automaticamente in avanti del numero di byte letti.
Se count è zero la funzione restituisce zero senza nessun altro risultato. Si deve sempre tener
presente che non è detto che la funzione read restituisca sempre il numero di byte richiesto, ci
sono infatti varie ragioni per cui la funzione può restituire un numero di byte inferiore; questo è
un comportamento normale, e non un errore, che bisogna sempre tenere presente.
La prima e più ovvia di queste ragioni è che si è chiesto di leggere più byte di quanto il file ne
contenga. In questo caso il file viene letto fino alla sua fine, e la funzione ritorna regolarmente il
numero di byte letti effettivamente. Raggiunta la fine del file, alla ripetizione di un’operazione di
lettura, otterremmo il ritorno immediato di read con uno zero. La condizione di raggiungimento
della fine del file non è un errore, e viene segnalata appunto da un valore di ritorno di read
nullo. Ripetere ulteriormente la lettura non avrebbe nessun effetto se non quello di continuare a
ricevere zero come valore di ritorno.
Con i file regolari questa è l’unica situazione in cui si può avere un numero di byte letti
inferiore a quello richiesto, ma questo non è vero quando si legge da un terminale, da una fifo o
da una pipe. In tal caso infatti, se non ci sono dati in ingresso, la read si blocca (a meno di non
aver selezionato la modalità non bloccante, vedi sez. 12.2.1) e ritorna solo quando ne arrivano;
se il numero di byte richiesti eccede quelli disponibili la funzione ritorna comunque, ma con un
numero di byte inferiore a quelli richiesti.
Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket, come vedremo
in sez. 16.3.1), o per la lettura da certi file di dispositivo, come le unità a nastro, che restituiscono
sempre i dati ad un singolo blocco alla volta, o come le linee seriali, che restituiscono solo i dati
ricevuti fino al momento della lettura.
Infine anche le due condizioni segnalate dagli errori EINTR ed EAGAIN non sono propriamente
degli errori. La prima si verifica quando la read è bloccata in attesa di dati in ingresso e viene
interrotta da un segnale; in tal caso l’azione da intraprendere è quella di rieseguire la funzione.
Torneremo in dettaglio sull’argomento in sez. 9.3.1. La seconda si verifica quando il file è aperto in
modalità non bloccante (vedi sez. 12.2.1) e non ci sono dati in ingresso: la funzione allora ritorna

immediatamente con un errore EAGAIN11 che indica soltanto che non essendoci al momento dati
disponibili occorre provare a ripetere la lettura in un secondo tempo.
La funzione read è una delle system call fondamentali, esistenti fin dagli albori di Unix, ma
nella seconda versione delle Single Unix Specification12 (quello che viene chiamato normalmente
Unix98, vedi sez. 1.2.6) è stata introdotta la definizione di un’altra funzione di lettura, pread,
#include <unistd.h>
ssize_t pread(int fd, void * buf, size_t count, off_t offset)
Cerca di leggere count byte dal file fd, a partire dalla posizione offset, nel buffer buf.
errno assumerà i valori già visti per read e lseek.
La funzione prende esattamente gli stessi argomenti di read con lo stesso significato, a cui si
aggiunge l’argomento offset che indica una posizione sul file. Identico è il comportamento ed
il valore di ritorno. La funzione serve quando si vogliono leggere dati dal file senza modificare la
posizione corrente.
L’uso di pread è equivalente all’esecuzione di una read seguita da una lseek che riporti al
valore precedente la posizione corrente sul file, ma permette di eseguire l’operazione atomica-
mente. Questo può essere importante quando la posizione sul file viene condivisa da processi
diversi (vedi sez. 6.3.1). Il valore di offset fa sempre riferimento all’inizio del file.
La funzione pread è disponibile anche in Linux, però diventa accessibile solo attivando il
supporto delle estensioni previste dalle Single Unix Specification con la definizione della macro:
#define _XOPEN_SOURCE 500
e si ricordi di definire questa macro prima dell’inclusione del file di dichiarazioni unistd.h.
6.2.5 Le funzioni write e pwrite
Una volta che un file è stato aperto (con il permesso in scrittura) si può scrivere su di esso
utilizzando la funzione write, il cui prototipo è:
#include <unistd.h>
ssize_t write(int fd, void * buf, size_t count)
Scrive count byte dal buffer buf sul file fd.
La funzione ritorna il numero di byte scritti in caso di successo e −1 in caso di errore, nel qual
caso errno assumerà uno dei valori:
EINVAL fd è connesso ad un oggetto che non consente la scrittura.
EFBIG si è cercato di scrivere oltre la dimensione massima consentita dal filesystem o il limite
per le dimensioni dei file del processo o su una posizione oltre il massimo consentito.
EPIPE fd è connesso ad una pipe il cui altro capo è chiuso in lettura; in questo caso viene
anche generato il segnale SIGPIPE, se questo viene gestito (o bloccato o ignorato) la
funzione ritorna questo errore.
EINTR si è stati interrotti da un segnale prima di aver potuto scrivere qualsiasi dato.
EAGAIN ci si sarebbe bloccati, ma il file era aperto in modalità O_NONBLOCK.
ed inoltre EBADF, EIO, EISDIR, EBADF, ENOSPC, EINVAL e EFAULT ed eventuali altri errori dipendenti
dalla natura dell’oggetto connesso a fd.
Come nel caso di read la funzione tenta di scrivere count byte a partire dalla posizione
corrente nel file e sposta automaticamente la posizione in avanti del numero di byte scritti. Se
11
in BSD si usa per questo errore la costante EWOULDBLOCK, in Linux, con le glibc, questa è sinonima di EAGAIN.
12
questa funzione, e l’analoga pwrite sono state aggiunte nel kernel 2.1.60, il supporto nelle glibc, compresa
l’emulazione per i vecchi kernel che non hanno la system call, è stato aggiunto con la versione 2.1, in versioni
precedenti sia del kernel che delle librerie la funzione non è disponibile.

il file è aperto in modalità O_APPEND i dati vengono sempre scritti alla fine del file. Lo standard
POSIX richiede che i dati scritti siano immediatamente disponibili ad una read chiamata dopo
che la write che li ha scritti è ritornata; ma dati i meccanismi di caching non è detto che tutti
i filesystem supportino questa capacità.
Se count è zero la funzione restituisce zero senza fare nient’altro. Per i file ordinari il numero
di byte scritti è sempre uguale a quello indicato da count, a meno di un errore. Negli altri casi
si ha lo stesso comportamento di read.
Anche per write lo standard Unix98 definisce un’analoga pwrite per scrivere alla posizione
indicata senza modificare la posizione corrente nel file, il suo prototipo è:
#include <unistd.h>
ssize_t pwrite(int fd, void * buf, size_t count, off_t offset)
Cerca di scrivere sul file fd, a partire dalla posizione offset, count byte dal buffer buf.
errno assumerà i valori già visti per write e lseek.
e per essa valgono le stesse considerazioni fatte per pread.
6.3 Caratteristiche avanzate
In questa sezione approfondiremo alcune delle caratteristiche più sottili della gestione file in un
sistema unix-like, esaminando in dettaglio il comportamento delle funzioni base, inoltre trat-
teremo le funzioni che permettono di eseguire alcune operazioni avanzate con i file (il grosso
dell’argomento sarà comunque affrontato in cap. 12).
6.3.1 La condivisione dei files
In sez. 6.1.1 abbiamo descritto brevemente l’architettura dell’interfaccia con i file da parte di
un processo, mostrando in fig. 6.1 le principali strutture usate dal kernel; esamineremo ora in
dettaglio le conseguenze che questa architettura ha nei confronti dell’accesso allo stesso file da
parte di processi diversi.
Il primo caso è quello in cui due processi diversi aprono lo stesso file su disco; sulla base
di quanto visto in sez. 6.1.1 avremo una situazione come quella illustrata in fig. 6.2: ciascun
processo avrà una sua voce nella file table referenziata da un diverso file descriptor nella sua
file_struct. Entrambe le voci nella file table faranno però riferimento allo stesso inode su
disco.
Questo significa che ciascun processo avrà la sua posizione corrente sul file, la sua modalità
di accesso e versioni proprie di tutte le proprietà che vengono mantenute nella sua voce della file
table. Questo ha conseguenze specifiche sugli effetti della possibile azione simultanea sullo stesso
file, in particolare occorre tenere presente che:
• ciascun processo può scrivere indipendentemente; dopo ciascuna write la posizione cor-
rente sarà cambiata solo nel processo. Se la scrittura eccede la dimensione corrente del file
questo verrà esteso automaticamente con l’aggiornamento del campo i_size nell’inode.
• se un file è in modalità O_APPEND tutte le volte che viene effettuata una scrittura la posizione
corrente viene prima impostata alla dimensione corrente del file letta dall’inode. Dopo la
scrittura il file viene automaticamente esteso.
• l’effetto di lseek è solo quello di cambiare il campo f_pos nella struttura file della file
table, non c’è nessuna operazione sul file su disco. Quando la si usa per porsi alla fine del
file la posizione viene impostata leggendo la dimensione corrente dall’inode.

6.3. CARATTERISTICHE AVANZATE 191
Figura 6.2: Schema dell’accesso allo stesso file da parte di due processi diversi
Il secondo caso è quello in cui due file descriptor di due processi diversi puntino alla stessa
voce nella file table; questo è ad esempio il caso dei file aperti che vengono ereditati dal processo
figlio all’esecuzione di una fork (si ricordi quanto detto in sez. 3.2.2). La situazione è illustrata
in fig. 6.3; dato che il processo figlio riceve una copia dello spazio di indirizzi del padre, riceverà
anche una copia di file_struct e relativa tabella dei file aperti.
In questo modo padre e figlio avranno gli stessi file descriptor che faranno riferimento alla
stessa voce nella file table, condividendo cos`ı la posizione corrente sul file. Questo ha le con-
seguenze descritte a suo tempo in sez. 3.2.2: in caso di scrittura contemporanea la posizione
corrente nel file varierà per entrambi i processi (in quanto verrà modificato f_pos che è lo stesso
per entrambi).
Si noti inoltre che anche i flag di stato del file (quelli impostati dall’argomento flag di open)
essendo tenuti nella voce della file table13, vengono in questo caso condivisi. Ai file però sono
associati anche altri flag, dei quali l’unico usato al momento è FD_CLOEXEC, detti file descriptor
flags. Questi ultimi sono tenuti invece in file_struct, e perciò sono specifici di ciascun processo
e non vengono modificati dalle azioni degli altri anche in caso di condivisione della stessa voce
della file table.
6.3.2 Operazioni atomiche con i file
Come si è visto in un sistema unix-like è sempre possibile per più processi accedere in contem-
poranea allo stesso file, e che le operazioni di lettura e scrittura possono essere fatte da ogni
processo in maniera autonoma in base ad una posizione corrente nel file che è locale a ciascuno
di essi.
13
per la precisione nel campo f_flags di file.

Figura 6.3: Schema dell’accesso ai file da parte di un processo figlio
Se dal punto di vista della lettura dei dati questo non comporta nessun problema, quando
si andrà a scrivere le operazioni potranno mescolarsi in maniera imprevedibile. Il sistema però
fornisce in alcuni casi la possibilità di eseguire alcune operazioni di scrittura in maniera coor-
dinata anche senza utilizzare meccanismi di sincronizzazione più complessi (come il file locking,
che esamineremo in sez. 12.1).
Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui vari processi devono
scrivere alla fine di un file (ad esempio un file di log). Come accennato in sez. 6.2.3 impostare la
posizione alla fine del file e poi scrivere può condurre ad una race condition: infatti può succedere
che un secondo processo scriva alla fine del file fra la lseek e la write; in questo caso, come
abbiamo appena visto, il file sarà esteso, ma il nostro primo processo avrà ancora la posizione
corrente impostata con la lseek che non corrisponde più alla fine del file, e la successiva write
sovrascriverà i dati del secondo processo.
Il problema è che usare due system call in successione non è un’operazione atomica; il pro-
blema è stato risolto introducendo la modalità O_APPEND. In questo caso infatti, come abbiamo
descritto in precedenza, è il kernel che aggiorna automaticamente la posizione alla fine del file
prima di effettuare la scrittura, e poi estende il file. Tutto questo avviene all’interno di una
singola system call (la write) che non essendo interrompibile da un altro processo costituisce
un’operazione atomica.
Un altro caso tipico in cui è necessaria l’atomicità è quello in cui si vuole creare un file di
lock , bloccandosi se il file esiste. In questo caso la sequenza logica porterebbe a verificare prima
l’esistenza del file con una stat per poi crearlo con una creat; di nuovo avremmo la possibilità
di una race condition da parte di un altro processo che crea lo stesso file fra il controllo e la
creazione.
Per questo motivo sono stati introdotti per open i due flag O_CREAT e O_EXCL. In questo
modo l’operazione di controllo dell’esistenza del file (con relativa uscita dalla funzione con un
errore) e creazione in caso di assenza, diventa atomica essendo svolta tutta all’interno di una

singola system call (per i dettagli sull’uso di questa caratteristica si veda sez. 11.3.2).
6.3.3 Le funzioni sync e fsync
Come accennato in sez. 6.2.2 tutte le operazioni di scrittura sono in genere bufferizzate dal
kernel, che provvede ad effettuarle in maniera asincrona (ad esempio accorpando gli accessi alla
stessa zona del disco) in un secondo tempo rispetto al momento della esecuzione della write.
Per questo motivo, quando è necessaria una sincronizzazione dei dati, il sistema mette a
disposizione delle funzioni che provvedono a forzare lo scarico dei dati dai buffer del kernel.14
La prima di queste funzioni è sync il cui prototipo è:
#include <unistd.h>
int sync(void)
Sincronizza il buffer della cache dei file col disco.
La funzione ritorna sempre zero.
i vari standard prevedono che la funzione si limiti a far partire le operazioni, ritornando imme-
diatamente; in Linux (dal kernel 1.3.20) invece la funzione aspetta la conclusione delle operazioni
di sincronizzazione del kernel.
La funzione viene usata dal comando sync quando si vuole forzare esplicitamente lo scarico
dei dati su disco, o dal demone di sistema update che esegue lo scarico dei dati ad intervalli di
tempo fissi: il valore tradizionale, usato da BSD, per l’update dei dati è ogni 30 secondi, ma in
Linux il valore utilizzato è di 5 secondi; con le nuove versioni15 poi, è il kernel che si occupa
direttamente di tutto quanto attraverso il demone interno bdflush, il cui comportamento può
essere controllato attraverso il file /proc/sys/vm/bdflush (per il significato dei valori si può
leggere la documentazione allegata al kernel in Documentation/sysctl/vm.txt).
Quando si vogliono scaricare soltanto i dati di un file (ad esempio essere sicuri che i dati di
un database sono stati registrati su disco) si possono usare le due funzioni fsync e fdatasync,
i cui prototipi sono:
#include <unistd.h>
int fsync(int fd)
Sincronizza dati e meta-dati del file fd
int fdatasync(int fd)
Sincronizza i dati del file fd.
La funzione ritorna 0 in caso di successo e −1 in caso di errore, nel qual caso errno assume i
valori:
EINVAL fd è un file speciale che non supporta la sincronizzazione.
ed inoltre EBADF, EROFS e EIO.
Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del file specificato,
ed attendono fino alla conclusione delle operazioni; fsync forza anche la sincronizzazione dei
meta-dati del file (che riguardano sia le modifiche alle tabelle di allocazione dei settori, che gli
altri dati contenuti nell’inode che si leggono con fstat, come i tempi del file).
Si tenga presente che questo non comporta la sincronizzazione della directory che contiene il
file (e scrittura della relativa voce su disco) che deve essere effettuata esplicitamente.16
14
come già accennato neanche questo dà la garanzia assoluta che i dati siano integri dopo la chiamata, l’hardware
dei dischi è in genere dotato di un suo meccanismo interno di ottimizzazione per l’accesso al disco che può ritardare
ulteriormente la scrittura effettiva.
15
a partire dal kernel 2.2.8
16
in realtà per il filesystem ext2, quando lo si monta con l’opzione sync, il kernel provvede anche alla
sincronizzazione automatica delle voci delle directory.

6.3.4 Le funzioni dup e dup2
Abbiamo già visto in sez. 6.3.1 come un processo figlio condivida gli stessi file descriptor del
padre; è possibile però ottenere un comportamento analogo all’interno di uno stesso processo
duplicando un file descriptor. Per far questo si usa la funzione dup il cui prototipo è:
#include <unistd.h>
int dup(int oldfd)
Crea una copia del file descriptor oldfd.
La funzione ritorna il nuovo file descriptor in caso di successo e −1 in caso di errore, nel qual caso
EBADF oldfd non è un file aperto.
EMFILE si è raggiunto il numero massimo consentito di file descriptor aperti.
La funzione ritorna, come open, il primo file descriptor libero. Il file descriptor è una copia
esatta del precedente ed entrambi possono essere interscambiati nell’uso. Per capire meglio il
funzionamento della funzione si può fare riferimento a fig. 6.4: l’effetto della funzione è sem-
plicemente quello di copiare il valore nella struttura file_struct, cosicché anche il nuovo file
descriptor fa riferimento alla stessa voce nella file table; per questo si dice che il nuovo file
descriptor è duplicato, da cui il nome della funzione.
Figura 6.4: Schema dell’accesso ai file duplicati
Si noti che per quanto illustrato in fig. 6.4 i file descriptor duplicati condivideranno eventuali
lock, file status flag, e posizione corrente. Se ad esempio si esegue una lseek per modificare
la posizione su uno dei due file descriptor, essa risulterà modificata anche sull’altro (dato che
quello che viene modificato è lo stesso campo nella voce della file table a cui entrambi fanno
riferimento). L’unica differenza fra due file descriptor duplicati è che ciascuno avrà il suo file
descriptor flag; a questo proposito va specificato che nel caso di dup il flag di close-on-exec (vedi
sez. 3.2.5 e sez. 6.3.6) viene sempre cancellato nella copia.
L’uso principale di questa funzione è per la redirezione dell’input e dell’output fra l’esecuzione
di una fork e la successiva exec; diventa cos`ı possibile associare un file (o una pipe) allo standard
input o allo standard output (torneremo sull’argomento in sez. 11.1.2, quando tratteremo le pipe).
Per fare questo in genere occorre prima chiudere il file che si vuole sostituire, cosicché il suo file
descriptor possa esser restituito alla chiamata di dup, come primo file descriptor disponibile.

Dato che questa è l’operazione più comune, è prevista una diversa versione della funzione,
dup2, che permette di specificare esplicitamente qual è il valore di file descriptor che si vuole
avere come duplicato; il suo prototipo è:
#include <unistd.h>
int dup2(int oldfd, int newfd)
Rende newfd una copia del file descriptor oldfd.
La funzione ritorna il nuovo file descriptor in caso di successo e −1 in caso di errore, nel qual caso
EBADF oldfd non è un file aperto o newfd ha un valore fuori dall’intervallo consentito per i
file descriptor.
EMFILE si è raggiunto il numero massimo consentito di file descriptor aperti.
e qualora il file descriptor newfd sia già aperto (come avviene ad esempio nel caso della dupli-
cazione di uno dei file standard) esso sarà prima chiuso e poi duplicato (cos`ı che il file duplicato
sarà connesso allo stesso valore per il file descriptor).
La duplicazione dei file descriptor può essere effettuata anche usando la funzione di controllo
dei file fcntl (che esamineremo in sez. 6.3.6) con il parametro F_DUPFD. L’operazione ha la
sintassi fcntl(oldfd, F_DUPFD, newfd) e se si usa 0 come valore per newfd diventa equivalente
a dup.
La sola differenza fra le due funzioni17 è che dup2 chiude il file descriptor newfd se questo
è già aperto, garantendo che la duplicazione sia effettuata esattamente su di esso, invece fcntl
restituisce il primo file descriptor libero di valore uguale o maggiore di newfd (e se newfd è
aperto la duplicazione avverrà su un altro file descriptor).
6.3.5 Le funzioni openat, mkdirat e affini
Un problema che si pone con l’uso della funzione open, cos`ı come per molte altre funzioni che
accettano come argomenti dei pathname relativi, è che, quando un pathname relativo non fa
riferimento alla directory di lavoro corrente, è possibile che alcuni dei suoi componenti vengano
modificati in parallelo alla chiamata a open, e questo lascia aperta la possibilità di una race
condition.
Inoltre come già accennato, la directory di lavoro corrente è una proprietà del singolo pro-
cesso; questo significa che quando si lavora con i thread essa sarà la stessa per tutti, ma esistono
molti casi in cui sarebbe invece utile che ogni singolo thread avesse la sua directory di lavoro.
Per risolvere questi problemi, riprendendo una interfaccia già presente in Solaris, a fianco
delle normali funzioni che operano sui file (come open, mkdir, ecc.) sono state introdotte delle
ulteriori funzioni, dette anche funzioni “at” in quanto contraddistinte dal suffisso at, che per-
mettono l’apertura di un file (o le rispettive altre operazioni) usando un pathname relativo ad
una directory specificata.18 Benché queste funzioni non siano presenti negli standard tradizionali
esse sono state adottate da vari Unix19 fino ad essere incluse nella recente revisione (la POSIX.1-
2008) dello standard POSIX.1; con le glibc per l’accesso a queste funzioni è necessario definire
la macro _ATFILE_SOURCE.
L’uso di queste funzioni prevede una apertura iniziale della directory che sarà la base della
risoluzione dei pathname relativi che verranno usati in seguito, dopo di che si dovrà passare il
17
a parte la sintassi ed i diversi codici di errore.
18
l’introduzione è avvenuta su proposta dello sviluppatore principale delle glibc Urlich Drepper; le corrispondenti
system call sono state inserite nel kernel ufficiale a partire dalla versione 2.6.16, in precedenza era disponibile
una emulazione che, sia pure con prestazioni inferiori, funzionava facendo ricorso all’uso del filesystem proc con
l’apertura del file attraverso il riferimento a pathname del tipo di /proc/self/fd/dirfd/relative_path.
19
oltre a Linux e Solaris sono presenti in vari BSD.

relativo file descriptor alle varie funzioni che useranno quella directory come punto di partenza
per la risoluzione.20
Questo metodo, oltre a risolvere i problemi di race condition, consente anche di ottenere au-
menti di prestazioni significativi quando si devono eseguire molte operazioni su sezioni dell’albero
dei file che prevedono delle gerarchie di sottodirectory molto profonde; infatti in questo caso ba-
sta eseguire la risoluzione del pathname della directory di partenza una sola volta (nell’apertura
iniziale) e non tutte le volte che si deve accedere a ciascun file che essa contiene.
La sintassi generale di queste nuove funzioni è che esse prevedono come primo argomento il
file descriptor della directory da usare come base, mentre gli argomenti successivi restano identici
a quelli della corrispondente funzione ordinaria; ad esempio nel caso di openat avremo che essa
è definita come:
#include <fcntl.h>
int openat(int dirfd, const char *pathname, int flags)
int openat(int dirfd, const char *pathname, int flags, mode_t mode))
Apre un file usando come directory di lavoro corrente dirfd.
la funzione restituisce gli stessi valori e gli stessi codici di errore di open, ed in più:
EBADF dirfd non è un file descriptor valido.
ENOTDIR pathname è un pathname relativo, ma dirfd fa riferimento ad un file.
Il comportamento delle nuove funzioni è del tutto analogo a quello delle corrispettive classi-
che, con la sola eccezione del fatto che se fra i loro argomenti si utilizza un pathname relativo
questo sarà risolto rispetto alla directory indicata da dirfd; qualora invece si usi un pathna-
me assoluto dirfd verrà semplicemente ignorato. Infine se per dirfd si usa il valore speciale
AT_FDCWD,21 la risoluzione sarà effettuata rispetto alla directory di lavoro corrente del processo.
Cos`ı come il comportamento, anche i valori di ritorno e le condizioni di errore delle nuove
funzioni sono gli stessi delle funzioni classiche, agli errori si aggiungono però quelli dovuti a
valori errati per dirfd; in particolare si avrà un errore di EBADF se esso non è un file descriptor
valido, ed un errore di ENOTDIR se esso non fa riferimento ad una directory.22
In tab. 6.3 si sono riportate le funzioni introdotte con questa nuova interfaccia, con a fianco
la corrispondente funzione classica.23 La gran parte di queste seguono la convenzione appena
vista per openat, in cui agli argomenti della corrispondente funzione classica viene anteposto
l’argomento dirfd.24 Per una parte di queste, indicate dal contenuto della omonima colonna di
tab. 6.3, oltre al nuovo argomento iniziale, è prevista anche l’aggiunta di un ulteriore argomento
finale, flags.
Per tutte le funzioni che lo prevedono, a parte unlinkat e faccessat, l’ulteriore argomento
è stato introdotto solo per fornire un meccanismo con cui modificarne il comportamento nel caso
si stia operando su un link simbolico, cos`ı da poter scegliere se far agire la funzione direttamente
sullo stesso o sul file da esso referenziato. Dato che in certi casi esso può fornire ulteriori in-
dicazioni per modificare il comportamento delle funzioni, flags deve comunque essere passato
come maschera binaria, ed impostato usando i valori delle appropriate costanti AT_*, definite in
fcntl.h.
20
in questo modo, anche quando si lavora con i thread, si può mantenere una directory di lavoro diversa per
ciascuno di essi.
21
questa, come le altre costanti AT_*, è definita in fcntl.h, pertanto se la si vuole usare occorrerà includere
comunque questo file, anche per le funzioni che non sono definite in esso.
22
tranne il caso in cui si sia specificato un pathname assoluto, nel qual caso, come detto, il valore di dirfd sarà
completamente ignorato.
23
in realtà, come visto in sez. 5.1.8, le funzioni utimes e lutimes non sono propriamente le corrispondenti di
utimensat, dato che questa ha una maggiore precisione nella indicazione dei tempi dei file.
24
non staremo pertanto a riportarle una per una.
25
in questo caso l’argomento flags è disponibile ed utilizzabile solo a partire dal kernel 2.6.18.

Funzione Flags Corrispondente
faccessat • access
fchmodat • chmod
fchownat • chown,lchown
fstatat • stat,lstat
utimensat • utimes,lutimes
linkat •25
link
mkdirat – mkdir
mknodat – mknod
openat – open
readlinkat – readlink
renameat – rename
symlinkat – symlink
unlinkat • unlink,rmdir
mkfifoat – mkfifo
Tabella 6.3: Corrispondenze fra le nuove funzioni “at” e le corrispettive funzioni classiche.
Come esempio di questo secondo tipo di funzioni possiamo considerare fchownat, che può
essere usata per sostituire sia chown che lchown; il suo prototipo è:
#include <unistd.h>
#include <fcntl.h>
int fchownat(int dirfd, const char *pathname, uid_t owner, gid_t group, int
flags)
.Modifica la proprietà di un file.
la funzione restituisce gli stessi valori e gli stessi codici di errore di chown, ed in più:
EINVAL flags non ha un valore valido.
In questo caso il valore di flags stabilisce il comportamento della funzione quando la si
applica ad un link simbolico, e l’unico valore utilizzabile è AT_SYMLINK_NOFOLLOW26 che se im-
postato indica alla funzione di non eseguire la dereferenziazione di un eventuale link simbolico,
facendo comportare fchownat come lchown invece che come chown.
Come accennato fra tutte quelle marcate in tab. 6.3 solo due funzioni possono usare l’argo-
mento flags con valori diversi da AT_SYMLINK_NOFOLLOW, la prima di queste è faccessat, ed il
suo prototipo è:
#include <unistd.h>
int faccessat(int dirfd, const char *path, int mode, int flags)
Controlla i permessi di accesso.
la funzione restituisce gli stessi valori e gli stessi codici di errore di access, ed in più:
La funzione esegue lo stesso controllo di accesso effettuabile con access, ma si può utilizzare
l’argomento flags per modificarne il comportamento rispetto a quello ordinario di access. In
questo caso esso può essere specificato come maschera binaria di due valori:
26
in fcntl.h è definito anche AT_SYMLINK_FOLLOW, che richiede di dereferenziare i link simbolici, essendo questo
però il comportamento adottato per un valore nullo di flags questo valore non viene mai usato.

AT_EACCESS se impostato faccessat esegue il controllo dei permessi usando l’user-ID
effettivo invece di quello reale (il comportamento di default, che riprende
quello di access).
AT_SYMLINK_NOFOLLOW se impostato faccessat non esegue la dereferenziazione dei link simbo-
lici, effettuando il controllo dei permessi direttamente sugli stessi.
La seconda eccezione è unlinkat, in questo caso l’ulteriore argomento flags viene utilizzato
perché tramite esso la funzione possa comportarsi sia come analogo di unlink che di rmdir; il
suo prototipo è:
#include <fcntl.h>
int unlinkat(int dirfd, const char *pathname, int flags)
Rimuove una voce da una directory.
la funzione restituisce gli stessi valori e gli stessi codici di errore di unlink o di rmdir a seconda
del valore di flags, ed in più:
Di default il comportamento di unlinkat è equivalente a quello che avrebbe unlink applicata
a pathname, fallendo in tutti i casi in cui questo è una directory, se però si imposta flags al
valore di AT_REMOVEDIR,27 essa si comporterà come rmdir, in tal caso pathname deve essere una
directory, che sarà rimossa qualora risulti vuota.
6.3.6 La funzione fcntl
Oltre alle operazioni base esaminate in sez. 6.2 esistono tutta una serie di operazioni ausiliarie
che è possibile eseguire su un file descriptor, che non riguardano la normale lettura e scrittura
di dati, ma la gestione sia delle loro proprietà, che di tutta una serie di ulteriori funzionalità che
il kernel può mettere a disposizione.28
Per queste operazioni di manipolazione e di controllo delle varie proprietà e caratteristiche
di un file descriptor, viene usata la funzione fcntl, il cui prototipo è:
#include <unistd.h>
#include <fcntl.h>
int fcntl(int fd, int cmd)
int fcntl(int fd, int cmd, long arg)
int fcntl(int fd, int cmd, struct flock * lock)
Esegue una delle possibili operazioni specificate da cmd sul file fd.
La funzione ha valori di ritorno diversi a seconda dell’operazione. In caso di errore il valore di
ritorno è sempre −1 ed il codice dell’errore è restituito nella variabile errno; i codici possibili
dipendono dal tipo di operazione, l’unico valido in generale è:
EBADF fd non è un file aperto.
Il primo argomento della funzione è sempre il numero di file descriptor fd su cui si vuole
operare. Il comportamento di questa funzione, il numero e il tipo degli argomenti, il valore di
ritorno e gli eventuali errori sono determinati dal valore dell’argomento cmd che in sostanza cor-
risponde all’esecuzione di un determinato comando; in sez. 6.3.4 abbiamo incontrato un esempio
dell’uso di fcntl per la duplicazione dei file descriptor, una lista di tutti i possibili valori per
cmd è riportata di seguito:
27
anche se flags è una maschera binaria, essendo questo l’unico flag disponibile per questa funzione, lo si può
assegnare direttamente.
28
ad esempio si gestiscono con questa funzione varie modalità di I/O asincrono (vedi sez. 12.3.1) e il file locking
(vedi sez. 12.1).

F_DUPFD trova il primo file descriptor disponibile di valore maggiore o uguale ad arg e ne fa
una copia di fd. Ritorna il nuovo file descriptor in caso di successo e −1 in caso di
errore. Gli errori possibili sono EINVAL se arg è negativo o maggiore del massimo
consentito o EMFILE se il processo ha già raggiunto il massimo numero di descrittori
consentito.
F_SETFD imposta il valore del file descriptor flag al valore specificato con arg. Al momento
l’unico bit usato è quello di close-on-exec, identificato dalla costante FD_CLOEXEC,
che serve a richiedere che il file venga chiuso nella esecuzione di una exec (vedi
sez. 3.2.5). Ritorna un valore nullo in caso di successo e −1 in caso di errore.
F_GETFD ritorna il valore del file descriptor flag di fd o −1 in caso di errore; se FD_CLOEXEC
è impostato i file descriptor aperti vengono chiusi attraverso una exec altrimenti
(il comportamento predefinito) restano aperti.
F_GETFL ritorna il valore del file status flag in caso di successo o −1 in caso di errore; per-
mette cioè di rileggere quei bit impostati da open all’apertura del file che vengono
memorizzati (quelli riportati nella prima e terza sezione di tab. 6.2).
F_SETFL imposta il file status flag al valore specificato da arg, ritorna un valore nullo in
caso di successo o −1 in caso di errore. Possono essere impostati solo i bit riportati
nella terza sezione di tab. 6.2.29
F_GETLK richiede un controllo sul file lock specificato da lock, sovrascrivendo la struttura
da esso puntata con il risultato; ritorna un valore nullo in caso di successo o −1 in
caso di errore. Questa funzionalità è trattata in dettaglio in sez. 12.1.3.
F_SETLK richiede o rilascia un file lock a seconda di quanto specificato nella struttura puntata
da lock. Se il lock è tenuto da qualcun altro ritorna immediatamente restituendo
−1 e imposta errno a EACCES o EAGAIN, in caso di successo ritorna un valore nullo.
Questa funzionalità è trattata in dettaglio in sez. 12.1.3.
F_SETLKW identica a F_SETLK eccetto per il fatto che la funzione non ritorna subito ma attende
che il blocco sia rilasciato. Se l’attesa viene interrotta da un segnale la funzione
restituisce −1 e imposta errno a EINTR, in caso di successo ritorna un valore nullo.
Questa funzionalità è trattata in dettaglio in sez. 12.1.3.
F_GETOWN restituisce il pid del processo o l’identificatore del process group30 che è preposto alla
ricezione dei segnali SIGIO31 per gli eventi associati al file descriptor fd32 e SIGURG
per la notifica dei dati urgenti di un socket.33 Nel caso di un process group viene
restituito un valore negativo il cui valore assoluto corrisponde all’identificatore del
process group. In caso di errore viene restituito −1.
F_SETOWN imposta, con il valore dell’argomento arg, l’identificatore del processo o del process
group che riceverà i segnali SIGIO e SIGURG per gli eventi associati al file descriptor
fd, ritorna un valore nullo in caso di successo o −1 in caso di errore. Come per
F_GETOWN, per impostare un process group si deve usare per arg un valore negativo,
il cui valore assoluto corrisponde all’identificatore del process group.
29
la pagina di manuale riporta come impostabili solo O_APPEND, O_NONBLOCK e O_ASYNC.
30
i process group sono (vedi sez. 10.1.2) raggruppamenti di processi usati nel controllo di sessione; a ciascuno di
essi è associato un identificatore (un numero positivo analogo al pid).
31
o qualunque altro segnale alternativo impostato con F_FSETSIG.
32
il segnale viene usato sia per il Signal Drive I/O, che tratteremo in sez. 12.3.1, e dai vari meccanismi di notifica
asincrona, che tratteremo in sez. 12.3.2.
33
vedi sez. 19.1.3.

F_GETSIG restituisce il valore del segnale inviato quando ci sono dati disponibili in ingresso su
un file descriptor aperto ed impostato per l’I/O asincrono (si veda sez. 12.3.3). Il
valore 0 indica il valore predefinito (che è SIGIO), un valore diverso da zero indica
il segnale richiesto, (che può essere anche lo stesso SIGIO). In caso di errore ritorna
−1.
F_SETSIG imposta il segnale da inviare quando diventa possibile effettuare I/O sul file de-
scriptor in caso di I/O asincrono, ritorna un valore nullo in caso di successo o −1 in
caso di errore. Il valore zero indica di usare il segnale predefinito, SIGIO. Un altro
valore diverso da zero (compreso lo stesso SIGIO) specifica il segnale voluto; l’uso
di un valore diverso da zero permette inoltre, se si è installato il gestore del segnale
come sa_sigaction usando SA_SIGINFO, (vedi sez. 9.4.3), di rendere disponibili al
gestore informazioni ulteriori riguardo il file che ha generato il segnale attraverso i
valori restituiti in siginfo_t (come vedremo in sez. 12.3.3).34
F_SETLEASE imposta o rimuove un file lease35 sul file descriptor fd a seconda del valore del
terzo argomento, che in questo caso è un int, ritorna un valore nullo in caso di
successo o −1 in caso di errore. Questa funzionalità avanzata è trattata in dettaglio
in sez. 12.3.2.
F_GETLEASE restituisce il tipo di file lease che il processo detiene nei confronti del file descriptor
fd o −1 in caso di errore. Con questo comando il terzo argomento può essere omesso.
Questa funzionalità avanzata è trattata in dettaglio in sez. 12.3.2.
F_NOTIFY attiva un meccanismo di notifica per cui viene riportata al processo chiamante,
tramite il segnale SIGIO (o altro segnale specificato con F_SETSIG) ogni modifica
eseguita o direttamente sulla directory cui fd fa riferimento, o su uno dei file in
essa contenuti; ritorna un valore nullo in caso di successo o −1 in caso di errore.
Questa funzionalità avanzata, disponibile dai kernel della serie 2.4.x, è trattata in
dettaglio in sez. 12.3.2.
La maggior parte delle funzionalità di fcntl sono troppo avanzate per poter essere affrontate
in tutti i loro aspetti a questo punto; saranno pertanto riprese più avanti quando affronteremo
le problematiche ad esse relative. In particolare le tematiche relative all’I/O asincrono e ai vari
meccanismi di notifica saranno trattate in maniera esaustiva in sez. 12.3 mentre quelle relative al
file locking saranno esaminate in sez. 12.1). L’uso di questa funzione con i socket verrà trattato
in sez. 17.3.
Si tenga presente infine che quando si usa la funzione per determinare le modalità di accesso
con cui è stato aperto il file (attraverso l’uso del comando F_GETFL) è necessario estrarre i bit
corrispondenti nel file status flag che si è ottenuto. Infatti la definizione corrente di quest’ultimo
non assegna bit separati alle tre diverse modalità O_RDONLY, O_WRONLY e O_RDWR.36 Per questo
motivo il valore della modalità di accesso corrente si ottiene eseguendo un AND binario del valore
di ritorno di fcntl con la maschera O_ACCMODE (anch’essa definita in fcntl.h), che estrae i bit
di accesso dal file status flag.
6.3.7 La funzione ioctl
Benché il concetto di everything is a file si sia dimostrato molto valido anche per l’interazione
con i dispositivi più vari, fornendo una interfaccia che permette di interagire con essi tramite
34
i due comandi F_SETSIG e F_GETSIG sono una estensione specifica di Linux.
35
questa è una nuova funzionalità, specifica di Linux, e presente solo a partire dai kernel della serie 2.4.x, in cui
il processo che detiene un lease su un file riceve una notifica qualora un altro processo cerca di eseguire una open
o una truncate su di esso.
36
in Linux queste costanti sono poste rispettivamente ai valori 0, 1 e 2.

le stesse funzioni usate per i normali file di dati, esisteranno sempre caratteristiche peculiari,
specifiche dell’hardware e della funzionalità che ciascun dispositivo può provvedere, che non
possono venire comprese in questa interfaccia astratta (un caso tipico è l’impostazione della
velocità di una porta seriale, o le dimensioni di un framebuffer).
Per questo motivo nell’architettura del sistema è stata prevista l’esistenza di una funzione
apposita, ioctl, con cui poter compiere le operazioni specifiche di ogni dispositivo particolare,
usando come riferimento il solito file descriptor. Il prototipo di questa funzione è:
#include <sys/ioctl.h>
int ioctl(int fd, int request, ...)
Esegue l’operazione di controllo specificata da request sul file descriptor fd.
La funzione nella maggior parte dei casi ritorna 0, alcune operazioni usano però il valore di ritorno
per restituire informazioni. In caso di errore viene sempre restituito −1 ed errno assumerà uno
dei valori:
ENOTTY il file fd non è associato con un dispositivo, o la richiesta non è applicabile all’oggetto
a cui fa riferimento fd.
EINVAL gli argomenti request o argp non sono validi.
ed inoltre EBADF e EFAULT.
La funzione serve in sostanza come meccanismo generico per fare tutte quelle operazioni che
non rientrano nell’interfaccia ordinaria della gestione dei file e che non è possibile effettuare con
le funzioni esaminate finora. La funzione richiede che si passi come primo argomento un file
descriptor regolarmente aperto, e l’operazione da compiere viene selezionata attraverso il valore
dell’argomento request. Il terzo argomento dipende dall’operazione prescelta; tradizionalmente
è specificato come char * argp, da intendersi come puntatore ad un area di memoria generica,37
ma per certe operazioni può essere omesso, e per altre è un semplice intero.
Normalmente la funzione ritorna zero in caso di successo e −1 in caso di errore, ma per alcune
operazione il valore di ritorno, che nel caso viene impostato ad un valore positivo, può essere
utilizzato come parametro di uscita. È più comune comunque restituire i risultati all’indirizzo
puntato dal terzo argomento.
Data la genericità dell’interfaccia non è possibile classificare in maniera sistematica le ope-
razioni che si possono gestire con ioctl, un breve elenco di alcuni esempi di esse è il seguente:
• il cambiamento dei font di un terminale.
• l’esecuzione di una traccia audio di un CDROM.
• i comandi di avanti veloce e riavvolgimento di un nastro.
• il comando di espulsione di un dispositivo rimovibile.
• l’impostazione della velocità trasmissione di una linea seriale.
• l’impostazione della frequenza e della durata dei suoni emessi dallo speaker.
• l’impostazione degli attributi dei file su un filesystem ext2.38
In generale ogni dispositivo ha un suo insieme di operazioni specifiche effettuabili attraverso
ioctl, tutte queste sono definite nell’header file sys/ioctl.h, e devono essere usate solo sui
dispositivi cui fanno riferimento. Infatti anche se in genere i valori di request sono opportu-
namente differenziati a seconda del dispositivo39 cos`ı che la richiesta di operazioni relative ad
altri dispositivi usualmente provoca il ritorno della funzione con una condizione di errore, in
37
all’epoca della creazione di questa funzione infatti ancora non era stato introdotto il tipo void.
38
i comandi lsattr e chattr fanno questo con delle ioctl dedicate, usabili solo su questo filesystem e derivati
successivi (come ext3).
39
il kernel usa un apposito magic number per distinguere ciascun dispositivo nella definizione delle macro da
usare per request, in modo da essere sicuri che essi siano sempre diversi, ed il loro uso per dispositivi diversi causi
al più un errore. Si veda il capitolo quinto di [7] per una trattazione dettagliata dell’argomento.

alcuni casi, relativi a valori assegnati prima che questa differenziazione diventasse pratica cor-
rente, si potrebbero usare valori validi anche per il dispositivo corrente, con effetti imprevedibili
o indesiderati.
Data la assoluta specificità della funzione, il cui comportamento varia da dispositivo a di-
spositivo, non è possibile fare altro che dare una descrizione sommaria delle sue caratteristiche;
torneremo ad esaminare in seguito40 quelle relative ad alcuni casi specifici (ad esempio la ge-
stione dei terminali è effettuata attraverso ioctl in quasi tutte le implementazioni di Unix), qui
riportiamo solo l’elenco delle operazioni che sono predefinite per qualunque file,41 caratterizzate
dal prefisso FIO:
FIOCLEX imposta il flag di close-on-exec sul file, in questo caso, essendo usata come opera-
zione logica, ioctl non richiede un terzo argomento, il cui eventuale valore viene
ignorato.
FIONCLEX cancella il flag di close-on-exec sul file, in questo caso, essendo usata come opera-
zione logica, ioctl non richiede un terzo argomento, il cui eventuale valore viene
ignorato.
FIOASYNC abilita o disabilita la modalità di I/O asincrono sul file (vedi sez. 12.3.1); il terzo
argomento deve essere un puntatore ad un intero (cioè di tipo const int *) che
contiene un valore logico (un valore nullo disabilita, un valore non nullo abilita).
FIONBIO abilita o disabilita sul file l’I/O in modalità non bloccante; il terzo argomento deve
essere un puntatore ad un intero (cioè di tipo const int *) che contiene un valore
logico (un valore nullo disabilita, un valore non nullo abilita).
FIOSETOWN imposta il processo che riceverà i segnali SIGURG e SIGIO generati sul file; il terzo
argomento deve essere un puntatore ad un intero (cioè di tipo const int *) il cui
valore specifica il PID del processo.
FIOGETOWN legge il processo che riceverà i segnali SIGURG e SIGIO generati sul file; il terzo
argomento deve essere un puntatore ad un intero (cioè di tipo int *) su cui sarà
scritto il PID del processo.
FIONREAD legge il numero di byte disponibili in lettura sul file descriptor;42 il terzo argomento
deve essere un puntatore ad un intero (cioè di tipo int *) su cui sarà restituito il
valore.
FIOQSIZE restituisce la dimensione corrente di un file o di una directory, mentre se applicata
ad un dispositivo fallisce con un errore di ENOTTY; il terzo argomento deve essere
un puntatore ad un intero (cioè di tipo int *) su cui sarà restituito il valore.
Si noti però come la gran parte di queste operazioni specifiche dei file (per essere precisi
le prime sei dell’elenco) siano effettuabili in maniera generica anche tramite l’uso di fcntl. Le
due funzioni infatti sono molto simili e la presenza di questa sovrapposizione è principalmente
dovuta al fatto che alle origini di Unix i progettisti considerarono che era necessario trattare
diversamente rispetto alle operazione di controllo delle modalità di I/O file e dispositivi usando
fcntl per i primi e ioctl per i secondi;43 oggi non è più cos`ı ma le due funzioni sono rimaste.
40
per l’uso di ioctl con i socket si veda sez. 17.3.
41
in particolare queste operazioni sono definite nel kernel a livello generale, e vengono sempre interpretate per
prime, per cui, come illustrato in [7], eventuali operazioni specifiche che usino lo stesso valore verrebbero ignorate.
42
questa operazione è disponibile solo su alcuni file descriptor, in particolare sui socket (vedi sez. 17.3.3) o sui
file descriptor di epoll (vedi sez. 12.2.4).
43
all’epoca tra l’altro i dispositivi che usavano ioctl erano sostanzialmente solo i terminali, il che spiega l’uso
comune di ENOTTY come codice di errore.

Capitolo 7
I file: l’interfaccia standard ANSI C
Esamineremo in questo capitolo l’interfaccia standard ANSI C per i file, quella che viene co-
munemente detta interfaccia degli stream. Dopo una breve sezione introduttiva tratteremo le
funzioni base per la gestione dell’input/output, mentre tratteremo le caratteristiche più avanzate
dell’interfaccia nell’ultima sezione.
7.1 Introduzione
Come visto in cap. 6 le operazioni di I/O sui file sono gestibili a basso livello con l’interfaccia
standard unix, che ricorre direttamente alle system call messe a disposizione dal kernel.
Questa interfaccia però non provvede le funzionalità previste dallo standard ANSI C, che
invece sono realizzate attraverso opportune funzioni di libreria, queste, insieme alle altre funzioni
definite dallo standard, vengono a costituire il nucleo1 delle glibc.
7.1.1 I file stream
Come più volte ribadito, l’interfaccia dei file descriptor è un’interfaccia di basso livello, che
non provvede nessuna forma di formattazione dei dati e nessuna forma di bufferizzazione per
ottimizzare le operazioni di I/O.
In [1] Stevens descrive una serie di test sull’influenza delle dimensioni del blocco di dati
(l’argomento buf di read e write) nell’efficienza nelle operazioni di I/O con i file descriptor,
evidenziando come le prestazioni ottimali si ottengano a partire da dimensioni del buffer dei dati
pari a quelle dei blocchi del filesystem (il valore dato dal campo st_blksize di stat), che di
norma corrispondono alle dimensioni dei settori fisici in cui è suddiviso il disco.
Se il programmatore non si cura di effettuare le operazioni in blocchi di dimensioni adeguate,
le prestazioni sono inferiori. La caratteristica principale dell’interfaccia degli stream è che essa
provvede da sola alla gestione dei dettagli della bufferizzazione e all’esecuzione delle operazioni di
lettura e scrittura in blocchi di dimensioni appropriate all’ottenimento della massima efficienza.
Per questo motivo l’interfaccia viene chiamata anche interfaccia dei file stream, dato che non
è più necessario doversi preoccupare dei dettagli della comunicazione con il tipo di hardware
sottostante (come nel caso della dimensione dei blocchi del filesystem), ed un file può essere
sempre considerato come composto da un flusso continuo (da cui il nome stream) di dati.
A parte i dettagli legati alla gestione delle operazioni di lettura e scrittura (sia per quel che
riguarda la bufferizzazione, che le formattazioni), i file stream restano del tutto equivalenti ai file
descriptor (sui quali sono basati), ed in particolare continua a valere quanto visto in sez. 6.3.1 a
proposito dell’accesso condiviso ed in sez. 5.3 per il controllo di accesso.
1
queste funzioni sono state implementate la prima volta da Ritchie nel 1976 e da allora sono rimaste
sostanzialmente immutate.
203

204 CAPITOLO 7. I FILE: L’INTERFACCIA STANDARD ANSI C
7.1.2 Gli oggetti FILE
Per ragioni storiche la struttura di dati che rappresenta uno stream è stata chiamata FILE, questi
oggetti sono creati dalle funzioni di libreria e contengono tutte le informazioni necessarie a gestire
le operazioni sugli stream, come la posizione corrente, lo stato del buffer e degli indicatori di
stato e di fine del file.
Per questo motivo gli utenti non devono mai utilizzare direttamente o allocare queste strut-
ture (che sono dei tipi opachi) ma usare sempre puntatori del tipo FILE * ottenuti dalla libreria
stessa (tanto che in certi casi il termine di puntatore a file è diventato sinonimo di stream). Tutte
le funzioni della libreria che operano sui file accettano come argomenti solo variabili di questo
tipo, che diventa accessibile includendo l’header file stdio.h.
7.1.3 Gli stream standard
Ai tre file descriptor standard (vedi sez. 6.1.2) aperti per ogni processo, corrispondono altrettanti
stream, che rappresentano i canali standard di input/output prestabiliti; anche questi tre stream
sono identificabili attraverso dei nomi simbolici definiti nell’header stdio.h che sono:
FILE *stdin Lo standard input cioè lo stream da cui il processo riceve ordinariamente i
dati in ingresso. Normalmente è associato dalla shell all’input del terminale
e prende i caratteri dalla tastiera.
FILE *stdout Lo standard output cioè lo stream su cui il processo invia ordinariamente i
dati in uscita. Normalmente è associato dalla shell all’output del terminale e
scrive sullo schermo.
FILE *stderr Lo standard error cioè lo stream su cui il processo è supposto inviare i mes-
saggi di errore. Normalmente anch’esso è associato dalla shell all’output del
terminale e scrive sullo schermo.
Nelle glibc stdin, stdout e stderr sono effettivamente tre variabili di tipo FILE * che
possono essere usate come tutte le altre, ad esempio si può effettuare una redirezione dell’output
di un programma con il semplice codice:
fclose(stdout );
stdout = fopen("standard -output -file", "w");
ma in altri sistemi queste variabili possono essere definite da macro, e se si hanno problemi di
portabilità e si vuole essere sicuri, diventa opportuno usare la funzione freopen.
7.1.4 Le modalità di bufferizzazione
La bufferizzazione è una delle caratteristiche principali dell’interfaccia degli stream; lo scopo è
quello di ridurre al minimo il numero di system call (read o write) eseguite nelle operazioni di
input/output. Questa funzionalità è assicurata automaticamente dalla libreria, ma costituisce
anche uno degli aspetti più comunemente fraintesi, in particolare per quello che riguarda l’aspetto
della scrittura dei dati sul file.
I caratteri che vengono scritti su di uno stream normalmente vengono accumulati in un buffer
e poi trasmessi in blocco2 tutte le volte che il buffer viene riempito, in maniera asincrona rispetto
alla scrittura. Un comportamento analogo avviene anche in lettura (cioè dal file viene letto un
blocco di dati, anche se ne sono richiesti una quantità inferiore), ma la cosa ovviamente ha
rilevanza inferiore, dato che i dati letti sono sempre gli stessi. In caso di scrittura invece, quando
2
questa operazione viene usualmente chiamata scaricamento dei dati, dal termine inglese flush.

7.2. FUNZIONI BASE 205
si ha un accesso contemporaneo allo stesso file (ad esempio da parte di un altro processo) si
potranno vedere solo le parti effettivamente scritte, e non quelle ancora presenti nel buffer.
Per lo stesso motivo, in tutte le situazioni in cui si sta facendo dell’input/output interattivo,
bisognerà tenere presente le caratteristiche delle operazioni di scaricamento dei dati, poiché non
è detto che ad una scrittura sullo stream corrisponda una immediata scrittura sul dispositivo
(la cosa è particolarmente evidente quando con le operazioni di input/output su terminale).
Per rispondere ad esigenze diverse, lo standard definisce tre distinte modalità in cui può
essere eseguita la bufferizzazione, delle quali occorre essere ben consapevoli, specie in caso di
lettura e scrittura da dispositivi interattivi:
• unbuffered: in questo caso non c’è bufferizzazione ed i caratteri vengono trasmessi diretta-
mente al file non appena possibile (effettuando immediatamente una write).
• line buffered: in questo caso i caratteri vengono normalmente trasmessi al file in blocco
ogni volta che viene incontrato un carattere di newline (il carattere ASCII n).
• fully buffered: in questo caso i caratteri vengono trasmessi da e verso il file in blocchi di
dimensione opportuna.
Lo standard ANSI C specifica inoltre che lo standard output e lo standard input siano aperti
in modalità fully buffered quando non fanno riferimento ad un dispositivo interattivo, e che lo
standard error non sia mai aperto in modalità fully buffered.
Linux, come BSD e SVr4, specifica il comportamento predefinito in maniera ancora più
precisa, e cioè impone che lo standard error sia sempre unbuffered (in modo che i messaggi di
errore siano mostrati il più rapidamente possibile) e che standard input e standard output siano
aperti in modalità line buffered quando sono associati ad un terminale (od altro dispositivo
interattivo) ed in modalità fully buffered altrimenti.
Il comportamento specificato per standard input e standard output vale anche per tutti i
nuovi stream aperti da un processo; la selezione comunque avviene automaticamente, e la libreria
apre lo stream nella modalità più opportuna a seconda del file o del dispositivo scelto.
La modalità line buffered è quella che necessita di maggiori chiarimenti e attenzioni per
quel che concerne il suo funzionamento. Come già accennato nella descrizione, di norma i dati
vengono inviati al kernel alla ricezione di un carattere di a capo (newline); questo non è vero
in tutti i casi, infatti, dato che le dimensioni del buffer usato dalle librerie sono fisse, se le si
eccedono si può avere uno scarico dei dati anche prima che sia stato inviato un carattere di
newline.
Un secondo punto da tenere presente, particolarmente quando si ha a che fare con I/O
interattivo, è che quando si effettua una lettura da uno stream che comporta l’accesso al kernel3
viene anche eseguito lo scarico di tutti i buffer degli stream in scrittura.
In sez. 7.3.2 vedremo come la libreria definisca delle opportune funzioni per controllare le
modalità di bufferizzazione e lo scarico dei dati.
7.2 Funzioni base
Esamineremo in questa sezione le funzioni base dell’interfaccia degli stream, analoghe a quelle
di sez. 6.2 per i file descriptor. In particolare vedremo come aprire, leggere, scrivere e cambiare
la posizione corrente in uno stream.
3
questo vuol dire che lo stream da cui si legge è in modalità unbuffered.

7.2.1 Apertura e chiusura di uno stream
Le funzioni che si possono usare per aprire uno stream sono solo tre: fopen, fdopen e freopen,4
i loro prototipi sono:
#include <stdio.h>
FILE *fopen(const char *path, const char *mode)
Apre il file specificato da path.
FILE *fdopen(int fildes, const char *mode)
Associa uno stream al file descriptor fildes.
FILE *freopen(const char *path, const char *mode, FILE *stream)
Apre il file specificato da path associandolo allo stream specificato da stream, se questo è
già aperto prima lo chiude.
Le funzioni ritornano un puntatore valido in caso di successo e NULL in caso di errore, in tal caso
errno assumerà il valore ricevuto dalla funzione sottostante di cui è fallita l’esecuzione.
Gli errori pertanto possono essere quelli di malloc per tutte e tre le funzioni, quelli open per
fopen, quelli di fcntl per fdopen e quelli di fopen, fclose e fflush per freopen.
Normalmente la funzione che si usa per aprire uno stream è fopen, essa apre il file specificato
nella modalità specificata da mode, che è una stringa che deve iniziare con almeno uno dei valori
indicati in tab. 7.1 (sono possibili varie estensioni che vedremo in seguito).
L’uso più comune di freopen è per redirigere uno dei tre file standard (vedi sez. 7.1.3): il
file path viene associato a stream e se questo è uno stream già aperto viene preventivamente
chiuso.
Infine fdopen viene usata per associare uno stream ad un file descriptor esistente ottenuto
tramite una altra funzione (ad esempio con una open, una dup, o una pipe) e serve quando si
vogliono usare gli stream con file come le fifo o i socket, che non possono essere aperti con le
funzioni delle librerie standard del C.
Valore Significato
r Il file viene aperto, l’accesso viene posto in sola lettura,
lo stream è posizionato all’inizio del file.
r+ Il file viene aperto, l’accesso viene posto in lettura e
scrittura, lo stream è posizionato all’inizio del file.
w Il file viene aperto e troncato a lunghezza nulla (o creato
se non esiste), l’accesso viene posto in sola scrittura, lo
stream è posizionato all’inizio del file.
w+ Il file viene aperto e troncato a lunghezza nulla (o creato
se non esiste), l’accesso viene posto in scrittura e lettura,
lo stream è posizionato all’inizio del file.
a Il file viene aperto (o creato se non esiste) in append mode,
l’accesso viene posto in sola scrittura.
a+ Il file viene aperto (o creato se non esiste) in append mode,
l’accesso viene posto in lettura e scrittura.
b Specifica che il file è binario, non ha alcun effetto.
x L’apertura fallisce se il file esiste già.
Tabella 7.1: Modalità di apertura di uno stream dello standard ANSI C che sono sempre presenti in qualunque
sistema POSIX.
In realtà lo standard ANSI C prevede un totale di 15 possibili valori diversi per mode, ma in
tab. 7.1 si sono riportati solo i sei valori effettivi, ad essi può essere aggiunto pure il carattere b
(come ultimo carattere o nel mezzo agli altri per le stringhe di due caratteri) che in altri sistemi
operativi serve a distinguere i file binari dai file di testo; in un sistema POSIX questa distinzione
non esiste e il valore viene accettato solo per compatibilità, ma non ha alcun effetto.
4
fopen e freopen fanno parte dello standard ANSI C, fdopen è parte dello standard POSIX.1.

Le glibc supportano alcune estensioni, queste devono essere sempre indicate dopo aver speci-
ficato il mode con uno dei valori di tab. 7.1. L’uso del carattere x serve per evitare di sovrascrivere
un file già esistente (è analoga all’uso dell’opzione O_EXCL in open), se il file specificato già esiste
e si aggiunge questo carattere a mode la fopen fallisce.
Un’altra estensione serve a supportare la localizzazione, quando si aggiunge a mode una
stringa della forma ",ccs=STRING" il valore STRING è considerato il nome di una codifica dei
caratteri e fopen marca il file per l’uso dei caratteri estesi e abilita le opportune funzioni di
conversione in lettura e scrittura.
Nel caso si usi fdopen i valori specificati da mode devono essere compatibili con quelli con
cui il file descriptor è stato aperto. Inoltre i modi w e w+ non troncano il file. La posizione nello
stream viene impostata a quella corrente nel file descriptor, e le variabili di errore e di fine del
file (vedi sez. 7.2.2) sono cancellate. Il file non viene duplicato e verrà chiuso alla chiusura dello
stream.
I nuovi file saranno creati secondo quanto visto in sez. 5.3.4 ed avranno i permessi di ac-
cesso impostati al valore S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH (pari a 0666)
modificato secondo il valore di umask per il processo (si veda sez. 5.3.3).
In caso di file aperti in lettura e scrittura occorre ricordarsi che c’è di mezzo una bufferizza-
zione; per questo motivo lo standard ANSI C richiede che ci sia un’operazione di posizionamento
fra un’operazione di output ed una di input o viceversa (eccetto il caso in cui l’input ha incontra-
to la fine del file), altrimenti una lettura può ritornare anche il risultato di scritture precedenti
l’ultima effettuata.
Per questo motivo è una buona pratica (e talvolta necessario) far seguire ad una scrittura
una delle funzioni fflush, fseek, fsetpos o rewind prima di eseguire una rilettura; viceversa
nel caso in cui si voglia fare una scrittura subito dopo aver eseguito una lettura occorre prima
usare una delle funzioni fseek, fsetpos o rewind. Anche un’operazione nominalmente nulla
come fseek(file, 0, SEEK_CUR) è sufficiente a garantire la sincronizzazione.
Una volta aperto lo stream, si può cambiare la modalità di bufferizzazione (si veda sez. 7.3.2)
fintanto che non si è effettuato alcuna operazione di I/O sul file.
Uno stream viene chiuso con la funzione fclose il cui prototipo è:
#include <stdio.h>
int fclose(FILE *stream)
Chiude lo stream stream.
Restituisce 0 in caso di successo e EOF in caso di errore, nel qual caso imposta errno a EBADF
se il file descriptor indicato da stream non è valido, o uno dei valori specificati dalla sottostante
funzione che è fallita (close, write o fflush).
La funzione effettua lo scarico di tutti i dati presenti nei buffer di uscita e scarta tutti i dati
in ingresso; se era stato allocato un buffer per lo stream questo verrà rilasciato. La funzione
effettua lo scarico solo per i dati presenti nei buffer in user space usati dalle glibc; se si vuole
essere sicuri che il kernel forzi la scrittura su disco occorrerà effettuare una sync (vedi sez. 6.3.3).
Linux supporta anche una altra funzione, fcloseall, come estensione GNU implementata
dalle glibc, accessibile avendo definito _GNU_SOURCE, il suo prototipo è:
#include <stdio.h>
int fcloseall(void)
Chiude tutti gli stream.
Restituisce 0 se non ci sono errori ed EOF altrimenti.
la funzione esegue lo scarico dei dati bufferizzati in uscita e scarta quelli in ingresso, chiudendo
tutti i file. Questa funzione è provvista solo per i casi di emergenza, quando si è verificato un
errore ed il programma deve essere abortito, ma si vuole compiere qualche altra operazione dopo
aver chiuso i file e prima di uscire (si ricordi quanto visto in sez. 2.1.3).

7.2.2 Lettura e scrittura su uno stream
Una delle caratteristiche più utili dell’interfaccia degli stream è la ricchezza delle funzioni di-
sponibili per le operazioni di lettura e scrittura sui file. Sono infatti previste ben tre diverse
modalità modalità di input/output non formattato:
1. binario in cui legge/scrive un blocco di dati alla volta, vedi sez. 7.2.3.
2. a caratteri in cui si legge/scrive un carattere alla volta (con la bufferizzazione gestita
automaticamente dalla libreria), vedi sez. 7.2.4.
3. di linea in cui si legge/scrive una linea alla volta (terminata dal carattere di newline ’n’),
vedi sez. 7.2.5.
ed inoltre la modalità di input/output formattato.
A differenza dell’interfaccia dei file descriptor, con gli stream il raggiungimento della fine del
file è considerato un errore, e viene notificato come tale dai valori di uscita delle varie funzioni.
Nella maggior parte dei casi questo avviene con la restituzione del valore intero (di tipo int)
EOF5 definito anch’esso nell’header stdlib.h.
Dato che le funzioni dell’interfaccia degli stream sono funzioni di libreria che si appoggiano
a delle system call, esse non impostano direttamente la variabile errno, che mantiene il valore
impostato dalla system call che ha riportato l’errore.
Siccome la condizione di end-of-file è anch’essa segnalata come errore, nasce il problema
di come distinguerla da un errore effettivo; basarsi solo sul valore di ritorno della funzione e
controllare il valore di errno infatti non basta, dato che quest’ultimo potrebbe essere stato
impostato in una altra occasione, (si veda sez. 8.5.1 per i dettagli del funzionamento di errno).
Per questo motivo tutte le implementazioni delle librerie standard mantengono per ogni
stream almeno due flag all’interno dell’oggetto FILE, il flag di end-of-file, che segnala che si è
raggiunta la fine del file in lettura, e quello di errore, che segnala la presenza di un qualche
errore nelle operazioni di input/output; questi due flag possono essere riletti dalle funzioni feof
e ferror, i cui prototipi sono:
#include <stdio.h>
int feof(FILE *stream)
Controlla il flag di end-of-file di stream.
int ferror(FILE *stream)
Controlla il flag di errore di stream.
Entrambe le funzioni ritornano un valore diverso da zero se i relativi flag sono impostati.
si tenga presente comunque che la lettura di questi flag segnala soltanto che c’è stato un errore,
o che si è raggiunta la fine del file in una qualunque operazione sullo stream, il controllo quindi
deve essere effettuato ogni volta che si chiama una funzione di libreria.
Entrambi i flag (di errore e di end-of-file) possono essere cancellati usando la funzione
clearerr, il cui prototipo è:
#include <stdio.h>
void clearerr(FILE *stream)
Cancella i flag di errore ed end-of-file di stream.
in genere si usa questa funzione una volta che si sia identificata e corretta la causa di un errore
per evitare di mantenere i flag attivi, cos`ı da poter rilevare una successiva ulteriore condizione
di errore. Di questa funzione esiste una analoga clearerr_unlocked che non esegue il blocco
dello stream (vedi sez. 7.3.3).
5
la costante deve essere negativa, le glibc usano -1, altre implementazioni possono avere valori diversi.

7.2.3 Input/output binario
La prima modalità di input/output non formattato ricalca quella della interfaccia dei file de-
scriptor, e provvede semplicemente la scrittura e la lettura dei dati da un buffer verso un file
e viceversa. In generale questa è la modalità che si usa quando si ha a che fare con dati non
formattati. Le due funzioni che si usano per l’I/O binario sono fread ed fwrite; i loro prototipi
sono:
#include <stdio.h>
size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream)
size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream)
Rispettivamente leggono e scrivono nmemb elementi di dimensione size dal buffer ptr al file
stream.
Entrambe le funzioni ritornano il numero di elementi letti o scritti, in caso di errore o fine del file
viene restituito un numero di elementi inferiore al richiesto.
In genere si usano queste funzioni quando si devono trasferire su file blocchi di dati binari in
maniera compatta e veloce; un primo caso di uso tipico è quello in cui si salva un vettore (o un
certo numero dei suoi elementi) con una chiamata del tipo:
int WriteVect(FILE *stream , double *vec , size_t nelem)
{
int size , nread;
size = sizeof (*vec);
if ( (nread = fwrite(vec , size , nelem , stream )) != nelem) {
perror("Write error");
}
return nread;
}
in questo caso devono essere specificate le dimensioni di ciascun elemento ed il numero di quelli
che si vogliono scrivere. Un secondo caso è invece quello in cui si vuole trasferire su file una
struttura; si avrà allora una chiamata tipo:
struct histogram {
int nbins;
double max , min;
double *bin;
} histo;
int WriteStruct(FILE *stream , struct histogram *histo)
{
if ( fwrite(histo , sizeof (* histo), 1, stream) !=1) {
perror("Write error");
}
return nread;
}
in cui si specifica la dimensione dell’intera struttura ed un solo elemento.
In realtà quello che conta nel trasferimento dei dati sono le dimensioni totali, che sono sempre
pari al prodotto size * nelem; la sola differenza è che le funzioni non ritornano il numero di
byte scritti, ma il numero di elementi.
La funzione fread legge sempre un numero intero di elementi, se incontra la fine del file
l’oggetto letto parzialmente viene scartato (lo stesso avviene in caso di errore). In questo caso
la posizione dello stream viene impostata alla fine del file (e non a quella corrispondente alla
quantità di dati letti).

In caso di errore (o fine del file per fread) entrambe le funzioni restituiscono il numero
di oggetti effettivamente letti o scritti, che sarà inferiore a quello richiesto. Contrariamente a
quanto avviene per i file descriptor, questo segnala una condizione di errore e occorrerà usare
feof e ferror per stabilire la natura del problema.
Benché queste funzioni assicurino la massima efficienza per il salvataggio dei dati, i dati me-
morizzati attraverso di esse presentano lo svantaggio di dipendere strettamente dalla piattaforma
di sviluppo usata ed in genere possono essere riletti senza problemi solo dallo stesso programma
che li ha prodotti.
Infatti diversi compilatori possono eseguire ottimizzazioni diverse delle strutture dati e alcuni
compilatori (come il gcc) possono anche scegliere se ottimizzare l’occupazione di spazio, impac-
chettando più strettamente i dati, o la velocità inserendo opportuni padding per l’allineamento
dei medesimi generando quindi output binari diversi. Inoltre altre incompatibilità si possono
presentare quando entrano in gioco differenze di architettura hardware, come la dimensione del
bus o la modalità di ordinamento dei bit o il formato delle variabili in floating point.
Per questo motivo quando si usa l’input/output binario occorre sempre prendere le opportune
precauzioni (in genere usare un formato di più alto livello che permetta di recuperare l’informa-
zione completa), per assicurarsi che versioni diverse del programma siano in grado di rileggere i
dati tenendo conto delle eventuali differenze.
Le glibc definiscono altre due funzioni per l’I/O binario, fread_unlocked e fwrite_unlocked
che evitano il lock implicito dello stream, usato per dalla librerie per la gestione delle applicazioni
multi-thread (si veda sez. 7.3.3 per i dettagli), i loro prototipi sono:
#include <stdio.h>
size_t fread_unlocked(void *ptr, size_t size, size_t nmemb, FILE *stream)
size_t fwrite_unlocked(const void *ptr, size_t size, size_t nmemb, FILE *stream)
Le funzioni sono identiche alle analoghe fread e fwrite ma non acquisiscono il lock implicito sullo
stream.
entrambe le funzioni sono estensioni GNU previste solo dalle glibc.
7.2.4 Input/output a caratteri
La seconda modalità di input/output è quella a caratteri, in cui si trasferisce un carattere alla
volta. Le funzioni per la lettura a caratteri sono tre, fgetc, getc e getchar, i rispettivi prototipi
sono:
#include <stdio.h>
int getc(FILE *stream)
Legge un byte da stream e lo restituisce come intero. In genere è implementata come una
macro.
int fgetc(FILE *stream)
Legge un byte da stream e lo restituisce come intero. È sempre una funzione.
int getchar(void)
Equivalente a getc(stdin).
Tutte queste funzioni leggono un byte alla volta, che viene restituito come intero; in caso di errore
o fine del file il valore di ritorno è EOF.
A parte getchar, che si usa in genere per leggere un carattere da tastiera, le altre due
funzioni sono sostanzialmente equivalenti. La differenza è che getc è ottimizzata al massimo e
normalmente viene implementata con una macro, per cui occorre stare attenti a cosa le si passa
come argomento, infatti stream può essere valutato più volte nell’esecuzione, e non viene passato
in copia con il meccanismo visto in sez. 2.4.1; per questo motivo se si passa un’espressione si
possono avere effetti indesiderati.
Invece fgetc è assicurata essere sempre una funzione, per questo motivo la sua esecuzione
normalmente è più lenta per via dell’overhead della chiamata, ma è altres`ı possibile ricavarne

l’indirizzo, che può essere passato come argomento ad un altra funzione (e non si hanno i problemi
accennati in precedenza nel tipo di argomento).
Le tre funzioni restituiscono tutte un unsigned char convertito ad int (si usa unsigned
char in modo da evitare l’espansione del segno). In questo modo il valore di ritorno è sempre
positivo, tranne in caso di errore o fine del file.
Nelle estensioni GNU che provvedono la localizzazione sono definite tre funzioni equivalenti
alle precedenti, getwc, fgetwc e getwchar, che invece di un carattere di un byte restituiscono
un carattere in formato esteso (cioè di tipo wint_t), il loro prototipo è:
#include <stdio.h>
#include <wchar.h>
wint_t getwc(FILE *stream)
Legge un carattere esteso da stream. In genere è implementata come una macro.
wint_t fgetwc(FILE *stream)
Legge un carattere esteso da stream. È una sempre una funzione.
wint_t getwchar(void)
Equivalente a getwc(stdin).
Tutte queste funzioni leggono un carattere alla volta, in caso di errore o fine del file il valore di
ritorno è WEOF.
Per scrivere un carattere si possono usare tre funzioni, analoghe alle precedenti usate per
leggere: putc, fputc e putchar; i loro prototipi sono:
#include <stdio.h>
int putc(int c, FILE *stream)
Scrive il carattere c su stream. In genere è implementata come una macro.
int fputc(int c, FILE *stream)
Scrive il carattere c su stream. È una sempre una funzione.
int putchar(int c)
Equivalente a putc(stdout).
Le funzioni scrivono sempre un carattere alla volta, il cui valore viene restituito in caso di successo;
in caso di errore o fine del file il valore di ritorno è EOF.
Tutte queste funzioni scrivono sempre un byte alla volta, anche se prendono come argomento
un int (che pertanto deve essere ottenuto con un cast da un unsigned char). Anche il valore
di ritorno è sempre un intero; in caso di errore o fine del file il valore di ritorno è EOF.
Come nel caso dell’I/O binario con fread e fwrite le glibc provvedono come estensione,
per ciascuna delle funzioni precedenti, un’ulteriore funzione, il cui nome è ottenuto aggiungendo
un _unlocked, che esegue esattamente le stesse operazioni, evitando però il lock implicito dello
stream.
Per compatibilità con SVID sono inoltre provviste anche due funzioni, getw e putw, da usare
per leggere e scrivere una word (cioè due byte in una volta); i loro prototipi sono:
#include <stdio.h>
int getw(FILE *stream)
Legge una parola da stream.
int putw(int w, FILE *stream)
Scrive la parola w su stream.
Le funzioni restituiscono la parola w, o EOF in caso di errore o di fine del file.
Le funzioni leggono e scrivono una word di due byte, usando comunque una variabile di
tipo int; il loro uso è deprecato in favore dell’uso di fread e fwrite, in quanto non è possibile
distinguere il valore -1 da una condizione di errore che restituisce EOF.
Uno degli usi più frequenti dell’input/output a caratteri è nei programmi di parsing in cui si
analizza il testo; in questo contesto diventa utile poter analizzare il carattere successivo da uno
stream senza estrarlo effettivamente (la tecnica è detta peeking ahead) in modo che il programma
possa regolarsi avendo dato una sbirciatina a quello che viene dopo.

Nel nostro caso questo tipo di comportamento può essere realizzato prima leggendo il ca-
rattere, e poi rimandandolo indietro, cosicché ridiventi disponibile per una lettura successiva; la
funzione che inverte la lettura si chiama ungetc ed il suo prototipo è:
#include <stdio.h>
int ungetc(int c, FILE *stream)
Rimanda indietro il carattere c, con un cast a unsigned char, sullo stream stream.
La funzione ritorna c in caso di successo e EOF in caso di errore.
benché lo standard ANSI C preveda che l’operazione possa essere ripetuta per un numero arbi-
trario di caratteri, alle implementazioni è richiesto di garantire solo un livello; questo è quello
che fa la glibc, che richiede che avvenga un’altra operazione fra due ungetc successive.
Non è necessario che il carattere che si manda indietro sia l’ultimo che si è letto, e non è
necessario neanche avere letto nessun carattere prima di usare ungetc, ma di norma la funzione
è intesa per essere usata per rimandare indietro l’ultimo carattere letto.
Nel caso c sia un EOF la funzione non fa nulla, e restituisce sempre EOF; cos`ı si può usare
ungetc anche con il risultato di una lettura alla fine del file.
Se si è alla fine del file si può comunque rimandare indietro un carattere, il flag di end-of-file
verrà automaticamente cancellato perché c’è un nuovo carattere disponibile che potrà essere
riletto successivamente.
Infine si tenga presente che ungetc non altera il contenuto del file, ma opera esclusivamen-
te sul buffer interno. Se si esegue una qualunque delle operazioni di riposizionamento (vedi
sez. 7.2.7) i caratteri rimandati indietro vengono scartati.
7.2.5 Input/output di linea
La terza ed ultima modalità di input/output non formattato è quella di linea, in cui si legge o
si scrive una riga alla volta; questa è una modalità molto usata per l’I/O da terminale, ma è
anche quella che presenta le caratteristiche più controverse.
Le funzioni previste dallo standard ANSI C per leggere una linea sono sostanzialmente due,
gets e fgets, i cui rispettivi prototipi sono:
#include <stdio.h>
char *gets(char *string)
Scrive su string una linea letta da stdin.
char *fgets(char *string, int size, FILE *stream)
Scrive su string la linea letta da stream per un massimo di size byte.
Le funzioni restituiscono l’indirizzo string in caso di successo o NULL in caso di errore.
Entrambe le funzioni effettuano la lettura (dal file specificato fgets, dallo standard input
gets) di una linea di caratteri (terminata dal carattere newline, ’n’, quello mappato sul tasto
di ritorno a capo della tastiera), ma gets sostituisce ’n’ con uno zero, mentre fgets aggiunge
uno zero dopo il newline, che resta dentro la stringa. Se la lettura incontra la fine del file (o c’è
un errore) viene restituito un NULL, ed il buffer buf non viene toccato. L’uso di gets è deprecato
e deve essere assolutamente evitato; la funzione infatti non controlla il numero di byte letti,
per cui nel caso la stringa letta superi le dimensioni del buffer, si avrà un buffer overflow, con
sovrascrittura della memoria del processo adiacente al buffer.6
Questa è una delle vulnerabilità più sfruttate per guadagnare accessi non autorizzati al
sistema (i cosiddetti exploit), basta infatti inviare una stringa sufficientemente lunga ed oppor-
tunamente forgiata per sovrascrivere gli indirizzi di ritorno nello stack (supposto che la gets sia
stata chiamata da una subroutine), in modo da far ripartire l’esecuzione nel codice inviato nella
stringa stessa (in genere uno shell code cioè una sezione di programma che lancia una shell).
6
questa tecnica è spiegata in dettaglio e con molta efficacia nell’ormai famoso articolo di Aleph1 [8].

La funzione fgets non ha i precedenti problemi di gets in quanto prende in input la di-
mensione del buffer size, che non verrà mai ecceduta in lettura. La funzione legge fino ad un
massimo di size caratteri (newline compreso), ed aggiunge uno zero di terminazione; questo
comporta che la stringa possa essere al massimo di size-1 caratteri. Se la linea eccede la di-
mensione del buffer verranno letti solo size-1 caratteri, ma la stringa sarà sempre terminata
correttamente con uno zero finale; sarà possibile leggere i rimanenti caratteri in una chiamata
successiva.
Per la scrittura di una linea lo standard ANSI C prevede altre due funzioni, fputs e puts,
analoghe a quelle di lettura, i rispettivi prototipi sono:
#include <stdio.h>
int puts(const char *string)
Scrive su stdout la linea string.
int fputs(const char *string, FILE *stream)
Scrive su stream la linea string.
Le funzioni restituiscono un valore non negativo in caso di successo o EOF in caso di errore.
Dato che in questo caso si scrivono i dati in uscita puts non ha i problemi di gets ed è in
genere la forma più immediata per scrivere messaggi sullo standard output; la funzione prende
una stringa terminata da uno zero ed aggiunge automaticamente il ritorno a capo. La differenza
con fputs (a parte la possibilità di specificare un file diverso da stdout) è che quest’ultima non
aggiunge il newline, che deve essere previsto esplicitamente.
Come per le analoghe funzioni di input/output a caratteri, anche per l’I/O di linea esistono
delle estensioni per leggere e scrivere linee di caratteri estesi, le funzioni in questione sono fgetws
e fputws ed i loro prototipi sono:
#include <wchar.h>
wchar_t *fgetws(wchar_t *ws, int n, FILE *stream)
Legge un massimo di n caratteri estesi dal file stream al buffer ws.
int fputws(const wchar_t *ws, FILE *stream)
Scrive la linea ws di caratteri estesi sul file stream.
Le funzioni ritornano rispettivamente ws o un numero non negativo in caso di successo e NULL o
EOF in caso di errore o fine del file.
Il comportamento di queste due funzioni è identico a quello di fgets e fputs, a parte il fatto
che tutto (numero di caratteri massimo, terminatore della stringa, newline) è espresso in termini
di caratteri estesi anziché di normali caratteri ASCII.
Come per l’I/O binario e quello a caratteri, anche per l’I/O di linea le glibc supportano
una serie di altre funzioni, estensioni di tutte quelle illustrate finora (eccetto gets e puts), che
eseguono esattamente le stesse operazioni delle loro equivalenti, evitando però il lock implicito
dello stream (vedi sez. 7.3.3). Come per le altre forma di I/O, dette funzioni hanno lo stesso
nome della loro analoga normale, con l’aggiunta dell’estensione _unlocked.
Come abbiamo visto, le funzioni di lettura per l’input/output di linea previste dallo standard
ANSI C presentano svariati inconvenienti. Benché fgets non abbia i gravissimi problemi di gets,
può comunque dare risultati ambigui se l’input contiene degli zeri; questi infatti saranno scritti
sul buffer di uscita e la stringa in output apparirà come più corta dei byte effettivamente letti.
Questa è una condizione che è sempre possibile controllare (deve essere presente un newline prima
della effettiva conclusione della stringa presente nel buffer), ma a costo di una complicazione
ulteriore della logica del programma. Lo stesso dicasi quando si deve gestire il caso di stringa
che eccede le dimensioni del buffer.
Per questo motivo le glibc prevedono, come estensione GNU, due nuove funzioni per la
gestione dell’input/output di linea, il cui uso permette di risolvere questi problemi. L’uso di
queste funzioni deve essere attivato definendo la macro _GNU_SOURCE prima di includere stdio.h.

La prima delle due, getline, serve per leggere una linea terminata da un newline, esattamente
allo stesso modo di fgets, il suo prototipo è:
#include <stdio.h>
ssize_t getline(char **buffer, size_t *n, FILE *stream)
Legge una linea dal file stream copiandola sul buffer indicato da buffer riallocandolo se
necessario (l’indirizzo del buffer e la sua dimensione vengono sempre riscritte).
La funzione ritorna il numero di caratteri letti in caso di successo e -1 in caso di errore o di
raggiungimento della fine del file.
La funzione permette di eseguire una lettura senza doversi preoccupare della eventuale lun-
ghezza eccessiva della stringa da leggere. Essa prende come primo argomento l’indirizzo del
puntatore al buffer su cui si vuole copiare la linea. Quest’ultimo deve essere stato allocato in
precedenza con una malloc (non si può passare l’indirizzo di un puntatore ad una variabile loca-
le); come secondo argomento la funzione vuole l’indirizzo della variabile contenente le dimensioni
del buffer suddetto.
Se il buffer di destinazione è sufficientemente ampio la stringa viene scritta subito, altrimenti
il buffer viene allargato usando realloc e la nuova dimensione ed il nuovo puntatore vengono
restituiti indietro (si noti infatti come per entrambi gli argomenti si siano usati dei value result
argument, passando dei puntatori anziché i valori delle variabili, secondo la tecnica spiegata in
sez. 2.4.1).
Se si passa alla funzione l’indirizzo di un puntatore impostato a NULL e *n è zero, la funzione
provvede da sola all’allocazione della memoria necessaria a contenere la linea. In tutti i casi si
ottiene dalla funzione un puntatore all’inizio del testo della linea letta. Un esempio di codice
può essere il seguente:
size_t n = 0;
char *ptr = NULL;
int nread;
FILE * file;
...
nread = getline (&ptr , &n, file );
e per evitare memory leak occorre ricordarsi di liberare ptr con una free.
Il valore di ritorno della funzione indica il numero di caratteri letti dallo stream (quindi
compreso il newline, ma non lo zero di terminazione); questo permette anche di distinguere
eventuali zeri letti dallo stream da quello inserito dalla funzione per terminare la linea. Se si è
alla fine del file e non si è potuto leggere nulla o c’è stato un errore la funzione restituisce -1.
La seconda estensione GNU è una generalizzazione di getline per poter usare come sepa-
ratore un carattere qualsiasi, la funzione si chiama getdelim ed il suo prototipo è:
#include <stdio.h>
ssize_t getdelim(char **buffer, size_t *n, int delim, FILE *stream)
Identica a getline solo che usa delim al posto del carattere di newline come separatore di
linea.
Il comportamento di getdelim è identico a quello di getline (che può essere implementata
da questa passando ’n’ come valore di delim).
7.2.6 L’input/output formattato
L’ultima modalità di input/output è quella formattata, che è una delle caratteristiche più uti-
lizzate delle librerie standard del C; in genere questa è la modalità in cui si esegue normalmente
l’output su terminale poiché permette di stampare in maniera facile e veloce dati, tabelle e
messaggi.

L’output formattato viene eseguito con una delle 13 funzioni della famiglia printf; le tre
più usate sono printf, fprintf e sprintf, i cui prototipi sono:
#include <stdio.h>
int printf(const char *format, ...)
Stampa su stdout gli argomenti, secondo il formato specificato da format.
int fprintf(FILE *stream, const char *format, ...)
Stampa su stream gli argomenti, secondo il formato specificato da format.
int sprintf(char *str, const char *format, ...)
Stampa sulla stringa str gli argomenti, secondo il formato specificato da format.
Le funzioni ritornano il numero di caratteri stampati.
le prime due servono per stampare su file (lo standard output o quello specificato) la terza
permette di stampare su una stringa, in genere l’uso di sprintf è sconsigliato in quanto è
possibile, se non si ha la sicurezza assoluta sulle dimensioni del risultato della stampa, eccedere
le dimensioni di str, con conseguente sovrascrittura di altre variabili e possibili buffer overflow;
per questo motivo si consiglia l’uso dell’alternativa snprintf, il cui prototipo è:
#include <stdio.h>
snprintf(char *str, size_t size, const char *format, ...)
Identica a sprintf, ma non scrive su str più di size caratteri.
La parte più complessa delle funzioni di scrittura formattata è il formato della stringa format
che indica le conversioni da fare, e da cui deriva anche il numero degli argomenti che dovranno
essere passati a seguire (si noti come tutte queste funzioni siano variadic, prendendo un numero
di argomenti variabile che dipende appunto da quello che si è specificato in format).
Valore Tipo Significato
%d int Stampa un numero intero in formato decimale con segno.
%i int Identico a %i in output.
%o unsigned int Stampa un numero intero come ottale.
%u unsigned int Stampa un numero intero in formato decimale senza segno.
%x, %X unsigned int Stampano un intero in formato esadecimale, rispettivamente con lettere
minuscole e maiuscole.
%f double Stampa un numero in virgola mobile con la notazione a virgola fissa.
%e, %E double Stampano un numero in virgola mobile con la notazione esponenziale,
rispettivamente con lettere minuscole e maiuscole.
%g, %G double Stampano un numero in virgola mobile con la notazione più appropriate
delle due precedenti, rispettivamente con lettere minuscole e maiuscole.
%a, %A double Stampano un numero in virgola mobile in notazione esadecimale
frazionaria.
%c int Stampa un carattere singolo.
%s char * Stampa una stringa.
%p void * Stampa il valore di un puntatore.
%n &int Prende il numero di caratteri stampati finora.
%% Stampa un %.
Tabella 7.2: Valori possibili per gli specificatori di conversione in una stringa di formato di printf.
La stringa è costituita da caratteri normali (tutti eccetto %), che vengono passati invariati
all’output, e da direttive di conversione, in cui devono essere sempre presenti il carattere %,
che introduce la direttiva, ed uno degli specificatori di conversione (riportati in tab. 7.2) che la
conclude.
Il formato di una direttiva di conversione prevede una serie di possibili elementi opzionali
oltre al % e allo specificatore di conversione. In generale essa è sempre del tipo:
% [n. parametro $] [flag] [[larghezza] [. precisione]] [tipo] conversione

Valore Significato
# Chiede la conversione in forma alternativa.
0 La conversione è riempita con zeri alla sinistra del valore.
- La conversione viene allineata a sinistra sul bordo del campo.
’ ’ Mette uno spazio prima di un numero con segno di valore positivo.
+ Mette sempre il segno (+ o −) prima di un numero.
Tabella 7.3: I valori dei flag per il formato di printf
in cui tutti i valori tranne il % e lo specificatore di conversione sono opzionali (e per questo
sono indicati fra parentesi quadre); si possono usare più elementi opzionali, nel qual caso devono
essere specificati in questo ordine:
• uno specificatore del parametro da usare (terminato da un $),
• uno o più flag (i cui valori possibili sono riassunti in tab. 7.3) che controllano il formato di
stampa della conversione,
• uno specificatore di larghezza (un numero decimale), eventualmente seguito (per i numeri
in virgola mobile) da un specificatore di precisione (un altro numero decimale),
• uno specificatore del tipo di dato, che ne indica la dimensione (i cui valori possibili sono
riassunti in tab. 7.4).
Dettagli ulteriori sulle varie opzioni possono essere trovati nella pagina di manuale di printf
e nella documentazione delle glibc.
Valore Significato
hh Una conversione intera corrisponde a un char con o senza segno, o il
puntatore per il numero dei parametri n è di tipo char.
h Una conversione intera corrisponde a uno short con o senza segno, o il
puntatore per il numero dei parametri n è di tipo short.
l Una conversione intera corrisponde a un long con o senza segno, o il
puntatore per il numero dei parametri n è di tipo long, o il carattere o
la stringa seguenti sono in formato esteso.
ll Una conversione intera corrisponde a un long long con o senza segno,
o il puntatore per il numero dei parametri n è di tipo long long.
L Una conversione in virgola mobile corrisponde a un double.
q Sinonimo di ll.
j Una conversione intera corrisponde a un intmax_t o uintmax_t.
z Una conversione intera corrisponde a un size_t o ssize_t.
t Una conversione intera corrisponde a un ptrdiff_t.
Tabella 7.4: Il modificatore di tipo di dato per il formato di printf
Una versione alternativa delle funzioni di output formattato, che permettono di usare il
puntatore ad una lista di argomenti (vedi sez. 2.4.2), sono vprintf, vfprintf e vsprintf, i cui
prototipi sono:
#include <stdio.h>
int vprintf(const char *format, va_list ap)
Stampa su stdout gli argomenti della lista ap, secondo il formato specificato da format.
int vfprintf(FILE *stream, const char *format, va_list ap)
Stampa su stream gli argomenti della lista ap, secondo il formato specificato da format.
int vsprintf(char *str, const char *format, va_list ap)
Stampa sulla stringa str gli argomenti della lista ap, secondo il formato specificato da
format.
con queste funzioni diventa possibile selezionare gli argomenti che si vogliono passare ad una
funzione di stampa, passando direttamente la lista tramite l’argomento ap. Per poter far questo

ovviamente la lista degli argomenti dovrà essere opportunamente trattata (l’argomento è esa-
minato in sez. 2.4.2), e dopo l’esecuzione della funzione l’argomento ap non sarà più utilizzabile
(in generale dovrebbe essere eseguito un va_end(ap) ma in Linux questo non è necessario).
Come per sprintf anche per vsprintf esiste una analoga vsnprintf che pone un limite sul
numero di caratteri che vengono scritti sulla stringa di destinazione:
#include <stdio.h>
vsnprintf(char *str, size_t size, const char *format, va_list ap)
Identica a vsprintf, ma non scrive su str più di size caratteri.
in modo da evitare possibili buffer overflow.
Per eliminare alla radice questi problemi, le glibc supportano una specifica estensione GNU
che alloca dinamicamente tutto lo spazio necessario; l’estensione si attiva al solito definendo
_GNU_SOURCE, le due funzioni sono asprintf e vasprintf, ed i rispettivi prototipi sono:
#include <stdio.h>
int asprintf(char **strptr, const char *format, ...)
Stampa gli argomenti specificati secondo il formato specificato da format su una stringa
allocata automaticamente all’indirizzo *strptr.
int vasprintf(char **strptr, const char *format, va_list ap)
Stampa gli argomenti della lista ap secondo il formato specificato da format su una stringa
allocata automaticamente all’indirizzo *strptr.
Entrambe le funzioni prendono come argomento strptr che deve essere l’indirizzo di un
puntatore ad una stringa di caratteri, in cui verrà restituito (si ricordi quanto detto in sez. 2.4.1
a proposito dei value result argument) l’indirizzo della stringa allocata automaticamente dalle
funzioni. Occorre inoltre ricordarsi di invocare free per liberare detto puntatore quando la
stringa non serve più, onde evitare memory leak.
Infine una ulteriore estensione GNU definisce le due funzioni dprintf e vdprintf, che pren-
dono un file descriptor al posto dello stream. Altre estensioni permettono di scrivere con caratteri
estesi. Anche queste funzioni, il cui nome è generato dalle precedenti funzioni aggiungendo una
w davanti a print, sono trattate in dettaglio nella documentazione delle glibc.
In corrispondenza alla famiglia di funzioni printf che si usano per l’output formattato,
l’input formattato viene eseguito con le funzioni della famiglia scanf; fra queste le tre più
importanti sono scanf, fscanf e sscanf, i cui prototipi sono:
#include <stdio.h>
int scanf(const char *format, ...)
Esegue una scansione di stdin cercando una corrispondenza di quanto letto con il formato
dei dati specificato da format, ed effettua le relative conversione memorizzando il risultato
negli argomenti seguenti.
int fscanf(FILE *stream, const char *format, ...)
Analoga alla precedente, ma effettua la scansione su stream.
int sscanf(char *str, const char *format, ...)
Analoga alle precedenti, ma effettua la scansione dalla stringa str.
Le funzioni ritornano il numero di elementi assegnati. Questi possono essere in numero inferiore a
quelli specificati, ed anche zero. Quest’ultimo valore significa che non si è trovata corrispondenza.
In caso di errore o fine del file viene invece restituito EOF.
e come per le analoghe funzioni di scrittura esistono le relative vscanf, vfscanf vsscanf che
usano un puntatore ad una lista di argomenti.
Tutte le funzioni della famiglia delle scanf vogliono come argomenti i puntatori alle variabili
che dovranno contenere le conversioni; questo è un primo elemento di disagio in quanto è molto
facile dimenticarsi di questa caratteristica.
Le funzioni leggono i caratteri dallo stream (o dalla stringa) di input ed eseguono un confronto
con quanto indicato in format, la sintassi di questo argomento è simile a quella usata per

l’analogo di printf, ma ci sono varie differenze. Le funzioni di input infatti sono più orientate
verso la lettura di testo libero che verso un input formattato in campi fissi. Uno spazio in
format corrisponde con un numero qualunque di caratteri di separazione (che possono essere
spazi, tabulatori, virgole ecc.), mentre caratteri diversi richiedono una corrispondenza esatta. Le
direttive di conversione sono analoghe a quelle di printf e si trovano descritte in dettaglio nelle
pagine di manuale e nel manuale delle glibc.
Le funzioni eseguono la lettura dall’input, scartano i separatori (e gli eventuali caratteri
diversi indicati dalla stringa di formato) effettuando le conversioni richieste; in caso la corri-
spondenza fallisca (o la funzione non sia in grado di effettuare una delle conversioni richieste) la
scansione viene interrotta immediatamente e la funzione ritorna lasciando posizionato lo stream
al primo carattere che non corrisponde.
Data la notevole complessità di uso di queste funzioni, che richiedono molta cura nella defini-
zione delle corrette stringhe di formato e sono facilmente soggette ad errori, e considerato anche
il fatto che è estremamente macchinoso recuperare in caso di fallimento nelle corrispondenze,
l’input formattato non è molto usato. In genere infatti quando si ha a che fare con un input
relativamente semplice si preferisce usare l’input di linea ed effettuare scansione e conversione
di quanto serve direttamente con una delle funzioni di conversione delle stringhe; se invece il
formato è più complesso diventa più facile utilizzare uno strumento come flex7 per generare un
analizzatore lessicale o il bison8 per generare un parser.
7.2.7 Posizionamento su uno stream
Come per i file descriptor anche per gli stream è possibile spostarsi all’interno di un file per
effettuare operazioni di lettura o scrittura in un punto prestabilito; sempre che l’operazione di
riposizionamento sia supportata dal file sottostante lo stream, quando cioè si ha a che fare con
quello che viene detto un file ad accesso casuale.9
In GNU/Linux ed in generale in ogni sistema unix-like la posizione nel file è espressa da un
intero positivo, rappresentato dal tipo off_t, il problema è che alcune delle funzioni usate per il
riposizionamento sugli stream originano dalle prime versioni di Unix, in cui questo tipo non era
ancora stato definito, e che in altri sistemi non è detto che la posizione su un file venga sempre
rappresentata con il numero di caratteri dall’inizio (ad esempio in VMS può essere rappresentata
come numero di record, più l’offset rispetto al record corrente).
Tutto questo comporta la presenza di diverse funzioni che eseguono sostanzialmente le
stesse operazioni, ma usano argomenti di tipo diverso. Le funzioni tradizionali usate per il
riposizionamento della posizione in uno stream sono fseek e rewind i cui prototipi sono:
#include <stdio.h>
int fseek(FILE *stream, long offset, int whence)
Sposta la posizione nello stream secondo quanto specificato tramite offset e whence.
void rewind(FILE *stream)
Riporta la posizione nello stream all’inizio del file.
L’uso di fseek è del tutto analogo a quello di lseek per i file descriptor, e gli argomenti, a
parte il tipo, hanno lo stesso significato; in particolare whence assume gli stessi valori già visti
in sez. 6.2.3. La funzione restituisce 0 in caso di successo e -1 in caso di errore. La funzione
rewind riporta semplicemente la posizione corrente all’inizio dello stream, ma non esattamente
7
il programma flex, è una implementazione libera di lex un generatore di analizzatori lessicali. Per i dettagli
si può fare riferimento al manuale [9].
8
il programma bison è un clone del generatore di parser yacc, maggiori dettagli possono essere trovati nel
relativo manuale [10].
9
dato che in un sistema Unix esistono vari tipi di file, come le fifo ed i file di dispositivo, non è scontato che
questo sia sempre vero.

7.3. FUNZIONI AVANZATE 219
equivalente ad una fseek(stream, 0L, SEEK_SET) in quanto vengono cancellati anche i flag di
errore e fine del file.
Per ottenere la posizione corrente si usa invece la funzione ftell, il cui prototipo è:
#include <stdio.h>
long ftell(FILE *stream)
Legge la posizione attuale nello stream stream.
La funzione restituisce la posizione corrente, o -1 in caso di fallimento, che può esser dovuto sia
al fatto che il file non supporta il riposizionamento che al fatto che la posizione non può essere
espressa con un long int
la funzione restituisce la posizione come numero di byte dall’inizio dello stream.
Queste funzioni esprimono tutte la posizione nel file come un long int. Dato che (ad esempio
quando si usa un filesystem indicizzato a 64 bit) questo può non essere possibile lo standard
POSIX ha introdotto le nuove funzioni fgetpos e fsetpos, che invece usano il nuovo tipo
fpos_t, ed i cui prototipi sono:
#include <stdio.h>
int fsetpos(FILE *stream, fpos_t *pos)
Imposta la posizione corrente nello stream stream al valore specificato da pos.
int fgetpos(FILE *stream, fpos_t *pos)
Legge la posizione corrente nello stream stream e la scrive in pos.
Le funzioni ritornano 0 in caso di successo e -1 in caso di errore.
In Linux, a partire dalle glibc 2.1, sono presenti anche le due funzioni fseeko e ftello, che
sono assolutamente identiche alle precedenti fseek e ftell ma hanno argomenti di tipo off_t
anziché di tipo long int. Dato che long è nella gran parte dei casi un intero a 32 bit, questo
diventa un problema quando la posizione sul file viene espressa con un valore a 64 bit come
accade nei sistemi più moderni.
7.3 Funzioni avanzate
In questa sezione esamineremo alcune funzioni avanzate che permettono di eseguire operazioni
particolari sugli stream, come leggerne gli attributi, controllarne le modalità di bufferizzazione,
gestire direttamente i lock impliciti per la programmazione multi-thread.
7.3.1 Le funzioni di controllo
Al contrario di quanto avviene con i file descriptor, le librerie standard del C non prevedono
nessuna funzione come la fcntl per il controllo degli attributi dei file. Però, dato che ogni stream
si appoggia ad un file descriptor, si può usare la funzione fileno per ottenere quest’ultimo, il
prototipo della funzione è:
#include <stdio.h>
int fileno(FILE *stream)
Legge il file descriptor sottostante lo stream stream.
Restituisce il numero del file descriptor in caso di successo, e -1 qualora stream non sia valido, nel
qual caso imposta errno a EBADF.
ed in questo modo diventa possibile usare direttamente fcntl.
Questo permette di accedere agli attributi del file descriptor sottostante lo stream, ma non ci
dà nessuna informazione riguardo alle proprietà dello stream medesimo. Le glibc però supportano
alcune estensioni derivate da Solaris, che permettono di ottenere informazioni utili.
Ad esempio in certi casi può essere necessario sapere se un certo stream è accessibile in lettura
o scrittura. In genere questa informazione non è disponibile, e si deve ricordare come il file è stato

aperto. La cosa può essere complessa se le operazioni vengono effettuate in una subroutine, che
a questo punto necessiterà di informazioni aggiuntive rispetto al semplice puntatore allo stream;
questo può essere evitato con le due funzioni __freadable e __fwritable i cui prototipi sono:
#include <stdio_ext.h>
int __freadable(FILE *stream)
Restituisce un valore diverso da zero se stream consente la lettura.
int __fwritable(FILE *stream)
Restituisce un valore diverso da zero se stream consente la scrittura.
che permettono di ottenere questa informazione.
La conoscenza dell’ultima operazione effettuata su uno stream aperto è utile in quanto
permette di trarre conclusioni sullo stato del buffer e del suo contenuto. Altre due funzioni,
__freading e __fwriting servono a tale scopo, il loro prototipo è:
int __freading(FILE *stream)
Restituisce un valore diverso da zero se stream è aperto in sola lettura o se l’ultima
operazione è stata di lettura.
int __fwriting(FILE *stream)
Restituisce un valore diverso da zero se stream è aperto in sola scrittura o se l’ultima
operazione è stata di scrittura.
Le due funzioni permettono di determinare di che tipo è stata l’ultima operazione eseguita
su uno stream aperto in lettura/scrittura; ovviamente se uno stream è aperto in sola lettura
(o sola scrittura) la modalità dell’ultima operazione è sempre determinata; l’unica ambiguità è
quando non sono state ancora eseguite operazioni, in questo caso le funzioni rispondono come
se una operazione ci fosse comunque stata.
7.3.2 Il controllo della bufferizzazione
Come accennato in sez. 7.1.4 le librerie definiscono una serie di funzioni che permettono di
controllare il comportamento degli stream; se non si è specificato nulla, la modalità di buffering
viene decisa autonomamente sulla base del tipo di file sottostante, ed i buffer vengono allocati
automaticamente.
Però una volta che si sia aperto lo stream (ma prima di aver compiuto operazioni su di
esso) è possibile intervenire sulle modalità di buffering; la funzione che permette di controllare
la bufferizzazione è setvbuf, il suo prototipo è:
#include <stdio.h>
int setvbuf(FILE *stream, char *buf, int mode, size_t size)
Imposta la bufferizzazione dello stream stream nella modalità indicata da mode, usando buf
come buffer di lunghezza size.
Restituisce zero in caso di successo, ed un valore qualunque in caso di errore, nel qual caso errno
viene impostata opportunamente.
La funzione permette di controllare tutti gli aspetti della bufferizzazione; l’utente può specifi-
care un buffer da usare al posto di quello allocato dal sistema passandone alla funzione l’indirizzo
in buf e la dimensione in size.
Ovviamente se si usa un buffer specificato dall’utente questo deve essere stato allocato e
rimanere disponibile per tutto il tempo in cui si opera sullo stream. In genere conviene allocarlo
con malloc e disallocarlo dopo la chiusura del file; ma fintanto che il file è usato all’interno di
una funzione, può anche essere usata una variabile automatica. In stdio.h è definita la macro
BUFSIZ, che indica le dimensioni generiche del buffer di uno stream; queste vengono usate dalla
funzione setbuf. Non è detto però che tale dimensione corrisponda sempre al valore ottimale
(che può variare a seconda del dispositivo).

Dato che la procedura di allocazione manuale è macchinosa, comporta dei rischi (come delle
scritture accidentali sul buffer) e non assicura la scelta delle dimensioni ottimali, è sempre meglio
lasciare allocare il buffer alle funzioni di libreria, che sono in grado di farlo in maniera ottimale
e trasparente all’utente (in quanto la deallocazione avviene automaticamente). Inoltre siccome
alcune implementazioni usano parte del buffer per mantenere delle informazioni di controllo, non
è detto che le dimensioni dello stesso coincidano con quelle su cui viene effettuato l’I/O.
Valore Modalità
_IONBF unbuffered
_IOLBF line buffered
_IOFBF fully buffered
Tabella 7.5: Valori dell’argomento mode di setvbuf per l’impostazione delle modalità di bufferizzazione.
Per evitare che setvbuf imposti il buffer basta passare un valore NULL per buf e la funzione
ignorerà l’argomento size usando il buffer allocato automaticamente dal sistema. Si potrà co-
munque modificare la modalità di bufferizzazione, passando in mode uno degli opportuni valori
elencati in tab. 7.5. Qualora si specifichi la modalità non bufferizzata i valori di buf e size
vengono sempre ignorati.
Oltre a setvbuf le glibc definiscono altre tre funzioni per la gestione della bufferizzazione di
uno stream: setbuf, setbuffer e setlinebuf; i loro prototipi sono:
#include <stdio.h>
void setbuf(FILE *stream, char *buf)
Disabilita la bufferizzazione se buf è NULL, altrimenti usa buf come buffer di dimensione
BUFSIZ in modalità fully buffered.
void setbuffer(FILE *stream, char *buf, size_t size)
Disabilita la bufferizzazione se buf è NULL, altrimenti usa buf come buffer di dimensione
size in modalità fully buffered.
void setlinebuf(FILE *stream)
Pone lo stream in modalità line buffered.
tutte queste funzioni sono realizzate con opportune chiamate a setvbuf e sono definite solo per
compatibilità con le vecchie librerie BSD. Infine le glibc provvedono le funzioni non standard10
__flbf e __fbufsize che permettono di leggere le proprietà di bufferizzazione di uno stream; i
cui prototipi sono:
int __flbf(FILE *stream)
Restituisce un valore diverso da zero se stream è in modalità line buffered.
size_t __fbufsize(FILE *stream)
Restituisce le dimensioni del buffer di stream.
Come già accennato, indipendentemente dalla modalità di bufferizzazione scelta, si può
forzare lo scarico dei dati sul file con la funzione fflush, il suo prototipo è:
#include <stdio.h>
int fflush(FILE *stream)
Forza la scrittura di tutti i dati bufferizzati dello stream stream.
Restituisce zero in caso di successo, ed EOF in caso di errore, impostando errno a EBADF se stream
non è aperto o non è aperto in scrittura, o ad uno degli errori di write.
anche di questa funzione esiste una analoga fflush_unlocked11 che non effettua il blocco dello
stream.
Se stream è NULL lo scarico dei dati è forzato per tutti gli stream aperti. Esistono però
circostanze, ad esempio quando si vuole essere sicuri che sia stato eseguito tutto l’output su
10
anche queste funzioni sono originarie di Solaris.
11
accessibile definendo _BSD_SOURCE o _SVID_SOURCE o _GNU_SOURCE.

terminale, in cui serve poter effettuare lo scarico dei dati solo per gli stream in modalità line
buffered; per questo motivo le glibc supportano una estensione di Solaris, la funzione _flushlbf,
#include <stdio-ext.h>
void _flushlbf(void)
Forza la scrittura di tutti i dati bufferizzati degli stream in modalità line buffered.
Si ricordi comunque che lo scarico dei dati dai buffer effettuato da queste funzioni non
comporta la scrittura di questi su disco; se si vuole che il kernel dia effettivamente avvio alle
operazioni di scrittura su disco occorre usare sync o fsync (si veda sez. 6.3.3).
Infine esistono anche circostanze in cui si vuole scartare tutto l’output pendente; per questo
si può usare fpurge, il cui prototipo è:
#include <stdio.h>
int fpurge(FILE *stream)
Cancella i buffer di input e di output dello stream stream.
Restituisce zero in caso di successo, ed EOF in caso di errore.
La funzione scarta tutti i dati non ancora scritti (se il file è aperto in scrittura), e tutto l’input
non ancora letto (se è aperto in lettura), compresi gli eventuali caratteri rimandati indietro con
ungetc.
7.3.3 Gli stream e i thread
Gli stream possono essere usati in applicazioni multi-thread allo stesso modo in cui sono usati
nelle applicazioni normali, ma si deve essere consapevoli delle possibili complicazioni anche
quando non si usano i thread, dato che l’implementazione delle librerie è influenzata pesantemente
dalle richieste necessarie per garantirne l’uso con i thread.
Lo standard POSIX richiede che le operazioni sui file siano atomiche rispetto ai thread, per
questo le operazioni sui buffer effettuate dalle funzioni di libreria durante la lettura e la scrittura
di uno stream devono essere opportunamente protette (in quanto il sistema assicura l’atomicità
solo per le system call). Questo viene fatto associando ad ogni stream un opportuno blocco che
deve essere implicitamente acquisito prima dell’esecuzione di qualunque operazione.
Ci sono comunque situazioni in cui questo non basta, come quando un thread necessita di com-
piere più di una operazione sullo stream atomicamente, per questo motivo le librerie provvedono
anche delle funzioni flockfile, ftrylockfile e funlockfile, che permettono la gestione espli-
cita dei blocchi sugli stream; esse sono disponibili definendo _POSIX_THREAD_SAFE_FUNCTIONS
ed i loro prototipi sono:
#include <stdio.h>
void flockfile(FILE *stream)
Esegue l’acquisizione del lock dello stream stream, bloccandosi se il lock non è disponibile.
int ftrylockfile(FILE *stream)
Tenta l’acquisizione del lock dello stream stream, senza bloccarsi se il lock non è disponibile.
Ritorna zero in caso di acquisizione del lock, diverso da zero altrimenti.
void funlockfile(FILE *stream)
Rilascia il lock dello stream stream.
con queste funzioni diventa possibile acquisire un blocco ed eseguire tutte le operazioni volute,
per poi rilasciarlo.
Ma, vista la complessità delle strutture di dati coinvolte, le operazioni di blocco non sono
del tutto indolori, e quando il locking dello stream non è necessario (come in tutti i programmi
che non usano i thread), tutta la procedura può comportare dei costi pesanti in termini di
prestazioni. Per questo motivo abbiamo visto come alle usuali funzioni di I/O non formattato
siano associate delle versioni _unlocked (alcune previste dallo stesso standard POSIX, altre

aggiunte come estensioni dalle glibc) che possono essere usate quando il locking non serve12 con
prestazioni molto più elevate, dato che spesso queste versioni (come accade per getc e putc)
sono realizzate come macro.
La sostituzione di tutte le funzioni di I/O con le relative versioni _unlocked in un programma
che non usa i thread è però un lavoro abbastanza noioso; per questo motivo le glibc forniscono al
programmatore pigro un’altra via13 da poter utilizzare per disabilitare in blocco il locking degli
stream: l’uso della funzione __fsetlocking, il cui prototipo è:
int __fsetlocking (FILE *stream, int type)
Specifica o richiede a seconda del valore di type la modalità in cui le operazioni di I/O su
stream vengono effettuate rispetto all’acquisizione implicita del blocco sullo stream.
Restituisce lo stato di locking interno dello stream con uno dei valori FSETLOCKING_INTERNAL o
FSETLOCKING_BYCALLER.
La funzione imposta o legge lo stato della modalità di operazione di uno stream nei confronti
del locking a seconda del valore specificato con type, che può essere uno dei seguenti:
FSETLOCKING_INTERNAL Lo stream userà da ora in poi il blocco implicito predefinito.
FSETLOCKING_BYCALLER Al ritorno della funzione sarà l’utente a dover gestire da solo il locking
dello stream.
FSETLOCKING_QUERY Restituisce lo stato corrente della modalità di blocco dello stream.
12
in certi casi dette funzioni possono essere usate, visto che sono molto più efficienti, anche in caso di necessità
di locking, una volta che questo sia stato acquisito manualmente.
13
anche questa mutuata da estensioni introdotte in Solaris.

Capitolo 8
La gestione del sistema, del tempo e
degli errori
In questo capitolo tratteremo varie interfacce che attengono agli aspetti più generali del sistema,
come quelle per la gestione dei parametri e della configurazione dello stesso, quelle per la lettura
dei limiti e delle caratteristiche, quelle per il controllo dell’uso delle risorse dei processi, quelle
per la gestione ed il controllo dei filesystem, degli utenti, dei tempi e degli errori.
8.1 Capacità e caratteristiche del sistema
In questa sezione tratteremo le varie modalità con cui un programma può ottenere informa-
zioni riguardo alle capacità del sistema. Ogni sistema unix-like infatti è contraddistinto da un
gran numero di limiti e costanti che lo caratterizzano, e che possono dipendere da fattori mol-
teplici, come l’architettura hardware, l’implementazione del kernel e delle librerie, le opzioni di
configurazione.
La definizione di queste caratteristiche ed il tentativo di provvedere dei meccanismi generali
che i programmi possono usare per ricavarle è uno degli aspetti più complessi e controversi con
cui le diverse standardizzazioni si sono dovute confrontare, spesso con risultati spesso tutt’altro
che chiari. Daremo comunque una descrizione dei principali metodi previsti dai vari standard
per ricavare sia le caratteristiche specifiche del sistema, che quelle della gestione dei file.
8.1.1 Limiti e parametri di sistema
Quando si devono determinare le caratteristiche generali del sistema ci si trova di fronte a diverse
possibilità; alcune di queste infatti possono dipendere dall’architettura dell’hardware (come le
dimensioni dei tipi interi), o dal sistema operativo (come la presenza o meno del gruppo degli
identificatori saved), altre invece possono dipendere dalle opzioni con cui si è costruito il sistema
(ad esempio da come si è compilato il kernel), o dalla configurazione del medesimo; per questo
motivo in generale sono necessari due tipi diversi di funzionalità:
• la possibilità di determinare limiti ed opzioni al momento della compilazione.
• la possibilità di determinare limiti ed opzioni durante l’esecuzione.
La prima funzionalità si può ottenere includendo gli opportuni header file che contengono le
costanti necessarie definite come macro di preprocessore, per la seconda invece sono ovviamente
necessarie delle funzioni. La situazione è complicata dal fatto che ci sono molti casi in cui alcuni
di questi limiti sono fissi in un’implementazione mentre possono variare in un altra. Tutto questo
crea una ambiguità che non è sempre possibile risolvere in maniera chiara; in generale quello
che succede è che quando i limiti del sistema sono fissi essi vengono definiti come macro di
225

226 CAPITOLO 8. LA GESTIONE DEL SISTEMA, DEL TEMPO E DEGLI ERRORI
preprocessore nel file limits.h, se invece possono variare, il loro valore sarà ottenibile tramite
la funzione sysconf (che esamineremo in sez. 8.1.2).
Lo standard ANSI C definisce dei limiti che sono tutti fissi, pertanto questo saranno sempre
disponibili al momento della compilazione. Un elenco, ripreso da limits.h, è riportato in tab. 8.1.
Come si può vedere per la maggior parte questi limiti attengono alle dimensioni dei dati interi,
che sono in genere fissati dall’architettura hardware (le analoghe informazioni per i dati in
virgola mobile sono definite a parte, ed accessibili includendo float.h). Lo standard prevede
anche un’altra costante, FOPEN_MAX, che può non essere fissa e che pertanto non è definita in
limits.h; essa deve essere definita in stdio.h ed avere un valore minimo di 8.
Costante Valore Significato
MB_LEN_MAX 16 Massima dimensione di un carattere esteso.
CHAR_BIT 8 Numero di bit di char.
UCHAR_MAX 255 Massimo di unsigned char.
SCHAR_MIN -128 Minimo di signed char.
SCHAR_MAX 127 Massimo di signed char.
CHAR_MIN 1
Minimo di char.
CHAR_MAX 2
Massimo di char.
SHRT_MIN -32768 Minimo di short.
SHRT_MAX 32767 Massimo di short.
USHRT_MAX 65535 Massimo di unsigned short.
INT_MAX 2147483647 Minimo di int.
INT_MIN -2147483648 Minimo di int.
UINT_MAX 4294967295 Massimo di unsigned int.
LONG_MAX 2147483647 Massimo di long.
LONG_MIN -2147483648 Minimo di long.
ULONG_MAX 4294967295 Massimo di unsigned long.
Tabella 8.1: Costanti definite in limits.h in conformità allo standard ANSI C.
A questi valori lo standard ISO C90 ne aggiunge altri tre, relativi al tipo long long intro-
dotto con il nuovo standard, i relativi valori sono in tab. 8.2.
LLONG_MAX 9223372036854775807 Massimo di long long.
LLONG_MIN -9223372036854775808 Minimo di long long.
ULLONG_MAX 18446744073709551615 Massimo di unsigned long long.
Tabella 8.2: Macro definite in limits.h in conformità allo standard ISO C90.
Ovviamente le dimensioni dei vari tipi di dati sono solo una piccola parte delle caratteristiche
del sistema; mancano completamente tutte quelle che dipendono dalla implementazione dello
stesso. Queste, per i sistemi unix-like, sono state definite in gran parte dallo standard POSIX.1,
che tratta anche i limiti relativi alle caratteristiche dei file che vedremo in sez. 8.1.3.
Purtroppo la sezione dello standard che tratta questi argomenti è una delle meno chiare3.
Lo standard prevede che ci siano 13 macro che descrivono le caratteristiche del sistema (7 per
le caratteristiche generiche, riportate in tab. 8.3, e 6 per le caratteristiche dei file, riportate in
tab. 8.7).
Lo standard dice che queste macro devono essere definite in limits.h quando i valori a cui
fanno riferimento sono fissi, e altrimenti devono essere lasciate indefinite, ed i loro valori dei
limiti devono essere accessibili solo attraverso sysconf. In realtà queste vengono sempre definite
ad un valore generico. Si tenga presente poi che alcuni di questi limiti possono assumere valori
1
il valore può essere 0 o SCHAR_MIN a seconda che il sistema usi caratteri con segno o meno.
2
il valore può essere UCHAR_MAX o SCHAR_MAX a seconda che il sistema usi caratteri con segno o meno.
3
tanto che Stevens, in [1], la porta come esempio di “standardese”.

8.1. CAPACITÀ E CARATTERISTICHE DEL SISTEMA 227
ARG_MAX 131072 Dimensione massima degli argomenti passati ad
una funzione della famiglia exec.
CHILD_MAX 999 Numero massimo di processi contemporanei che
un utente può eseguire.
OPEN_MAX 256 Numero massimo di file che un processo può
mantenere aperti in contemporanea.
STREAM_MAX 8 Massimo numero di stream aperti per processo in
contemporanea.
TZNAME_MAX 6 Dimensione massima del nome di una timezone
(vedi sez. 8.4.3)).
NGROUPS_MAX 32 Numero di gruppi supplementari per processo
(vedi sez. 3.3.1).
SSIZE_MAX 32767 Valore massimo del tipo ssize_t.
Tabella 8.3: Costanti per i limiti del sistema.
molto elevati (come CHILD_MAX), e non è pertanto il caso di utilizzarli per allocare staticamente
della memoria.
A complicare la faccenda si aggiunge il fatto che POSIX.1 prevede una serie di altre costanti
(il cui nome inizia sempre con _POSIX_) che definiscono i valori minimi le stesse caratteristiche
devono avere, perché una implementazione possa dichiararsi conforme allo standard; detti valori
sono riportati in tab. 8.4.
_POSIX_ARG_MAX 4096 Dimensione massima degli argomenti passati ad
una funzione della famiglia exec.
_POSIX_CHILD_MAX 6 Numero massimo di processi contemporanei che
un utente può eseguire.
_POSIX_OPEN_MAX 16 Numero massimo di file che un processo può
mantenere aperti in contemporanea.
_POSIX_STREAM_MAX 8 Massimo numero di stream aperti per processo in
contemporanea.
_POSIX_TZNAME_MAX Dimensione massima del nome di una timezone
(vedi sez. 8.4.4).
_POSIX_NGROUPS_MAX 0 Numero di gruppi supplementari per processo
(vedi sez. 3.3.1).
_POSIX_SSIZE_MAX 32767 Valore massimo del tipo ssize_t.
_POSIX_AIO_LISTIO_MAX 2
_POSIX_AIO_MAX 1
Tabella 8.4: Macro dei valori minimi delle caratteristiche generali del sistema per la conformità allo standard
POSIX.1.
In genere questi valori non servono a molto, la loro unica utilità è quella di indicare un limite
superiore che assicura la portabilità senza necessità di ulteriori controlli. Tuttavia molti di essi
sono ampiamente superati in tutti i sistemi POSIX in uso oggigiorno. Per questo è sempre meglio
utilizzare i valori ottenuti da sysconf.
Macro Significato
_POSIX_JOB_CONTROL Il sistema supporta il job control (vedi sez. 10.1).
_POSIX_SAVED_IDS Il sistema supporta gli identificatori del gruppo saved
(vedi sez. 3.3.1) per il controllo di accesso dei processi
_POSIX_VERSION Fornisce la versione dello standard POSIX.1 supportata
nel formato YYYYMML (ad esempio 199009L).
Tabella 8.5: Alcune macro definite in limits.h in conformità allo standard POSIX.1.

Oltre ai precedenti valori (e a quelli relativi ai file elencati in tab. 8.8), che devono essere
obbligatoriamente definiti, lo standard POSIX.1 ne prevede parecchi altri. La lista completa si
trova dall’header file bits/posix1_lim.h (da non usare mai direttamente, è incluso automatica-
mente all’interno di limits.h). Di questi vale la pena menzionare alcune macro di uso comune,
(riportate in tab. 8.5), che non indicano un valore specifico, ma denotano la presenza di alcune
funzionalità nel sistema (come il supporto del job control o degli identificatori del gruppo saved).
Oltre allo standard POSIX.1, anche lo standard POSIX.2 definisce una serie di altre costanti.
Siccome queste sono principalmente attinenti a limiti relativi alle applicazioni di sistema presenti
(come quelli su alcuni parametri delle espressioni regolari o del comando bc), non li tratteremo
esplicitamente, se ne trova una menzione completa nell’header file bits/posix2_lim.h, e alcuni
di loro sono descritti nella pagina di manuale di sysconf e nel manuale delle glibc.
8.1.2 La funzione sysconf
Come accennato in sez. 8.1.1 quando uno dei limiti o delle caratteristiche del sistema può variare,
per non dover essere costretti a ricompilare un programma tutte le volte che si cambiano le
opzioni con cui è compilato il kernel, o alcuni dei parametri modificabili a run time, è necessario
ottenerne il valore attraverso la funzione sysconf. Il prototipo di questa funzione è:
#include <unistd.h>
long sysconf(int name)
Restituisce il valore del parametro di sistema name.
La funzione restituisce indietro il valore del parametro richiesto, o 1 se si tratta di un’opzione
disponibile, 0 se l’opzione non è disponibile e -1 in caso di errore (ma errno non viene impostata).
La funzione prende come argomento un intero che specifica quale dei limiti si vuole conoscere;
uno specchietto contenente i principali valori disponibili in Linux è riportato in tab. 8.6; l’elenco
completo è contenuto in bits/confname.h, ed una lista più esaustiva, con le relative spiegazioni,
si può trovare nel manuale delle glibc.
Parametro Macro sostituita Significato
_SC_ARG_MAX ARG_MAX La dimensione massima degli argomenti passati ad una funzione
della famiglia exec.
_SC_CHILD_MAX _CHILD_MAX Il numero massimo di processi contemporanei che un utente può
eseguire.
_SC_OPEN_MAX _OPEN_MAX Il numero massimo di file che un processo può mantenere aperti
in contemporanea.
_SC_STREAM_MAX STREAM_MAX Il massimo numero di stream che un processo può mantene-
re aperti in contemporanea. Questo limite previsto anche dallo
standard ANSI C, che specifica la macro FOPEN MAX.
_SC_TZNAME_MAX TZNAME_MAX La dimensione massima di un nome di una timezone (vedi
sez. 8.4.4).
_SC_NGROUPS_MAX NGROUP_MAX Massimo numero di gruppi supplementari che può avere un
processo (vedi sez. 3.3.1).
_SC_SSIZE_MAX SSIZE_MAX Valore massimo del tipo di dato ssize_t.
_SC_CLK_TCK CLK_TCK Il numero di clock tick al secondo, cioè l’unità di misura del
process time (vedi sez. 8.4.1).
_SC_JOB_CONTROL _POSIX_JOB_CONTROL Indica se è supportato il job control (vedi sez. 10.1) in stile
POSIX.
_SC_SAVED_IDS _POSIX_SAVED_IDS Indica se il sistema supporta i saved id (vedi sez. 3.3.1).
_SC_VERSION _POSIX_VERSION Indica il mese e l’anno di approvazione della revisione dello
standard POSIX.1 a cui il sistema fa riferimento, nel formato
YYYYMML, la revisione più recente è 199009L, che indica il
Settembre 1990.
Tabella 8.6: Parametri del sistema leggibili dalla funzione sysconf.

8.1. CAPACITÀ E CARATTERISTICHE DEL SISTEMA 229
In generale ogni limite o caratteristica del sistema per cui è definita una macro, sia dagli
standard ANSI C e ISO C90, che da POSIX.1 e POSIX.2, può essere ottenuto attraverso una
chiamata a sysconf. Il valore si otterrà specificando come valore dell’argomento name il nome
ottenuto aggiungendo _SC_ ai nomi delle macro definite dai primi due, o sostituendolo a _POSIX_
per le macro definite dagli gli altri due.
In generale si dovrebbe fare uso di sysconf solo quando la relativa macro non è definita,
quindi con un codice analogo al seguente:
get_child_max(void)
{
#ifdef CHILD_MAX
return CHILD_MAX;
#else
int val = sysconf(_SC_CHILD_MAX );
if (val < 0) {
perror("fatal error");
exit (-1);
}
return val;
#endif
}
ma in realtà in Linux queste macro sono comunque definite, indicando però un limite generico.
Per questo motivo è sempre meglio usare i valori restituiti da sysconf.
8.1.3 I limiti dei file
Come per le caratteristiche generali del sistema anche per i file esistono una serie di limiti (come la
lunghezza del nome del file o il numero massimo di link) che dipendono sia dall’implementazione
che dal filesystem in uso; anche in questo caso lo standard prevede alcune macro che ne specificano
il valore, riportate in tab. 8.7.
LINK_MAX 8 Numero massimo di link a un file.
NAME_MAX 14 Lunghezza in byte di un nome di file.
PATH_MAX 256 Lunghezza in byte di un pathname.
PIPE_BUF 4096 Byte scrivibili atomicamente in una pipe (vedi sez. 11.1.1).
MAX_CANON 255 Dimensione di una riga di terminale in modo canonico (vedi sez. 10.2.1).
MAX_INPUT 255 Spazio disponibile nella coda di input del terminale (vedi sez. 10.2.1).
Tabella 8.7: Costanti per i limiti sulle caratteristiche dei file.
Come per i limiti di sistema, lo standard POSIX.1 detta una serie di valori minimi anche
per queste caratteristiche, che ogni sistema che vuole essere conforme deve rispettare; le relative
macro sono riportate in tab. 8.8, e per esse vale lo stesso discorso fatto per le analoghe di tab. 8.4.
Macro Valore Significato
_POSIX_LINK_MAX 8 Numero massimo di link a un file.
_POSIX_NAME_MAX 14 Lunghezza in byte di un nome di file.
_POSIX_PATH_MAX 256 Lunghezza in byte di un pathname.
_POSIX_PIPE_BUF 512 Byte scrivibili atomicamente in una pipe.
_POSIX_MAX_CANON 255 Dimensione di una riga di terminale in modo canonico.
_POSIX_MAX_INPUT 255 Spazio disponibile nella coda di input del terminale.
Tabella 8.8: Costanti dei valori minimi delle caratteristiche dei file per la conformità allo standard POSIX.1.

Tutti questi limiti sono definiti in limits.h; come nel caso precedente il loro uso è di scarsa
utilità in quanto ampiamente superati in tutte le implementazioni moderne.
8.1.4 La funzione pathconf
In generale i limiti per i file sono molto più soggetti ad essere variabili rispetto ai limiti generali
del sistema; ad esempio parametri come la lunghezza del nome del file o il numero di link
possono variare da filesystem a filesystem; per questo motivo questi limiti devono essere sempre
controllati con la funzione pathconf, il cui prototipo è:
#include <unistd.h>
long pathconf(char *path, int name)
Restituisce il valore del parametro name per il file path.
La funzione restituisce indietro il valore del parametro richiesto, o -1 in caso di errore (ed errno
viene impostata ad uno degli errori possibili relativi all’accesso a path).
E si noti come la funzione in questo caso richieda un argomento che specifichi a quale file si fa
riferimento, dato che il valore del limite cercato può variare a seconda del filesystem. Una seconda
versione della funzione, fpathconf, opera su un file descriptor invece che su un pathname. Il suo
prototipo è:
#include <unistd.h>
long fpathconf(int fd, int name)
Restituisce il valore del parametro name per il file fd.
È identica a pathconf solo che utilizza un file descriptor invece di un pathname; pertanto gli errori
restituiti cambiano di conseguenza.
ed il suo comportamento è identico a quello di pathconf.
8.1.5 La funzione uname
Un’altra funzione che si può utilizzare per raccogliere informazioni sia riguardo al sistema che
al computer su cui esso sta girando è uname; il suo prototipo è:
#include <sys/utsname.h>
int uname(struct utsname *info)
Restituisce informazioni sul sistema nella struttura info.
La funzione ritorna 0 in caso di successo e -1 in caso di fallimento, nel qual caso errno assumerà
il valore EFAULT.
La funzione, che viene usata dal comando uname, restituisce le informazioni richieste nella
struttura info; anche questa struttura è definita in sys/utsname.h, secondo quanto mostrato
in fig. 8.1, e le informazioni memorizzate nei suoi membri indicano rispettivamente:
• il nome del sistema operativo;
• il nome della release del kernel;
• il nome della versione del kernel;
• il tipo di macchina in uso;
• il nome della stazione;
• il nome del domino.
l’ultima informazione è stata aggiunta di recente e non è prevista dallo standard POSIX, essa è
accessibile, come mostrato in fig. 8.1, solo definendo _GNU_SOURCE.
In generale si tenga presente che le dimensioni delle stringhe di una struttura utsname non è
specificata, e che esse sono sempre terminate con NUL; il manuale delle glibc indica due diver-
se dimensioni, _UTSNAME_LENGTH per i campi standard e _UTSNAME_DOMAIN_LENGTH per quello

8.2. OPZIONI E CONFIGURAZIONE DEL SISTEMA 231
struct utsname {
char sysname [];
char nodename [];
char release [];
char version [];
char machine [];
#ifdef _GNU_SOURCE
char domainname [];
#endif
};
Figura 8.1: La struttura utsname.
specifico per il nome di dominio; altri sistemi usano nomi diversi come SYS_NMLN o _SYS_NMLN
o UTSLEN che possono avere valori diversi.4
8.2 Opzioni e configurazione del sistema
Come abbiamo accennato nella sezione precedente, non tutti i limiti che caratterizzano il sistema
sono fissi, o perlomeno non lo sono in tutte le implementazioni. Finora abbiamo visto come si
può fare per leggerli, ci manca di esaminare il meccanismo che permette, quando questi possono
variare durante l’esecuzione del sistema, di modificarli.
Inoltre, al di la di quelli che possono essere limiti caratteristici previsti da uno standard,
ogni sistema può avere una sua serie di altri parametri di configurazione, che, non essendo mai
fissi e variando da sistema a sistema, non sono stati inclusi nella standardizzazione della sezione
precedente. Per questi occorre, oltre al meccanismo di impostazione, pure un meccanismo di
lettura. Affronteremo questi argomenti in questa sezione, insieme alle funzioni che si usano per
il controllo di altre caratteristiche generali del sistema, come quelle per la gestione dei filesystem
e di utenti e gruppi.
8.2.1 La funzione sysctl ed il filesystem /proc
La funzione che permette la lettura ed l’impostazione dei parametri del sistema è sysctl; è una
funzione derivata da BSD4.4, ma l’implementazione è specifica di Linux; il suo prototipo è:
#include <unistd.h>
int sysctl(int *name, int nlen, void *oldval, size_t *oldlenp, void *newval,
size_t newlen)
Legge o scrive uno dei parametri di sistema.
uno dei valori:
EPERM non si ha il permesso di accedere ad uno dei componenti nel cammino specificato per
il parametro, o di accedere al parametro nella modalità scelta.
ENOTDIR non esiste un parametro corrispondente al nome name.
EINVAL o si è specificato un valore non valido per il parametro che si vuole impostare o lo
spazio provvisto per il ritorno di un valore non è delle giuste dimensioni.
ENOMEM talvolta viene usato più correttamente questo errore quando non si è specificato
sufficiente spazio per ricevere il valore di un parametro.
ed inoltre EFAULT.
4
nel caso di Linux uname corrisponde in realtà a 3 system call diverse, le prime due usano rispettivamente
delle lunghezze delle stringhe di 9 e 65 byte; la terza usa anch’essa 65 byte, ma restituisce anche l’ultimo campo,
domainname, con una lunghezza di 257 byte.

I parametri a cui la funzione permettere di accedere sono organizzati in maniera gerarchica
all’interno di un albero;5 per accedere ad uno di essi occorre specificare un cammino attraverso
i vari nodi dell’albero, in maniera analoga a come avviene per la risoluzione di un pathname (da
cui l’uso alternativo del filesystem /proc, che vedremo dopo).
Ciascun nodo dell’albero è identificato da un valore intero, ed il cammino che arriva ad
identificare un parametro specifico è passato alla funzione attraverso l’array name, di lunghezza
nlen, che contiene la sequenza dei vari nodi da attraversare. Ogni parametro ha un valore in
un formato specifico che può essere un intero, una stringa o anche una struttura complessa, per
questo motivo i valori vengono passati come puntatori void.
L’indirizzo a cui il valore corrente del parametro deve essere letto è specificato da oldvalue,
e lo spazio ivi disponibile è specificato da oldlenp (passato come puntatore per avere indietro
la dimensione effettiva di quanto letto); il valore che si vuole impostare nel sistema è passato in
newval e la sua dimensione in newlen.
Si può effettuare anche una lettura e scrittura simultanea, nel qual caso il valore letto
restituito dalla funzione è quello precedente alla scrittura.
I parametri accessibili attraverso questa funzione sono moltissimi, e possono essere trovati in
sysctl.h, essi inoltre dipendono anche dallo stato corrente del kernel (ad esempio dai moduli
che sono stati caricati nel sistema) e in genere i loro nomi possono variare da una versione di
kernel all’altra; per questo è sempre il caso di evitare l’uso di sysctl quando esistono modalità
alternative per ottenere le stesse informazioni. Alcuni esempi di parametri ottenibili sono:
• il nome di dominio
• i parametri del meccanismo di paging.
• il filesystem montato come radice
• la data di compilazione del kernel
• i parametri dello stack TCP
• il numero massimo di file aperti
Come accennato in Linux si ha una modalità alternativa per accedere alle stesse informa-
zioni di sysctl attraverso l’uso del filesystem /proc. Questo è un filesystem virtuale, generato
direttamente dal kernel, che non fa riferimento a nessun dispositivo fisico, ma presenta in forma
di file alcune delle strutture interne del kernel stesso.
In particolare l’albero dei valori di sysctl viene presentato in forma di file nella directory
/proc/sys, cosicché è possibile accedervi specificando un pathname e leggendo e scrivendo sul
file corrispondente al parametro scelto. Il kernel si occupa di generare al volo il contenuto ed i
nomi dei file corrispondenti, e questo ha il grande vantaggio di rendere accessibili i vari parametri
a qualunque comando di shell e di permettere la navigazione dell’albero dei valori.
Alcune delle corrispondenze dei file presenti in /proc/sys con i valori di sysctl sono ri-
portate nei commenti del codice che può essere trovato in linux/sysctl.h,6 la informazione
disponibile in /proc/sys è riportata inoltre nella documentazione inclusa nei sorgenti del kernel,
nella directory Documentation/sysctl.
Ma oltre alle informazioni ottenibili da sysctl dentro proc sono disponibili moltissime altre
informazioni, fra cui ad esempio anche quelle fornite da uname (vedi sez. 8.1.5) che sono mante-
nute nei file ostype, hostname, osrelease, version e domainname di /proc/sys/kernel/.
5
si tenga presente che includendo solo unistd.h, saranno definiti solo i parametri generici; dato che ce ne
sono molti specifici dell’implementazione, nel caso di Linux occorrerà includere anche i file linux/unistd.h e
linux/sysctl.h.
6
indicando un file di definizioni si fa riferimento alla directory standard dei file di include, che in ogni
distribuzione che si rispetti è /usr/include.

8.2.2 La gestione delle proprietà dei filesystem
Come accennato in sez. 4.1.1 per poter accedere ai file occorre prima rendere disponibile al
sistema il filesystem su cui essi sono memorizzati; l’operazione di attivazione del filesystem è
chiamata montaggio, per far questo in Linux7 si usa la funzione mount il cui prototipo è:
#include <sys/mount.h>
mount(const char *source, const char *target, const char *filesystemtype,
unsigned long mountflags, const void *data)
Monta il filesystem di tipo filesystemtype contenuto in source sulla directory target.
La funzione ritorna 0 in caso di successo e -1 in caso di fallimento, nel qual caso gli errori comuni
a tutti i filesystem che possono essere restituiti in errno sono:
ENODEV filesystemtype non esiste o non è configurato nel kernel.
ENOTBLK non si è usato un block device per source quando era richiesto.
EBUSY source è già montato, o non può essere rimontato in read-only perché ci sono ancora
file aperti in scrittura, o target è ancora in uso.
EINVAL il device source presenta un superblock non valido, o si è cercato di rimontare un
filesystem non ancora montato, o di montarlo senza che target sia un mount point o
di spostarlo quando target non è un mount point o è /.
EACCES non si ha il permesso di accesso su uno dei componenti del pathname, o si è cercato
di montare un filesystem disponibile in sola lettura senza averlo specificato o il device
source è su un filesystem montato con l’opzione MS_NODEV.
ENXIO il major number del device source è sbagliato.
EMFILE la tabella dei device dummy è piena.
ed inoltre ENOTDIR, EFAULT, ENOMEM, ENAMETOOLONG, ENOENT o ELOOP.
La funzione monta sulla directory target, detta mount point, il filesystem contenuto in
source. In generale un filesystem è contenuto su un disco, e l’operazione di montaggio corri-
sponde a rendere visibile al sistema il contenuto del suddetto disco, identificato attraverso il file
di dispositivo ad esso associato.
Ma la struttura del virtual filesystem vista in sez. 4.2.1 è molto più flessibile e può essere
usata anche per oggetti diversi da un disco. Ad esempio usando il loop device si può montare
un file qualunque (come l’immagine di un CD-ROM o di un floppy) che contiene un filesystem,
inoltre alcuni filesystem, come proc o devfs sono del tutto virtuali, i loro dati sono generati al
volo ad ogni lettura, e passati al kernel ad ogni scrittura.
Il tipo di filesystem è specificato da filesystemtype, che deve essere una delle stringhe
riportate nel file /proc/filesystems, che contiene l’elenco dei filesystem supportati dal kernel;
nel caso si sia indicato uno dei filesystem virtuali, il contenuto di source viene ignorato.
Dopo l’esecuzione della funzione il contenuto del filesystem viene resto disponibile nella direc-
tory specificata come mount point, il precedente contenuto di detta directory viene mascherato
dal contenuto della directory radice del filesystem montato.
Dal kernel 2.4.x inoltre è divenuto possibile sia spostare atomicamente un mount point da
una directory ad un’altra, sia montare in diversi mount point lo stesso filesystem, sia montare più
filesystem sullo stesso mount point (nel qual caso vale quanto appena detto, e solo il contenuto
dell’ultimo filesystem montato sarà visibile).
Ciascun filesystem è dotato di caratteristiche specifiche che possono essere attivate o meno,
alcune di queste sono generali (anche se non è detto siano disponibili in ogni filesystem), e
vengono specificate come opzioni di montaggio con l’argomento mountflags.
7
la funzione è specifica di Linux e non è portabile.

In Linux mountflags deve essere un intero a 32 bit i cui 16 più significativi sono un magic
number8 mentre i 16 meno significativi sono usati per specificare le opzioni; essi sono usati come
maschera binaria e vanno impostati con un OR aritmetico della costante MS_MGC_VAL con i valori
riportati in tab. 8.9.
Parametro Valore Significato
MS_RDONLY 1 Monta in sola lettura.
MS_NOSUID 2 Ignora i bit suid e sgid.
MS_NODEV 4 Impedisce l’accesso ai file di dispositivo.
MS_NOEXEC 8 Impedisce di eseguire programmi.
MS_SYNCHRONOUS 16 Abilita la scrittura sincrona.
MS_REMOUNT 32 Rimonta il filesystem cambiando le opzioni.
MS_MANDLOCK 64 Consente il mandatory locking (vedi sez. 12.1.5).
S_WRITE 128 Scrive normalmente.
S_APPEND 256 Consente la scrittura solo in append mode (vedi sez. 6.3.1).
S_IMMUTABLE 512 Impedisce che si possano modificare i file.
MS_NOATIME 1024 Non aggiorna gli access time (vedi sez. 5.2.4).
MS_NODIRATIME 2048 Non aggiorna gli access time delle directory.
MS_BIND 4096 Monta il filesystem altrove.
MS_MOVE 8192 Sposta atomicamente il punto di montaggio.
Tabella 8.9: Tabella dei codici dei flag di montaggio di un filesystem.
Per l’impostazione delle caratteristiche particolari di ciascun filesystem si usa invece l’argo-
mento data che serve per passare le ulteriori informazioni necessarie, che ovviamente variano da
filesystem a filesystem.
La funzione mount può essere utilizzata anche per effettuare il rimontaggio di un filesystem,
cosa che permette di cambiarne al volo alcune delle caratteristiche di funzionamento (ad esempio
passare da sola lettura a lettura/scrittura). Questa operazione è attivata attraverso uno dei bit
di mountflags, MS_REMOUNT, che se impostato specifica che deve essere effettuato il rimontaggio
del filesystem (con le opzioni specificate dagli altri bit), anche in questo caso il valore di source
viene ignorato.
Una volta che non si voglia più utilizzare un certo filesystem è possibile smontarlo usando la
funzione umount, il cui prototipo è:
umount(const char *target)
Smonta il filesystem montato sulla directory target.
La funzione ritorna 0 in caso di successo e -1 in caso di fallimento, nel qual caso errno assumerà
uno dei valori:
EBUSY target è la directory di lavoro di qualche processo, o contiene dei file aperti, o un
altro mount point.
ed inoltre ENOTDIR, EFAULT, ENOMEM, ENAMETOOLONG, ENOENT o ELOOP.
la funzione prende il nome della directory su cui il filesystem è montato e non il file o il dispositivo
che è stato montato,9 in quanto con il kernel 2.4.x è possibile montare lo stesso dispositivo in più
punti. Nel caso più di un filesystem sia stato montato sullo stesso mount point viene smontato
quello che è stato montato per ultimo.
Si tenga presente che la funzione fallisce quando il filesystem è occupato, questo avviene
quando ci sono ancora file aperti sul filesystem, se questo contiene la directory di lavoro corrente
8
cioè un numero speciale usato come identificativo, che nel caso è 0xC0ED; si può usare la costante MS_MGC_MSK
per ottenere la parte di mountflags riservata al magic number.
9
questo è vero a partire dal kernel 2.3.99-pre7, prima esistevano due chiamate separate e la funzione poteva
essere usata anche specificando il file di dispositivo.

di un qualunque processo o il mount point di un altro filesystem; in questo caso l’errore restituito
è EBUSY.
Linux provvede inoltre una seconda funzione, umount2, che in alcuni casi permette di forzare
lo smontaggio di un filesystem, anche quando questo risulti occupato; il suo prototipo è:
umount2(const char *target, int flags)
La funzione è identica a umount per comportamento e codici di errore, ma con flags si può
specificare se forzare lo smontaggio.
Il valore di flags è una maschera binaria, e al momento l’unico valore definito è il bit
MNT_FORCE; gli altri bit devono essere nulli. Specificando MNT_FORCE la funzione cercherà di
liberare il filesystem anche se è occupato per via di una delle condizioni descritte in precedenza.
A seconda del tipo di filesystem alcune (o tutte) possono essere superate, evitando l’errore di
EBUSY. In tutti i casi prima dello smontaggio viene eseguita una sincronizzazione dei dati.
Altre due funzioni specifiche di Linux,10 utili per ottenere in maniera diretta informazioni
riguardo al filesystem su cui si trova un certo file, sono statfs e fstatfs, i cui prototipi sono:
#include <sys/vfs.h>
int statfs(const char *path, struct statfs *buf)
int fstatfs(int fd, struct statfs *buf)
Restituisce in buf le informazioni relative al filesystem su cui è posto il file specificato.
Le funzioni ritornano 0 in caso di successo e -1 in caso di errore, nel qual caso errno assumerà
uno dei valori:
ENOSYS il filesystem su cui si trova il file specificato non supporta la funzione.
e EFAULT ed EIO per entrambe, EBADF per fstatfs, ENOTDIR, ENAMETOOLONG, ENOENT, EACCES, ELOOP
per statfs.
Queste funzioni permettono di ottenere una serie di informazioni generali riguardo al filesy-
stem su cui si trova il file specificato; queste vengono restituite all’indirizzo buf di una struttura
statfs definita come in fig. 8.2, ed i campi che sono indefiniti per il filesystem in esame sono
impostati a zero. I valori del campo f_type sono definiti per i vari filesystem nei relativi file
di header dei sorgenti del kernel da costanti del tipo XXX_SUPER_MAGIC, dove XXX in genere è il
nome del filesystem stesso.
struct statfs {
long f_type; /* tipo di filesystem */
long f_bsize; /* dimensione ottimale dei blocchi di I/O */
long f_blocks; /* blocchi totali nel filesystem */
long f_bfree; /* blocchi liberi nel filesystem */
long f_bavail; /* blocchi liberi agli utenti normali */
long f_files; /* inode totali nel filesystem */
long f_ffree; /* inode liberi nel filesystem */
fsid_t f_fsid; /* filesystem id */
long f_namelen; /* lunghezza massima dei nomi dei file */
long f_spare [6]; /* riservati per uso futuro */
};
Figura 8.2: La struttura statfs.
Le glibc provvedono infine una serie di funzioni per la gestione dei due file /etc/fstab ed
/etc/mtab, che convenzionalmente sono usati in quasi tutti i sistemi unix-like per mantenere
10
esse si trovano anche su BSD, ma con una struttura diversa.

rispettivamente le informazioni riguardo ai filesystem da montare e a quelli correntemente mon-
tati. Le funzioni servono a leggere il contenuto di questi file in opportune strutture fstab e
mntent, e, per /etc/mtab per inserire e rimuovere le voci presenti nel file.
In generale si dovrebbero usare queste funzioni (in particolare quelle relative a /etc/mtab),
quando si debba scrivere un programma che effettua il montaggio di un filesystem; in real-
tà in questi casi è molto più semplice invocare direttamente il programma mount, per cui
ne tralasceremo la trattazione, rimandando al manuale delle glibc [5] per la documentazione
completa.
8.2.3 La gestione delle informazioni su utenti e gruppi
Tradizionalmente le informazioni utilizzate nella gestione di utenti e gruppi (password, corri-
spondenze fra nomi simbolici e user-id, home directory, ecc.) venivano registrate all’interno dei
due file di testo /etc/passwd ed /etc/group,11 il cui formato è descritto dalle relative pagine
del manuale12 e tutte le funzioni che richiedevano l’accesso a queste informazione andavano a
leggere direttamente il contenuto di questi file.
Col tempo però questa impostazione ha incominciato a mostrare dei limiti: da una parte il
meccanismo classico di autenticazione è stato ampliato, ed oggi la maggior parte delle distribu-
zioni di GNU/Linux usa la libreria PAM (sigla che sta per Pluggable Authentication Method) che
fornisce una interfaccia comune per i processi di autenticazione,13 svincolando completamente
le singole applicazione dai dettagli del come questa viene eseguita e di dove vengono mantenuti
i dati relativi; dall’altra con il diffondersi delle reti la necessità di centralizzare le informazioni
degli utenti e dei gruppi per insiemi di macchine, in modo da mantenere coerenti i dati, ha
portato anche alla necessità di poter recuperare e memorizzare dette informazioni su supporti
diversi, introducendo il sistema del Name Service Switch che tratteremo brevemente più avanti
(in sez. 17.1.1) dato che la maggior parte delle sua applicazioni sono relative alla risoluzioni di
nomi di rete.
In questo paragrafo ci limiteremo comunque a trattare le funzioni classiche per la lettura delle
informazioni relative a utenti e gruppi tralasciando completamente quelle relative all’autentica-
zione. Le prime funzioni che vedremo sono quelle previste dallo standard POSIX.1; queste sono
del tutto generiche e si appoggiano direttamente al Name Service Switch, per cui sono in grado
di ricevere informazioni qualunque sia il supporto su cui esse vengono mantenute. Per leggere
le informazioni relative ad un utente si possono usare due funzioni, getpwuid e getpwnam, i cui
prototipi sono:
#include <pwd.h>
struct passwd *getpwuid(uid_t uid)
struct passwd *getpwnam(const char *name)
Restituiscono le informazioni relative all’utente specificato.
Le funzioni ritornano il puntatore alla struttura contenente le informazioni in caso di successo e
NULL nel caso non sia stato trovato nessun utente corrispondente a quanto specificato.
11
in realtà oltre a questi nelle distribuzioni più recenti è stato introdotto il sistema delle shadow password che
prevede anche i due file /etc/shadow e /etc/gshadow, in cui sono state spostate le informazioni di autentica-
zione (ed inserite alcune estensioni) per toglierle dagli altri file che devono poter essere letti per poter effettuare
l’associazione fra username e uid.
12
nella quinta sezione, quella dei file di configurazione, occorre cioè usare man 5 passwd dato che altrimenti si
avrebbe la pagina di manuale del comando passwd.
13
il Pluggable Authentication Method è un sistema modulare, in cui è possibile utilizzare anche più meccanismi
insieme, diventa cos`ı possibile avere vari sistemi di riconoscimento (biometria, chiavi hardware, ecc.), diversi
formati per le password e diversi supporti per le informazioni, il tutto in maniera trasparente per le applicazioni
purché per ciascun meccanismo si disponga della opportuna libreria che implementa l’interfaccia di PAM.

Le due funzioni forniscono le informazioni memorizzate nel registro degli utenti (che nelle
versioni più recenti possono essere ottenute attraverso PAM) relative all’utente specificato at-
traverso il suo uid o il nome di login. Entrambe le funzioni restituiscono un puntatore ad una
struttura di tipo passwd la cui definizione (anch’essa eseguita in pwd.h) è riportata in fig. 8.3,
dove è pure brevemente illustrato il significato dei vari campi.
struct passwd {
char *pw_name; /* user name */
char *pw_passwd; /* user password */
uid_t pw_uid; /* user id */
gid_t pw_gid; /* group id */
char *pw_gecos; /* real name */
char *pw_dir; /* home directory */
char *pw_shell; /* shell program */
};
Figura 8.3: La struttura passwd contenente le informazioni relative ad un utente del sistema.
La struttura usata da entrambe le funzioni è allocata staticamente, per questo motivo viene
sovrascritta ad ogni nuova invocazione, lo stesso dicasi per la memoria dove sono scritte le
stringhe a cui i puntatori in essa contenuti fanno riferimento. Ovviamente questo implica che
dette funzioni non possono essere rientranti; per questo motivo ne esistono anche due versioni
alternative (denotate dalla solita estensione _r), i cui prototipi sono:
#include <pwd.h>
struct passwd *getpwuid_r(uid_t uid, struct passwd *password, char *buffer,
size_t buflen, struct passwd **result)
struct passwd *getpwnam_r(const char *name, struct passwd *password, char
*buffer, size_t buflen, struct passwd **result)
Restituiscono le informazioni relative all’utente specificato.
Le funzioni ritornano 0 in caso di successo e un codice d’errore altrimenti, nel qual caso errno
sarà impostata opportunamente.
In questo caso l’uso è molto più complesso, in quanto bisogna prima allocare la memoria
necessaria a contenere le informazioni. In particolare i valori della struttura passwd saranno
restituiti all’indirizzo password mentre la memoria allocata all’indirizzo buffer, per un massimo
di buflen byte, sarà utilizzata per contenere le stringhe puntate dai campi di password. Infine
all’indirizzo puntato da result viene restituito il puntatore ai dati ottenuti, cioè buffer nel caso
l’utente esista, o NULL altrimenti. Qualora i dati non possano essere contenuti nei byte specificati
da buflen, la funzione fallirà restituendo ERANGE (e result sarà comunque impostato a NULL).
Del tutto analoghe alle precedenti sono le funzioni getgrnam e getgrgid (e le relative ana-
loghe rientranti con la stessa estensione _r) che permettono di leggere le informazioni relative
ai gruppi, i loro prototipi sono:
#include <grp.h>
struct group *getgrgid(gid_t gid)
struct group *getgrnam(const char *name)
struct group *getpwuid_r(gid_t gid, struct group *password, char *buffer, size_t
buflen, struct group **result)
struct group *getpwnam_r(const char *name, struct group *password, char *buffer,
size_t buflen, struct group **result)
Restituiscono le informazioni relative al gruppo specificato.
Le funzioni ritornano 0 in caso di successo e un codice d’errore altrimenti, nel qual caso errno
sarà impostata opportunamente.

Il comportamento di tutte queste funzioni è assolutamente identico alle precedenti che leggono
le informazioni sugli utenti, l’unica differenza è che in questo caso le informazioni vengono
restituite in una struttura di tipo group, la cui definizione è riportata in fig. 8.4.
struct group {
char *gr_name; /* group name */
char *gr_passwd; /* group password */
gid_t gr_gid; /* group id */
char ** gr_mem; /* group members */
};
Figura 8.4: La struttura group contenente le informazioni relative ad un gruppo del sistema.
Le funzioni viste finora sono in grado di leggere le informazioni sia direttamente dal file delle
password in /etc/passwd che tramite il sistema del Name Service Switch e sono completamente
generiche. Si noti però che non c’è una funzione che permetta di impostare direttamente una
password.14 Dato che POSIX non prevede questa possibilità esiste un’altra interfaccia che lo
fa, derivata da SVID le cui funzioni sono riportate in tab. 8.10. Questa però funziona soltanto
quando le informazioni sono mantenute su un apposito file di registro di utenti e gruppi, con il
formato classico di /etc/passwd e /etc/group.
Funzione Significato
fgetpwent Legge una voce dal file di registro degli utenti specificato.
fgetpwent_r Come la precedente, ma rientrante.
putpwent Immette una voce in un file di registro degli utenti.
getpwent Legge una voce da /etc/passwd.
getpwent_r Come la precedente, ma rientrante.
setpwent Ritorna all’inizio di /etc/passwd.
endpwent Chiude /etc/passwd.
fgetgrent Legge una voce dal file di registro dei gruppi specificato.
fgetgrent_r Come la precedente, ma rientrante.
putgrent Immette una voce in un file di registro dei gruppi.
getgrent Legge una voce da /etc/group.
getgrent_r Come la precedente, ma rientrante.
setgrent Ritorna all’inizio di /etc/group.
endgrent Chiude /etc/group.
Tabella 8.10: Funzioni per la manipolazione dei campi di un file usato come registro per utenti o gruppi nel
formato di /etc/passwd e /etc/group.
Dato che oramai la gran parte delle distribuzioni di GNU/Linux utilizzano almeno le shadow
password (quindi con delle modifiche rispetto al formato classico del file /etc/passwd), si tenga
presente che le funzioni di questa interfaccia che permettono di scrivere delle voci in un registro
degli utenti (cioè putpwent e putgrent) non hanno la capacità di farlo specificando tutti i
contenuti necessari rispetto a questa estensione. Per questo motivo l’uso di queste funzioni è
deprecato, in quanto comunque non funzionale, pertanto ci limiteremo a fornire soltanto l’elenco
di tab. 8.10, senza nessuna spiegazione ulteriore. Chi volesse insistere ad usare questa interfaccia
può fare riferimento alle pagine di manuale delle rispettive funzioni ed al manuale delle glibc
per i dettagli del funzionamento.
14
in realtà questo può essere fatto ricorrendo a PAM, ma questo è un altro discorso.

8.2.4 Il registro della contabilità degli utenti
L’ultimo insieme di funzioni relative alla gestione del sistema che esamineremo è quello che
permette di accedere ai dati del registro della cosiddetta contabilità (o accounting) degli utenti.
In esso vengono mantenute una serie di informazioni storiche relative sia agli utenti che si sono
collegati al sistema, (tanto per quelli correntemente collegati, che per la registrazione degli accessi
precedenti), sia relative all’intero sistema, come il momento di lancio di processi da parte di init,
il cambiamento dell’orologio di sistema, il cambiamento di runlevel o il riavvio della macchina.
I dati vengono usualmente15 memorizzati nei due file /var/run/utmp e /var/log/wtmp.16
Quando un utente si collega viene aggiunta una voce a /var/run/utmp in cui viene memorizzato
il nome di login, il terminale da cui ci si collega, l’uid della shell di login, l’orario della connessione
ed altre informazioni. La voce resta nel file fino al logout, quando viene cancellata e spostata in
/var/log/wtmp.
In questo modo il primo file viene utilizzato per registrare chi sta utilizzando il sistema al
momento corrente, mentre il secondo mantiene la registrazione delle attività degli utenti. A
quest’ultimo vengono anche aggiunte delle voci speciali per tenere conto dei cambiamenti del
sistema, come la modifica del runlevel, il riavvio della macchina, ecc. Tutte queste informazioni
sono descritte in dettaglio nel manuale delle glibc.
Questi file non devono mai essere letti direttamente, ma le informazioni che contengono
possono essere ricavate attraverso le opportune funzioni di libreria. Queste sono analoghe alle
precedenti funzioni (vedi tab. 8.10) usate per accedere al registro degli utenti, solo che in questo
caso la struttura del registro della contabilità è molto più complessa, dato che contiene diversi
tipi di informazione.
Le prime tre funzioni, setutent, endutent e utmpname servono rispettivamente a aprire e a
chiudere il file che contiene il registro, e a specificare su quale file esso viene mantenuto. I loro
prototipi sono:
#include <utmp.h>
void utmpname(const char *file)
Specifica il file da usare come registro.
void setutent(void)
Apre il file del registro, posizionandosi al suo inizio.
void endutent(void)
Chiude il file del registro.
Le funzioni non ritornano codici di errore.
e si tenga presente che le funzioni non restituiscono nessun valore, pertanto non è possi-
bile accorgersi di eventuali errori (ad esempio se si è impostato un nome di file sbagliato con
utmpname).
Nel caso non si sia utilizzata utmpname per specificare un file di registro alternativo, sia
setutent che endutent operano usando il default che è /var/run/utmp. Il nome di questo
file, cos`ı come una serie di altri valori di default per i pathname di uso più comune, viene
mantenuto nei valori di una serie di costanti definite includendo paths.h, in particolare quelle
che ci interessano sono:
_PATH_UTMP specifica il file che contiene il registro per gli utenti correntemente collegati; questo
è il valore che viene usato se non si è utilizzato utmpname per modificarlo.
_PATH_WTMP specifica il file che contiene il registro per l’archivio storico degli utenti collegati.
15
questa è la locazione specificata dal Linux Filesystem Hierarchy Standard, adottato dalla gran parte delle
distribuzioni.
16
non si confonda quest’ultimo con il simile /var/log/btmp dove invece vengono memorizzati dal programma
di login tutti tentativi di accesso fallito.

che nel caso di Linux hanno un valore corrispondente ai file /var/run/utmp e /var/log/wtmp
citati in precedenza.
Una volta aperto il file del registro degli utenti si può eseguire una scansione leggendo o
scrivendo una voce con le funzioni getutent, getutid, getutline e pututline, i cui prototipi
sono:
#include <utmp.h>
struct utmp *getutent(void)
Legge una voce dalla posizione corrente nel registro.
struct utmp *getutid(struct utmp *ut)
Ricerca una voce sul registro in base al contenuto di ut.
struct utmp *getutline(struct utmp *ut)
Ricerca nel registro la prima voce corrispondente ad un processo sulla linea di terminale
specificata tramite ut.
struct utmp *pututline(struct utmp *ut)
Scrive una voce nel registro.
Le funzioni ritornano il puntatore ad una struttura utmp in caso di successo e NULL in caso di
errore.
Tutte queste funzioni fanno riferimento ad una struttura di tipo utmp, la cui definizione in
Linux è riportata in fig. 8.5. Le prime tre funzioni servono per leggere una voce dal registro;
getutent legge semplicemente la prima voce disponibile; le altre due permettono di eseguire
una ricerca.
struct utmp
{
short int ut_type; /* Type of login. */
pid_t ut_pid; /* Process ID of login process. */
char ut_line[UT_LINESIZE ]; /* Devicename. */
char ut_id [4]; /* Inittab ID. */
char ut_user[UT_NAMESIZE ]; /* Username. */
char ut_host[UT_HOSTSIZE ]; /* Hostname for remote login. */
struct exit_status ut_exit; /* Exit status of a process marked
as DEAD_PROCESS. */
long int ut_session; /* Session ID , used for windowing. */
struct timeval ut_tv; /* Time entry was made. */
int32_t ut_addr_v6 [4]; /* Internet address of remote host. */
char __unused [20]; /* Reserved for future use. */
};
Figura 8.5: La struttura utmp contenente le informazioni di una voce del registro di contabilità.
Con getutid si può cercare una voce specifica, a seconda del valore del campo ut_type
dell’argomento ut. Questo può assumere i valori riportati in tab. 8.11, quando assume i valori
RUN_LVL, BOOT_TIME, OLD_TIME, NEW_TIME, verrà restituito la prima voce che corrisponde al tipo
determinato; quando invece assume i valori INIT_PROCESS, LOGIN_PROCESS, USER_PROCESS o
DEAD_PROCESS verrà restituita la prima voce corrispondente al valore del campo ut_id specificato
in ut.
La funzione getutline esegue la ricerca sulle voci che hanno ut_type uguale a LOGIN_PROCESS
o USER_PROCESS, restituendo la prima che corrisponde al valore di ut_line, che specifica il de-
vice17 di terminale che interessa. Lo stesso criterio di ricerca è usato da pututline per trovare
uno spazio dove inserire la voce specificata, qualora non sia trovata la voce viene aggiunta in
coda al registro.
17
espresso senza il /dev/ iniziale.

8.3. IL CONTROLLO DELL’USO DELLE RISORSE 241
Valore Significato
EMPTY Non contiene informazioni valide.
RUN_LVL Identica il runlevel del sistema.
BOOT_TIME Identifica il tempo di avvio del sistema.
OLD_TIME Identifica quando è stato modificato l’orologio di sistema.
NEW_TIME Identifica da quanto è stato modificato il sistema.
INIT_PROCESS Identifica un processo lanciato da init.
LOGIN_PROCESS Identifica un processo di login.
USER_PROCESS Identifica un processo utente.
DEAD_PROCESS Identifica un processo terminato.
Tabella 8.11: Classificazione delle voci del registro a seconda dei possibili valori del campo ut_type.
In generale occorre però tenere conto che queste funzioni non sono completamente standar-
dizzate, e che in sistemi diversi possono esserci differenze; ad esempio pututline restituisce void
in vari sistemi (compreso Linux, fino alle libc5). Qui seguiremo la sintassi fornita dalle glibc,
ma gli standard POSIX 1003.1-2001 e XPG4.2 hanno introdotto delle nuove strutture (e relativi
file) di tipo utmpx, che sono un sovrainsieme di utmp.
Le glibc utilizzano già una versione estesa di utmp, che rende inutili queste nuove strutture;
pertanto esse e le relative funzioni di gestione (getutxent, getutxid, getutxline, pututxline,
setutxent e endutxent) sono ridefinite come sinonimi delle funzioni appena viste.
Come visto in sez. 8.2.3, l’uso di strutture allocate staticamente rende le funzioni di lettura
non rientranti; per questo motivo le glibc forniscono anche delle versioni rientranti: getutent_r,
getutid_r, getutline_r, che invece di restituire un puntatore restituiscono un intero e pren-
dono due argomenti aggiuntivi. Le funzioni si comportano esattamente come le analoghe non
rientranti, solo che restituiscono il risultato all’indirizzo specificato dal primo argomento aggiun-
tivo (di tipo struct utmp *buffer) mentre il secondo (di tipo struct utmp **result) viene
usato per restituire il puntatore allo stesso buffer.
Infine le glibc forniscono come estensione per la scrittura delle voci in wmtp altre due funzioni,
updwtmp e logwtmp, i cui prototipi sono:
#include <utmp.h>
void updwtmp(const char *wtmp_file, const struct utmp *ut)
Aggiunge la voce ut nel registro wmtp.
void logwtmp(const char *line, const char *name, const char *host)
Aggiunge nel registro una voce con i valori specificati.
La prima funzione permette l’aggiunta di una voce a wmtp specificando direttamente una
struttura utmp, mentre la seconda utilizza gli argomenti line, name e host per costruire la voce
che poi aggiunge chiamando updwtmp.
8.3 Il controllo dell’uso delle risorse
Dopo aver esaminato le funzioni che permettono di controllare le varie caratteristiche, capacità
e limiti del sistema a livello globale, in questa sezione tratteremo le varie funzioni che vengono
usate per quantificare le risorse (CPU, memoria, ecc.) utilizzate da ogni singolo processo e quelle
che permettono di imporre a ciascuno di essi vincoli e limiti di utilizzo.
8.3.1 L’uso delle risorse
Come abbiamo accennato in sez. 3.2.4 le informazioni riguardo l’utilizzo delle risorse da parte
di un processo è mantenuto in una struttura di tipo rusage, la cui definizione (che si trova in
sys/resource.h) è riportata in fig. 8.6.

struct rusage {
struct timeval ru_utime; /* user time used */
struct timeval ru_stime; /* system time used */
long ru_maxrss; /* maximum resident set size */
long ru_ixrss; /* integral shared memory size */
long ru_idrss; /* integral unshared data size */
long ru_isrss; /* integral unshared stack size */
long ru_minflt; /* page reclaims */
long ru_majflt; /* page faults */
long ru_nswap; /* swaps */
long ru_inblock; /* block input operations */
long ru_oublock; /* block output operations */
long ru_msgsnd; /* messages sent */
long ru_msgrcv; /* messages received */
long ru_nsignals; ; /* signals received */
long ru_nvcsw; /* voluntary context switches */
long ru_nivcsw; /* involuntary context switches */
};
Figura 8.6: La struttura rusage per la lettura delle informazioni dei delle risorse usate da un processo.
La definizione della struttura in fig. 8.6 è ripresa da BSD 4.3,18 ma attualmente (con i kernel
della serie 2.4.x e 2.6.x) i soli campi che sono mantenuti sono: ru_utime, ru_stime, ru_minflt,
ru_majflt, e ru_nswap. I primi due indicano rispettivamente il tempo impiegato dal processo
nell’eseguire le istruzioni in user space, e quello impiegato dal kernel nelle system call eseguite
per conto del processo.
Gli altri tre campi servono a quantificare l’uso della memoria virtuale e corrispondono ri-
spettivamente al numero di page fault (vedi sez. 2.2.1) avvenuti senza richiedere I/O su disco (i
cosiddetti minor page fault), a quelli che invece han richiesto I/O su disco (detti invece major
page fault) ed al numero di volte che il processo è stato completamente tolto dalla memoria per
essere inserito nello swap.
In genere includere esplicitamente <sys/time.h> non è più strettamente necessario, ma
aumenta la portabilità, e serve comunque quando, come nella maggior parte dei casi, si debba
accedere ai campi di rusage relativi ai tempi di utilizzo del processore, che sono definiti come
strutture di tipo timeval (vedi fig. 5.7).
Questa è la stessa struttura utilizzata da wait4 (si ricordi quando visto in sez. 3.2.4) per
ricavare la quantità di risorse impiegate dal processo di cui si è letto lo stato di terminazione,
ma essa può anche essere letta direttamente utilizzando la funzione getrusage, il cui prototipo
è:
#include <unistd.h>
int getrusage(int who, struct rusage *usage)
Legge la quantità di risorse usate da un processo.
La funzione ritorna 0 in caso di successo e -1 in caso di errore, nel qual caso errno può essere
EINVAL o EFAULT.
L’argomento who permette di specificare il processo di cui si vuole leggere l’uso delle ri-
sorse; esso può assumere solo i due valori RUSAGE_SELF per indicare il processo corrente e
18
questo non ha a nulla a che fare con il cosiddetto BSD accounting (vedi sez. 8.3.4) che si trova nelle opzioni
di compilazione del kernel (e di norma è disabilitato) che serve per mantenere una contabilità delle risorse usate
da ciascun processo in maniera molto più dettagliata.

RUSAGE_CHILDREN per indicare l’insieme dei processi figli di cui si è ricevuto lo stato di ter-
minazione.
8.3.2 Limiti sulle risorse
Come accennato nell’introduzione il kernel mette a disposizione delle funzionalità che permettono
non solo di mantenere dati statistici relativi all’uso delle risorse, ma anche di imporre dei limiti
precisi sul loro utilizzo da parte dei vari processi o degli utenti.
Per far questo esistono una serie di risorse e ad ogni processo vengono associati due diversi
limiti per ciascuna di esse; questi sono il limite corrente (o current limit) che esprime un valore
massimo che il processo non può superare ad un certo momento, ed il limite massimo (o maximum
limit) che invece esprime il valore massimo che può assumere il limite corrente. In generale il
primo viene chiamato anche soft limit dato che il suo valore può essere aumentato dal processo
stesso durante l’esecuzione, ciò può però essere fatto solo fino al valore del secondo, che per
questo viene detto hard limit.
Valore Significato
RLIMIT_AS La dimensione massima della memoria virtuale di un processo, il cosiddetto Address
Space, (vedi sez. 2.2.1). Se il limite viene superato dall’uso di funzioni come brk,
mremap o mmap esse falliranno con un errore di ENOMEM, mentre se il superamento viene
causato dalla crescita dello stack il processo riceverà un segnale di SIGSEGV.
RLIMIT_CORE La massima dimensione per di un file di core dump (vedi sez. 9.2.2) creato nella
terminazione di un processo; file di dimensioni maggiori verranno troncati a questo
valore, mentre con un valore si bloccherà la creazione dei core dump.
RLIMIT_CPU Il massimo tempo di CPU (vedi sez. 8.4.2) che il processo può usare. Il superamento del
limite corrente comporta l’emissione di un segnale di SIGXCPU, la cui azione predefinita
(vedi sez. 9.2) è terminare il processo, una volta al secondo fino al raggiungimento
del limite massimo. Il superamento del limite massimo comporta l’emissione di un
segnale di SIGKILL.19
RLIMIT_DATA La massima dimensione del segmento dati di un processo (vedi sez. 2.2.2). Il tentativo
di allocare più memoria di quanto indicato dal limite corrente causa il fallimento della
funzione di allocazione (brk o sbrk) con un errore di ENOMEM.
RLIMIT_FSIZE La massima dimensione di un file che un processo può creare. Se il processo cerca di
scrivere oltre questa dimensione riceverà un segnale di SIGXFSZ, che di norma termina
il processo; se questo viene intercettato la system call che ha causato l’errore fallirà
con un errore di EFBIG.
RLIMIT_LOCKS È un limite presente solo nelle prime versioni del kernel 2.4 sul numero massimo di
file lock (vedi sez. 12.1) che un processo poteva effettuare.
RLIMIT_MEMLOCK L’ammontare massimo di memoria che può essere bloccata in RAM da un processo
(vedi sez. 2.2.4). Dal kernel 2.6.9 questo limite comprende anche la memoria che può
essere bloccata da ciascun utente nell’uso della memoria condivisa (vedi sez. 11.2.6)
che viene contabilizzata separatamente ma sulla quale viene applicato questo stesso
limite.
RLIMIT_NOFILE Il numero massimo di file che il processo può aprire. L’apertura di un ulteriore file
farà fallire la funzione (open, dup o pipe) con un errore EMFILE.
RLIMIT_NPROC Il numero massimo di processi che possono essere creati sullo stesso user id real. Se il
limite viene raggiunto fork fallirà con un EAGAIN.
RLIMIT_SIGPENDING Il numero massimo di segnali che possono essere mantenuti in coda per ciascun utente,
considerando sia i segnali normali che real-time (vedi sez. 9.5.1). Il limite è attivo solo
per sigqueue, con kill si potrà sempre inviare un segnale che non sia già presente
su una coda.20
RLIMIT_STACK La massima dimensione dello stack del processo. Se il processo esegue operazioni che
estendano lo stack oltre questa dimensione riceverà un segnale di SIGSEGV.
RLIMIT_RSS L’ammontare massimo di pagine di memoria dato al testo del processo. Il limite è solo
una indicazione per il kernel, qualora ci fosse un surplus di memoria questa verrebbe
assegnata.
Tabella 8.12: Valori possibili dell’argomento resource delle funzioni getrlimit e setrlimit.

In generale il superamento di un limite corrente21 comporta o l’emissione di un segnale o
il fallimento della system call che lo ha provocato;22 per permettere di leggere e di impostare i
limiti di utilizzo delle risorse da parte di un processo sono previste due funzioni, getrlimit e
setrlimit, i cui prototipi sono:
#include <unistd.h>
int getrlimit(int resource, struct rlimit *rlim)
Legge il limite corrente per la risorsa resource.
int setrlimit(int resource, const struct rlimit *rlim)
Imposta il limite per la risorsa resource.
Le funzioni ritornano 0 in caso di successo e -1 in caso di errore, nel qual caso errno assumerà
uno dei valori:
EINVAL i valori per resource non sono validi.
EPERM un processo senza i privilegi di amministratore ha cercato di innalzare i propri limiti.
ed EFAULT.
Entrambe le funzioni permettono di specificare, attraverso l’argomento resource, su quale
risorsa si vuole operare: i possibili valori di questo argomento sono elencati in tab. 8.12. L’acceso
(rispettivamente in lettura e scrittura) ai valori effettivi dei limiti viene poi effettuato attraverso
la struttura rlimit puntata da rlim, la cui definizione è riportata in fig. 8.7, ed i cui campi
corrispondono appunto a limite corrente e limite massimo.
struct rlimit {
rlim_t rlim_cur; /* Soft limit */
rlim_t rlim_max; /* Hard limit (ceiling for rlim_cur) */
};
Figura 8.7: La struttura rlimit per impostare i limiti di utilizzo delle risorse usate da un processo.
Nello specificare un limite, oltre a fornire dei valori specifici, si può anche usare la costante
RLIM_INFINITY che permette di sbloccare l’uso di una risorsa; ma si ricordi che solo un processo
con i privilegi di amministratore23 può innalzare un limite al di sopra del valore corrente del
limite massimo ed usare un valore qualsiasi per entrambi i limiti. Si tenga conto infine che tutti
i limiti vengono ereditati dal processo padre attraverso una fork (vedi sez. 3.2.2) e mantenuti
per gli altri programmi eseguiti attraverso una exec (vedi sez. 3.2.5).
8.3.3 Le risorse di memoria e processore
La gestione della memoria è già stata affrontata in dettaglio in sez. 2.2; abbiamo visto allora che
il kernel provvede il meccanismo della memoria virtuale attraverso la divisione della memoria
fisica in pagine.
18
questo è quanto avviene per i kernel dalla serie 2.2 fino ad oggi (la 2.6.x); altri kernel possono avere com-
portamenti diversi per quanto avviene quando viene superato il soft limit; perciò per avere operazioni portabili è
sempre opportuno intercettare il primo SIGXCPU e terminare in maniera ordinata il processo.
20
il limite su questa risorsa è stato introdotto con il kernel 2.6.8.
21
di norma quanto riportato in tab. 8.12 fa riferimento a quanto avviene al superamento del limite corrente,
con l’eccezione RLIMIT_CPU in cui si ha in comportamento diverso per il superamento dei due limiti.
22
si nuovo c’è una eccezione per RLIMIT_CORE che influenza soltanto la dimensione (o l’eventuale creazione) dei
file di core dump.
23
per essere precisi in questo caso quello che serve è la capability CAP_SYS_RESOURCE (vedi sez. 5.4.4).

In genere tutto ciò è del tutto trasparente al singolo processo, ma in certi casi, come per
l’I/O mappato in memoria (vedi sez. 12.4.1) che usa lo stesso meccanismo per accedere ai file, è
necessario conoscere le dimensioni delle pagine usate dal kernel. Lo stesso vale quando si vuole
gestire in maniera ottimale l’interazione della memoria che si sta allocando con il meccanismo
della paginazione.
Di solito la dimensione delle pagine di memoria è fissata dall’architettura hardware, per cui
il suo valore di norma veniva mantenuto in una costante che bastava utilizzare in fase di compi-
lazione, ma oggi, con la presenza di alcune architetture (ad esempio Sun Sparc) che permettono
di variare questa dimensione, per non dover ricompilare i programmi per ogni possibile modello
e scelta di dimensioni, è necessario poter utilizzare una funzione.
Dato che si tratta di una caratteristica generale del sistema, questa dimensione può essere
ottenuta come tutte le altre attraverso una chiamata a sysconf, 24 ma in BSD 4.2 è stata
introdotta una apposita funzione, getpagesize, che restituisce la dimensione delle pagine di
memoria; il suo prototipo è:
#include <unistd.h>
int getpagesize(void)
Legge le dimensioni delle pagine di memoria.
La funzione ritorna la dimensione di una pagina in byte, e non sono previsti errori.
La funzione è prevista in SVr4, BSD 4.4 e SUSv2, anche se questo ultimo standard la etichetta
come obsoleta, mentre lo standard POSIX 1003.1-2001 la ha eliminata. In Linux è implementata
come una system call nelle architetture in cui essa è necessaria, ed in genere restituisce il valore
del simbolo PAGE_SIZE del kernel, che dipende dalla architettura hardware, anche se le versioni
delle librerie del C precedenti le glibc 2.1 implementavano questa funzione restituendo sempre
un valore statico.
Le glibc forniscono, come specifica estensione GNU, altre due funzioni, get_phys_pages e
get_avphys_pages che permettono di ottenere informazioni riguardo la memoria; i loro prototipi
sono:
#include <sys/sysinfo.h>
long int get_phys_pages(void)
Legge il numero totale di pagine di memoria disponibili per il sistema.
long int get_avphys_pages(void)
Legge il numero di pagine di memoria disponibili nel sistema.
Le funzioni restituiscono un numero di pagine.
Queste funzioni sono equivalenti all’uso della funzione sysconf rispettivamente con i pa-
rametri _SC_PHYS_PAGES e _SC_AVPHYS_PAGES. La prima restituisce il numero totale di pagine
corrispondenti alla RAM della macchina; la seconda invece la memoria effettivamente disponibile
per i processi.
Le glibc supportano inoltre, come estensioni GNU, due funzioni che restituiscono il numero di
processori della macchina (e quello dei processori attivi); anche queste sono informazioni comun-
que ottenibili attraverso sysconf utilizzando rispettivamente i parametri _SC_NPROCESSORS_CONF
e _SC_NPROCESSORS_ONLN.
Infine le glibc riprendono da BSD la funzione getloadavg che permette di ottenere il carico
di processore della macchina, in questo modo è possibile prendere decisioni su quando far partire
eventuali nuovi processi. Il suo prototipo è:
#include <stdlib.h>
int getloadavg(double loadavg[], int nelem)
Legge il carico medio della macchina.
La funzione ritorna il numero di elementi scritti o -1 in caso di errore.
24
nel caso specifico si dovrebbe utilizzare il parametro _SC_PAGESIZE.

La funzione restituisce in ciascun elemento di loadavg il numero medio di processi attivi
sulla coda dello scheduler, calcolato su diversi intervalli di tempo. Il numero di intervalli che si
vogliono leggere è specificato da nelem, dato che nel caso di Linux il carico viene valutato solo
su tre intervalli (corrispondenti a 1, 5 e 15 minuti), questo è anche il massimo valore che può
essere assegnato a questo argomento.
8.3.4 La contabilità in stile BSD
Una ultima modalità per monitorare l’uso delle risorse è, se si è compilato il kernel con il relativo
supporto,25 quella di attivare il cosiddetto BSD accounting, che consente di registrare su file una
serie di informazioni26 riguardo alla contabilità delle risorse utilizzate da ogni processo che viene
terminato.
Linux consente di salvare la contabilità delle informazioni relative alle risorse utilizzate dai
processi grazie alla funzione acct, il cui prototipo è:
#include <unistd.h>
int acct(const char *filename)
Abilita il BSD accounting.
La funzione ritorna 0 in caso di successo o −1 in caso di errore, nel qual caso errno assumerà uno
dei valori:
EACCESS non si hanno i permessi per accedere a pathname.
EPERM il processo non ha privilegi sufficienti ad abilitare il BSD accounting.
ENOSYS il kernel non supporta il BSD accounting.
EUSER non sono disponibili nel kernel strutture per il file o si è finita la memoria.
ed inoltre EFAULT, EIO, ELOOP, ENAMETOOLONG, ENFILE, ENOENT, ENOMEM, ENOTDIR, EROFS.
La funzione attiva il salvataggio dei dati sul file indicato dal pathname contenuti nella stringa
puntata da filename; la funzione richiede che il processo abbia i privilegi di amministratore
(è necessaria la capability CAP_SYS_PACCT, vedi sez. 5.4.4). Se si specifica il valore NULL per
filename il BSD accounting viene invece disabilitato. Un semplice esempio per l’uso di questa
funzione è riportato nel programma AcctCtrl.c dei sorgenti allegati alla guida.
Quando si attiva la contabilità, il file che si indica deve esistere; esso verrà aperto in sola
scrittura;27 le informazioni verranno registrate in append in coda al file tutte le volte che un pro-
cesso termina. Le informazioni vengono salvate in formato binario, e corrispondono al contenuto
della apposita struttura dati definita all’interno del kernel.
Il funzionamento di acct viene inoltre modificato da uno specifico parametro di sistema,
modificabile attraverso /proc/sys/kernel/acct (o tramite la corrispondente sysctl). Esso
contiene tre valori interi, il primo indica la percentuale di spazio disco libero sopra il quale
viene ripresa una registrazione che era stata sospesa per essere scesi sotto il minimo indicato
dal secondo valore (sempre in percentuale di spazio disco libero). Infine l’ultimo valore indica la
frequenza in secondi con cui deve essere controllata detta percentuale.
8.4 La gestione dei tempi del sistema
In questa sezione, una volta introdotti i concetti base della gestione dei tempi da parte del
sistema, tratteremo le varie funzioni attinenti alla gestione del tempo in un sistema unix-like, a
partire da quelle per misurare i veri tempi di sistema associati ai processi, a quelle per convertire
25
se cioè si è abilitata l’opzione di compilazione CONFIG_BSD_PROCESS_ACCT.
26
contenute nella struttura acct definita nel file include/linux/acct.h dei sorgenti del kernel.
27
si applicano al pathname indicato da filename tutte le restrizioni viste in cap. 4.

8.4. LA GESTIONE DEI TEMPI DEL SISTEMA 247
i vari tempi nelle differenti rappresentazioni che vengono utilizzate, a quelle della gestione di
data e ora.
8.4.1 La misura del tempo in Unix
Storicamente i sistemi unix-like hanno sempre mantenuto due distinti tipi di dati per la misure
dei tempi all’interno del sistema: essi sono rispettivamente chiamati calendar time e process time,
secondo le definizioni:
calendar time
detto anche tempo di calendario. È il numero di secondi dalla mezzanotte del primo
gennaio 1970, in tempo universale coordinato (o UTC), data che viene usualmente
indicata con 00:00:00 Jan, 1 1970 (UTC) e chiamata the Epoch. Questo tempo viene
anche chiamato anche GMT (Greenwich Mean Time) dato che l’UTC corrisponde
all’ora locale di Greenwich. È il tempo su cui viene mantenuto l’orologio del kernel, e
viene usato ad esempio per indicare le date di modifica dei file o quelle di avvio dei
processi. Per memorizzare questo tempo è stato riservato il tipo primitivo time_t.
process time
detto talvolta tempo di processore. Viene misurato in clock tick. Un tempo questo
corrispondeva al numero di interruzioni effettuate dal timer di sistema, adesso lo stan-
dard POSIX richiede che esso sia pari al valore della costante CLOCKS_PER_SEC, che
deve essere definita come 1000000, qualunque sia la risoluzione reale dell’orologio di
sistema e la frequenza delle interruzioni del timer.28 Il dato primitivo usato per questo
tempo è clock_t, che ha quindi una risoluzione del microsecondo. Il numero di tick
al secondo può essere ricavato anche attraverso sysconf (vedi sez. 8.1.2). Il vecchio
simbolo CLK_TCK definito in time.h è ormai considerato obsoleto.
In genere si usa il calendar time per esprimere le date dei file e le informazioni analoghe
che riguardano i cosiddetti tempi di orologio, che vengono usati ad esempio per i demoni che
compiono lavori amministrativi ad ore definite, come cron.
Di solito questo tempo viene convertito automaticamente dal valore in UTC al tempo locale,
utilizzando le opportune informazioni di localizzazione (specificate in /etc/timezone). E da
tenere presente che questo tempo è mantenuto dal sistema e non è detto che corrisponda al
tempo tenuto dall’orologio hardware del calcolatore.
Anche il process time di solito si esprime in secondi, ma fornisce una precisione ovviamente
superiore al calendar time (che è mantenuto dal sistema con una granularità di un secondo) e
viene usato per tenere conto dei tempi di esecuzione dei processi. Per ciascun processo il kernel
calcola tre tempi diversi:
clock time
il tempo reale (viene chiamato anche wall clock time o elapsed time) passato dall’avvio
del processo. Chiaramente tale tempo dipende anche dal carico del sistema e da quanti
altri processi stavano girando nello stesso periodo.
user time
il tempo effettivo che il processore ha impiegato nell’esecuzione delle istruzioni del
processo in user space. È quello riportato nella risorsa ru_utime di rusage vista in
sez. 8.3.1.
system time
il tempo effettivo che il processore ha impiegato per eseguire codice delle system call
nel kernel per conto del processo. È quello riportato nella risorsa ru_stime di rusage
vista in sez. 8.3.1.
28
quest’ultima, come accennato in sez. 3.1.1, è invece data dalla costante HZ.

In genere la somma di user time e system time indica il tempo di processore totale che il
sistema ha effettivamente utilizzato per eseguire un certo processo, questo viene chiamato anche
CPU time o tempo di CPU. Si può ottenere un riassunto dei valori di questi tempi quando si
esegue un qualsiasi programma lanciando quest’ultimo come argomento del comando time.
8.4.2 La gestione del process time
Di norma tutte le operazioni del sistema fanno sempre riferimento al calendar time, l’uso del
process time è riservato a quei casi in cui serve conoscere i tempi di esecuzione di un processo
(ad esempio per valutarne l’efficienza). In tal caso infatti fare ricorso al calendar time è inutile
in quanto il tempo può essere trascorso mentre un altro processo era in esecuzione o in attesa
del risultato di una operazione di I/O.
La funzione più semplice per leggere il process time di un processo è clock, che da una
valutazione approssimativa del tempo di CPU utilizzato dallo stesso; il suo prototipo è:
#include <time.h>
clock_t clock(void)
Legge il valore corrente del tempo di CPU.
La funzione ritorna il tempo di CPU usato dal programma e -1 in caso di errore.
La funzione restituisce il tempo in clock tick, quindi se si vuole il tempo in secondi occorre
dividere il risultato per la costante CLOCKS_PER_SEC.29 In genere clock_t viene rappresentato
come intero a 32 bit, il che comporta un valore massimo corrispondente a circa 72 minuti, dopo
i quali il contatore riprenderà lo stesso valore iniziale.
Come accennato in sez. 8.4.1 il tempo di CPU è la somma di altri due tempi, l’user time ed
il system time che sono quelli effettivamente mantenuti dal kernel per ciascun processo. Questi
possono essere letti attraverso la funzione times, il cui prototipo è:
#include <sys/times.h>
clock_t times(struct tms *buf)
Legge in buf il valore corrente dei tempi di processore.
La funzione ritorna il numero di clock tick dall’avvio del sistema in caso di successo e -1 in caso
di errore.
La funzione restituisce i valori di process time del processo corrente in una struttura di tipo
tms, la cui definizione è riportata in fig. 8.8. La struttura prevede quattro campi; i primi due,
tms_utime e tms_stime, sono l’user time ed il system time del processo, cos`ı come definiti in
sez. 8.4.1.
struct tms {
clock_t tms_utime; /* user time */
clock_t tms_stime; /* system time */
clock_t tms_cutime; /* user time of children */
clock_t tms_cstime; /* system time of children */
};
Figura 8.8: La struttura tms dei tempi di processore associati a un processo.
Gli altri due campi mantengono rispettivamente la somma dell’user time ed del system time
di tutti i processi figli che sono terminati; il kernel cioè somma in tms_cutime il valore di
29
le glibc seguono lo standard ANSI C, POSIX richiede che CLOCKS_PER_SEC sia definito pari a 1000000
indipendentemente dalla risoluzione del timer di sistema.

tms_utime e tms_cutime per ciascun figlio del quale è stato ricevuto lo stato di terminazione, e
lo stesso vale per tms_cstime.
Si tenga conto che l’aggiornamento di tms_cutime e tms_cstime viene eseguito solo quando
una chiamata a wait o waitpid è ritornata. Per questo motivo se un processo figlio termina
prima di ricevere lo stato di terminazione di tutti i suoi figli, questi processi“nipoti”non verranno
considerati nel calcolo di questi tempi.
8.4.3 Le funzioni per il calendar time
Come anticipato in sez. 8.4.1 il calendar time è mantenuto dal kernel in una variabile di tipo
time_t,30 che usualmente corrisponde ad un tipo elementare (in Linux è definito come long
int, che di norma corrisponde a 32 bit). Il valore corrente del calendar time, che indicheremo
come tempo di sistema, può essere ottenuto con la funzione time che lo restituisce nel suddetto
formato; il suo prototipo è:
#include <time.h>
time_t time(time_t *t)
Legge il valore corrente del calendar time.
La funzione ritorna il valore del calendar time in caso di successo e -1 in caso di errore, che può
essere solo EFAULT.
dove t, se non nullo, deve essere l’indirizzo di una variabile su cui duplicare il valore di ritorno.
Analoga a time è la funzione stime che serve per effettuare l’operazione inversa, e cioè per
impostare il tempo di sistema qualora questo sia necessario; il suo prototipo è:
#include <time.h>
int stime(time_t *t)
Imposta a t il valore corrente del calendar time.
La funzione ritorna 0 in caso di successo e -1 in caso di errore, che può essere EFAULT o EPERM.
dato che modificare l’ora ha un impatto su tutto il sistema il cambiamento dell’orologio è una
operazione privilegiata e questa funzione può essere usata solo da un processo con i privilegi di
amministratore, altrimenti la chiamata fallirà con un errore di EPERM.
Data la scarsa precisione nell’uso di time_t (che ha una risoluzione massima di un secondo)
quando si devono effettuare operazioni sui tempi di norma l’uso delle funzioni precedenti è
sconsigliato, ed esse sono di solito sostituite da gettimeofday e settimeofday,31 i cui prototipi
sono:
#include <time.h>
int gettimeofday(struct timeval *tv, struct timezone *tz)
Legge il tempo corrente del sistema.
int settimeofday(const struct timeval *tv, const struct timezone *tz)
Imposta il tempo di sistema.
Entrambe le funzioni restituiscono 0 in caso di successo e -1 in caso di errore, nel qual caso errno
può assumere i valori EINVAL EFAULT e per settimeofday anche EPERM.
Si noti come queste funzioni utilizzino per indicare il tempo una struttura di tipo timeval,
la cui definizione si è già vista in fig. 5.7, questa infatti permette una espressione alternativa dei
valori del calendar time, con una precisione, rispetto a time_t, fino al microsecondo.32
30
in realtà il kernel usa una rappresentazione interna di che fornisce una precisione molto maggiore, e consente
per questo anche di usare rappresentazioni diverse del calendar time.
31
le due funzioni time e stime sono più antiche e derivano da SVr4, gettimeofday e settimeofday sono state
introdotte da BSD, ed in BSD4.3 sono indicate come sostitute delle precedenti.
32
la precisione è solo teorica, la precisione reale della misura del tempo dell’orologio di sistema non dipende
dall’uso di queste strutture.

Come nel caso di stime anche settimeofday (la cosa continua a valere per qualunque funzio-
ne che vada a modificare l’orologio di sistema, quindi anche per quelle che tratteremo in seguito)
può essere utilizzata solo da un processo coi privilegi di amministratore.33
Il secondo argomento di entrambe le funzioni è una struttura timezone, che storicamente
veniva utilizzata per specificare appunto la time zone, cioè l’insieme del fuso orario e delle
convenzioni per l’ora legale che permettevano il passaggio dal tempo universale all’ora locale.
Questo argomento oggi è obsoleto ed in Linux non è mai stato utilizzato; esso non è supportato
né dalle vecchie libc5, né dalle glibc: pertanto quando si chiama questa funzione deve essere
sempre impostato a NULL.
Modificare l’orologio di sistema con queste funzioni è comunque problematico, in quanto
esse effettuano un cambiamento immediato. Questo può creare dei buchi o delle ripetizioni
nello scorrere dell’orologio di sistema, con conseguenze indesiderate. Ad esempio se si porta
avanti l’orologio si possono perdere delle esecuzioni di cron programmate nell’intervallo che si
è saltato. Oppure se si porta indietro l’orologio si possono eseguire due volte delle operazioni
previste nell’intervallo di tempo che viene ripetuto.
Per questo motivo la modalità più corretta per impostare l’ora è quella di usare la funzione
adjtime, il cui prototipo è:
int adjtime(const struct timeval *delta, struct timeval *olddelta)
Aggiusta del valore delta l’orologio di sistema.
il valore EPERM.
Questa funzione permette di avere un aggiustamento graduale del tempo di sistema in modo
che esso sia sempre crescente in maniera monotona. Il valore di delta esprime il valore di cui si
vuole spostare l’orologio; se è positivo l’orologio sarà accelerato per un certo tempo in modo da
guadagnare il tempo richiesto, altrimenti sarà rallentato. Il secondo argomento viene usato, se
non nullo, per ricevere il valore dell’ultimo aggiustamento effettuato.
struct timex {
unsigned int modes; /* mode selector */
long int offset; /* time offset (usec) */
long int freq; /* frequency offset (scaled ppm) */
long int maxerror; /* maximum error (usec) */
long int esterror; /* estimated error (usec) */
int status; /* clock command/status */
long int constant; /* pll time constant */
long int precision; /* clock precision (usec) (read only) */
long int tolerance; /* clock frequency tolerance (ppm) (read only) */
struct timeval time; /* (read only) */
long int tick; /* (modified) usecs between clock ticks */
long int ppsfreq; /* pps frequency (scaled ppm) (ro) */
long int jitter; /* pps jitter (us) (ro) */
int shift; /* interval duration (s) (shift) (ro) */
long int stabil; /* pps stability (scaled ppm) (ro) */
long int jitcnt; /* jitter limit exceeded (ro) */
long int calcnt; /* calibration intervals (ro) */
long int errcnt; /* calibration errors (ro) */
long int stbcnt; /* stability limit exceeded (ro) */
};
Figura 8.9: La struttura timex per il controllo dell’orologio di sistema.
33
più precisamente la capabitity CAP_SYS_TIME.

Linux poi prevede un’altra funzione, che consente un aggiustamento molto più dettagliato del
tempo, permettendo ad esempio anche di modificare anche la velocità dell’orologio di sistema.
La funzione è adjtimex ed il suo prototipo è:
#include <sys/timex.h>
int adjtimex(struct timex *buf)
Aggiusta del valore delta l’orologio di sistema.
La funzione restituisce lo stato dell’orologio (un valore > 0) in caso di successo e -1 in caso di
errore, nel qual caso errno assumerà i valori EFAULT, EINVAL ed EPERM.
La funzione richiede una struttura di tipo timex, la cui definizione, cos`ı come effettuata
in sys/timex.h, è riportata in fig. 8.9. L’azione della funzione dipende dal valore del campo
mode, che specifica quale parametro dell’orologio di sistema, specificato in un opportuno campo
di timex, deve essere impostato. Un valore nullo serve per leggere i parametri correnti; i valori
diversi da zero devono essere specificati come OR binario delle costanti riportate in tab. 8.13.
La funzione utilizza il meccanismo di David L. Mills, descritto nell’RFC 1305, che è alla base
del protocollo NTP. La funzione è specifica di Linux e non deve essere usata se la portabilità è un
requisito, le glibc provvedono anche un suo omonimo ntp_adjtime. La trattazione completa di
questa funzione necessita di una lettura approfondita del meccanismo descritto nell’RFC 1305,
ci limitiamo a descrivere in tab. 8.13 i principali valori utilizzabili per il campo mode, un elenco
più dettagliato del significato dei vari campi della struttura timex può essere ritrovato in [5].
Nome Valore Significato
ADJ_OFFSET 0x0001 Imposta la differenza fra il tempo reale e l’orologio di sistema:
deve essere indicata in microsecondi nel campo offset di
timex.
ADJ_FREQUENCY 0x0002 Imposta la differenze in frequenza fra il tempo reale e l’oro-
logio di sistema: deve essere indicata in parti per milione nel
campo frequency di timex.
ADJ_MAXERROR 0x0004 Imposta il valore massimo dell’errore sul tempo, espresso in
microsecondi nel campo maxerror di timex.
ADJ_ESTERROR 0x0008 Imposta la stima dell’errore sul tempo, espresso in
microsecondi nel campo esterror di timex.
ADJ_STATUS 0x0010 Imposta alcuni valori di stato interni usati dal sistema nella
gestione dell’orologio specificati nel campo status di timex.
ADJ_TIMECONST 0x0020 Imposta la larghezza di banda del PLL implementato dal
kernel, specificato nel campo constant di timex.
ADJ_TICK 0x4000 Imposta il valore dei tick del timer in microsecondi, espresso
nel campo tick di timex.
ADJ_OFFSET_SINGLESHOT 0x8001 Imposta uno spostamento una tantum dell’orologio secondo
il valore del campo offset simulando il comportamento di
adjtime.
Tabella 8.13: Costanti per l’assegnazione del valore del campo mode della struttura timex.
Il valore delle costanti per mode può essere anche espresso, secondo la sintassi specificata per
la forma equivalente di questa funzione definita come ntp_adjtime, utilizzando il prefisso MOD
al posto di ADJ.
La funzione ritorna un valore positivo che esprime lo stato dell’orologio di sistema; questo
può assumere i valori riportati in tab. 8.14. Un valore di -1 viene usato per riportare un errore;
al solito se si cercherà di modificare l’orologio di sistema (specificando un mode diverso da zero)
senza avere i privilegi di amministratore si otterrà un errore di EPERM.
8.4.4 La gestione delle date.
Le funzioni viste al paragrafo precedente sono molto utili per trattare le operazioni elementari sui
tempi, però le rappresentazioni del tempo ivi illustrate, se han senso per specificare un intervallo,

Nome Valore Significato
TIME_OK 0 L’orologio è sincronizzato.
TIME_INS 1 Insert leap second.
TIME_DEL 2 Delete leap second.
TIME_OOP 3 Leap second in progress.
TIME_WAIT 4 Leap second has occurred.
TIME_BAD 5 L’orologio non è sincronizzato.
Tabella 8.14: Possibili valori di ritorno di adjtimex.
non sono molto intuitive quando si deve esprimere un’ora o una data. Per questo motivo è stata
introdotta una ulteriore rappresentazione, detta broken-down time, che permette appunto di
suddividere il calendar time usuale in ore, minuti, secondi, ecc.
Questo viene effettuato attraverso una opportuna struttura tm, la cui definizione è riportata
in fig. 8.10, ed è in genere questa struttura che si utilizza quando si deve specificare un tempo
a partire dai dati naturali (ora e data), dato che essa consente anche di trattare la gestione del
fuso orario e dell’ora legale.34
Le funzioni per la gestione del broken-down time sono varie e vanno da quelle usate per
convertire gli altri formati in questo, usando o meno l’ora locale o il tempo universale, a quelle
per trasformare il valore di un tempo in una stringa contenente data ed ora, i loro prototipi
sono:
#include <time.h>
char *asctime(const struct tm *tm)
Produce una stringa con data e ora partendo da un valore espresso in broken-down time.
char *ctime(const time_t *timep)
Produce una stringa con data e ora partendo da un valore espresso in in formato time_t.
struct tm *gmtime(const time_t *timep)
Converte il calendar time dato in formato time_t in un broken-down time espresso in UTC.
struct tm *localtime(const time_t *timep)
Converte il calendar time dato in formato time_t in un broken-down time espresso nell’ora
locale.
time_t mktime(struct tm *tm)
Converte il broken-down time in formato time_t.
Tutte le funzioni restituiscono un puntatore al risultato in caso di successo e NULL in caso di errore,
tranne che mktime che restituisce direttamente il valore o -1 in caso di errore.
struct tm {
int tm_sec; /* seconds */
int tm_min; /* minutes */
int tm_hour; /* hours */
int tm_mday; /* day of the month */
int tm_mon; /* month */
int tm_year; /* year */
int tm_wday; /* day of the week */
int tm_yday; /* day in the year */
int tm_isdst; /* daylight saving time */
long int tm_gmtoff; /* Seconds east of UTC. */
const char *tm_zone; /* Timezone abbreviation. */
};
Figura 8.10: La struttura tm per una rappresentazione del tempo in termini di ora, minuti, secondi, ecc.
34
in realtà i due campi tm_gmtoff e tm_zone sono estensioni previste da BSD e dalle glibc, che, quando è definita
_BSD_SOURCE, hanno la forma in fig. 8.10.

Le prime due funzioni, asctime e ctime servono per poter stampare in forma leggibile un
tempo; esse restituiscono il puntatore ad una stringa, allocata staticamente, nella forma:
"Wed Jun 30 21:49:08 1993n"
e impostano anche la variabile tzname con l’informazione della time zone corrente; ctime è
banalmente definita in termini di asctime come asctime(localtime(t). Dato che l’uso di
una stringa statica rende le funzioni non rientranti POSIX.1c e SUSv2 prevedono due sostitute
rientranti, il cui nome è al solito ottenuto aggiungendo un _r, che prendono un secondo argomento
char *buf, in cui l’utente deve specificare il buffer su cui la stringa deve essere copiata (deve
essere di almeno 26 caratteri).
Le altre tre funzioni, gmtime, localtime e mktime servono per convertire il tempo dal formato
time_t a quello di tm e viceversa; gmtime effettua la conversione usando il tempo coordinato
universale (UTC), cioè l’ora di Greenwich; mentre localtime usa l’ora locale; mktime esegue la
conversione inversa.
Anche in questo caso le prime due funzioni restituiscono l’indirizzo di una struttura allocata
staticamente, per questo sono state definite anche altre due versioni rientranti (con la solita
estensione _r), che prevedono un secondo argomento struct tm *result, fornito dal chiamante,
che deve preallocare la struttura su cui sarà restituita la conversione.
Come mostrato in fig. 8.10 il broken-down time permette di tenere conto anche della differenza
fra tempo universale e ora locale, compresa l’eventuale ora legale. Questo viene fatto attraverso
le tre variabili globali mostrate in fig. 8.11, cui si accede quando si include time.h. Queste va-
riabili vengono impostate quando si chiama una delle precedenti funzioni di conversione, oppure
invocando direttamente la funzione tzset, il cui prototipo è:
#include <sys/timex.h>
void tzset(void)
Imposta le variabili globali della time zone.
La funzione non ritorna niente e non dà errori.
La funzione inizializza le variabili di fig. 8.11 a partire dal valore della variabile di ambiente
TZ, se quest’ultima non è definita verrà usato il file /etc/localtime.
extern char *tzname [2];
extern long timezone;
extern int daylight;
Figura 8.11: Le variabili globali usate per la gestione delle time zone.
La variabile tzname contiene due stringhe, che indicano i due nomi standard della time zone
corrente. La prima è il nome per l’ora solare, la seconda per l’ora legale.35 La variabile timezone
indica la differenza di fuso orario in secondi, mentre daylight indica se è attiva o meno l’ora
legale.
Benché la funzione asctime fornisca la modalità più immediata per stampare un tempo o
una data, la flessibilità non fa parte delle sue caratteristiche; quando si vuole poter stampare
solo una parte (l’ora, o il giorno) di un tempo si può ricorrere alla più sofisticata strftime, il
cui prototipo è:
#include <time.h>
size_t strftime(char *s, size_t max, const char *format, const struct tm *tm)
Stampa il tempo tm nella stringa s secondo il formato format.
La funzione ritorna il numero di caratteri stampati in s, altrimenti restituisce 0.
35
anche se sono indicati come char * non è il caso di modificare queste stringhe.

La funzione converte opportunamente il tempo tm in una stringa di testo da salvare in s,
purché essa sia di dimensione, indicata da size, sufficiente. I caratteri generati dalla funzione
vengono restituiti come valore di ritorno, ma non tengono conto del terminatore finale, che invece
viene considerato nel computo della dimensione; se quest’ultima è eccessiva viene restituito 0 e
lo stato di s è indefinito.
Modificatore Esempio Significato
%a Wed Nome del giorno, abbreviato.
%A Wednesday Nome del giorno, completo.
%b Apr Nome del mese, abbreviato.
%B April Nome del mese, completo.
%c Wed Apr 24 18:40:50 2002 Data e ora.
%d 24 Giorno del mese.
%H 18 Ora del giorno, da 0 a 24.
%I 06 Ora del giorno, da 0 a 12.
%j 114 Giorno dell’anno.
%m 04 Mese dell’anno.
%M 40 Minuto.
%p PM AM/PM.
%S 50 Secondo.
%U 16 Settimana dell’anno (partendo dalla dome-
nica).
%w 3 Giorno della settimana.
%W 16 Settimana dell’anno (partendo dal luned`ı).
%x 04/24/02 La data.
%X 18:40:50 L’ora.
%y 02 Anno nel secolo.
%Y 2002 Anno.
%Z CEST Nome della timezone.
%% % Il carattere %.
Tabella 8.15: Valori previsti dallo standard ANSI C per modificatore della stringa di formato di strftime.
Il risultato della funzione è controllato dalla stringa di formato format, tutti i caratteri
restano invariati eccetto % che viene utilizzato come modificatore; alcuni36 dei possibili valori
che esso può assumere sono riportati in tab. 8.15. La funzione tiene conto anche della presenza
di una localizzazione per stampare in maniera adeguata i vari nomi.
8.5 La gestione degli errori
In questa sezione esamineremo le caratteristiche principali della gestione degli errori in un sistema
unix-like. Infatti a parte il caso particolare di alcuni segnali (che tratteremo in cap. 9) in un
sistema unix-like il kernel non avvisa mai direttamente un processo dell’occorrenza di un errore
nell’esecuzione di una funzione, ma di norma questo viene riportato semplicemente usando un
opportuno valore di ritorno della funzione invocata. Inoltre il sistema di classificazione degli
errori è basato sull’architettura a processi, e presenta una serie di problemi nel caso lo si debba
usare con i thread.
8.5.1 La variabile errno
Quasi tutte le funzioni delle librerie del C sono in grado di individuare e riportare condizioni
di errore, ed è una norma fondamentale di buona programmazione controllare sempre che le
funzioni chiamate si siano concluse correttamente.
36
per la precisione quelli definiti dallo standard ANSI C, che sono anche quelli riportati da POSIX.1; le glibc
provvedono tutte le estensioni introdotte da POSIX.2 per il comando date, i valori introdotti da SVID3 e ulteriori
estensioni GNU; l’elenco completo dei possibili valori è riportato nella pagina di manuale della funzione.

8.5. LA GESTIONE DEGLI ERRORI 255
In genere le funzioni di libreria usano un valore speciale per indicare che c’è stato un errore.
Di solito questo valore è -1 o un puntatore nullo o la costante EOF (a seconda della funzione);
ma questo valore segnala solo che c’è stato un errore, non il tipo di errore.
Per riportare il tipo di errore il sistema usa la variabile globale errno,37 definita nell’hea-
der errno.h; la variabile è in genere definita come volatile dato che può essere cambiata in
modo asincrono da un segnale (si veda sez. 9.3.6 per un esempio, ricordando quanto trattato
in sez. 3.6.2), ma dato che un gestore di segnale scritto bene salva e ripristina il valore della
variabile, di questo non è necessario preoccuparsi nella programmazione normale.
I valori che può assumere errno sono riportati in app. C, nell’header errno.h sono anche
definiti i nomi simbolici per le costanti numeriche che identificano i vari errori; essi iniziano tutti
per E e si possono considerare come nomi riservati. In seguito faremo sempre riferimento a tali
valori, quando descriveremo i possibili errori restituiti dalle funzioni. Il programma di esempio
errcode stampa il codice relativo ad un valore numerico con l’opzione -l.
Il valore di errno viene sempre impostato a zero all’avvio di un programma, gran parte delle
funzioni di libreria impostano errno ad un valore diverso da zero in caso di errore. Il valore è
invece indefinito in caso di successo, perché anche se una funzione ha successo, può chiamarne
altre al suo interno che falliscono, modificando cos`ı errno.
Pertanto un valore non nullo di errno non è sintomo di errore (potrebbe essere il risultato di
un errore precedente) e non lo si può usare per determinare quando o se una chiamata a funzione
è fallita. La procedura da seguire è sempre quella di controllare errno immediatamente dopo
aver verificato il fallimento della funzione attraverso il suo codice di ritorno.
8.5.2 Le funzioni strerror e perror
Benché gli errori siano identificati univocamente dal valore numerico di errno le librerie provve-
dono alcune funzioni e variabili utili per riportare in opportuni messaggi le condizioni di errore
verificatesi. La prima funzione che si può usare per ricavare i messaggi di errore è strerror, il
cui prototipo è:
#include <string.h>
char *strerror(int errnum)
Restituisce una stringa con il messaggio di errore relativo ad errnum.
La funzione ritorna il puntatore ad una stringa di errore.
La funzione ritorna il puntatore alla stringa contenente il messaggio di errore corrispondente
al valore di errnum, se questo non è un valore valido verrà comunque restituita una stringa valida
contenente un messaggio che dice che l’errore è sconosciuto, e errno verrà modificata assumendo
il valore EINVAL.
In generale strerror viene usata passando errno come argomento, ed il valore di quest’ul-
tima non verrà modificato. La funzione inoltre tiene conto del valore della variabile di ambien-
te LC_MESSAGES per usare le appropriate traduzioni dei messaggi d’errore nella localizzazione
presente.
La funzione utilizza una stringa statica che non deve essere modificata dal programma; essa
è utilizzabile solo fino ad una chiamata successiva a strerror o perror, nessun’altra funzione di
libreria tocca questa stringa. In ogni caso l’uso di una stringa statica rende la funzione non rien-
trante, per cui nel caso si usino i thread le librerie forniscono38 una apposita versione rientrante
strerror_r, il cui prototipo è:
37
l’uso di una variabile globale può comportare alcuni problemi (ad esempio nel caso dei thread) ma lo standard
ISO C consente anche di definire errno come un modifiable lvalue, quindi si può anche usare una macro, e questo
è infatti il modo usato da Linux per renderla locale ai singoli thread.
38
questa funzione è la versione prevista dalle glibc, ed effettivamente definita in string.h, ne esiste una analoga
nello standard SUSv3 (quella riportata dalla pagina di manuale), che restituisce int al posto di char *, e che
tronca la stringa restituita a size.

#include <string.h>
char * strerror_r(int errnum, char *buf, size_t size)
Restituisce una stringa con il messaggio di errore relativo ad errnum.
La funzione restituisce l’indirizzo del messaggio in caso di successo e NULL in caso di errore; nel
qual caso errno assumerà i valori:
EINVAL si è specificato un valore di errnum non valido.
ERANGE la lunghezza di buf è insufficiente a contenere la stringa di errore.
La funzione è analoga a strerror ma restituisce la stringa di errore nel buffer buf che il
singolo thread deve allocare autonomamente per evitare i problemi connessi alla condivisione del
buffer statico. Il messaggio è copiato fino alla dimensione massima del buffer, specificata dal-
l’argomento size, che deve comprendere pure il carattere di terminazione; altrimenti la stringa
viene troncata.
Una seconda funzione usata per riportare i codici di errore in maniera automatizzata sullo
standard error (vedi sez. 6.1.2) è perror, il cui prototipo è:
#include <stdio.h>
void perror(const char *message)
Stampa il messaggio di errore relativo al valore corrente di errno sullo standard error;
preceduto dalla stringa message.
I messaggi di errore stampati sono gli stessi di strerror, (riportati in app. C), e, usando
il valore corrente di errno, si riferiscono all’ultimo errore avvenuto. La stringa specificata con
message viene stampato prima del messaggio d’errore, seguita dai due punti e da uno spazio, il
messaggio è terminato con un a capo.
Il messaggio può essere riportato anche usando le due variabili globali:
const char *sys_errlist [];
int sys_nerr;
dichiarate in errno.h. La prima contiene i puntatori alle stringhe di errore indicizzati da errno;
la seconda esprime il valore più alto per un codice di errore, l’utilizzo di questa stringa è
sostanzialmente equivalente a quello di strerror.
1 /* convert string to number */
2 err = strtol(argv[optind], NULL , 10);
3 /* testing error condition on conversion */
4 if (err== LONG_MIN) {
5 perror("Underflow on error code");
6 return 1;
7 } else if (err== LONG_MIN) {
8 perror("Overflow on error code");
9 return 1;
10 }
11 /* conversion is fine */
12 if (message) {
13 printf("Error message for %d is %sn", err , strerror(err ));
14 }
15 if (label) {
16 printf("Error label for %d is %sn", err , err_code[err ]);
17 }
Figura 8.12: Codice per la stampa del messaggio di errore standard.
In fig. 8.12 è riportata la sezione attinente del codice del programma errcode, che può essere
usato per stampare i messaggi di errore e le costanti usate per identificare i singoli errori; il

8.5. LA GESTIONE DEGLI ERRORI 257
sorgente completo del programma è allegato nel file ErrCode.c e contiene pure la gestione delle
opzioni e tutte le definizioni necessarie ad associare il valore numerico alla costante simbolica.
In particolare si è riportata la sezione che converte la stringa passata come argomento in un
intero (1-2), controllando con i valori di ritorno di strtol che la conversione sia avvenuta
correttamente (4-10), e poi stampa, a seconda dell’opzione scelta il messaggio di errore (11-14)
o la macro (15-17) associate a quel codice.
8.5.3 Alcune estensioni GNU
Le precedenti funzioni sono quelle definite ed usate nei vari standard; le glibc hanno però in-
trodotto una serie di estensioni “GNU” che forniscono alcune funzionalità aggiuntive per una
gestione degli errori semplificata e più efficiente.
La prima estensione consiste in due variabili, char * program_invocation_name e char *
program_invocation_short_name servono per ricavare il nome del programma; queste sono utili
quando si deve aggiungere il nome del programma (cosa comune quando si ha un programma che
non viene lanciato da linea di comando e salva gli errori in un file di log) al messaggio d’errore.
La prima contiene il nome usato per lanciare il programma (ed è equivalente ad argv[0]); la
seconda mantiene solo il nome del programma (senza eventuali directory in testa).
Uno dei problemi che si hanno con l’uso di perror è che non c’è flessibilità su quello che
si può aggiungere al messaggio di errore, che può essere solo una stringa. In molte occasioni
invece serve poter scrivere dei messaggi con maggiore informazione; ad esempio negli standard
di programmazione GNU si richiede che ogni messaggio di errore sia preceduto dal nome del
programma, ed in generale si può voler stampare il contenuto di qualche variabile; per questo le
glibc definiscono la funzione error, il cui prototipo è:
#include <stdio.h>
void error(int status, int errnum, const char *format, ...)
Stampa un messaggio di errore formattato.
La funzione non restituisce nulla e non riporta errori.
La funzione fa parte delle estensioni GNU per la gestione degli errori, l’argomento format
prende la stessa sintassi di printf, ed i relativi argomenti devono essere forniti allo stesso modo,
mentre errnum indica l’errore che si vuole segnalare (non viene quindi usato il valore corrente
di errno); la funzione stampa sullo standard error il nome del programma, come indicato dalla
variabile globale program_name, seguito da due punti ed uno spazio, poi dalla stringa generata
da format e dagli argomenti seguenti, seguita da due punti ed uno spazio infine il messaggio di
errore relativo ad errnum, il tutto è terminato da un a capo.
Il comportamento della funzione può essere ulteriormente controllato se si definisce una
variabile error_print_progname come puntatore ad una funzione void che restituisce void che
si incarichi di stampare il nome del programma.
L’argomento status può essere usato per terminare direttamente il programma in caso di
errore, nel qual caso error dopo la stampa del messaggio di errore chiama exit con questo stato
di uscita. Se invece il valore è nullo error ritorna normalmente ma viene incrementata un’altra
variabile globale, error_message_count, che tiene conto di quanti errori ci sono stati.
Un’altra funzione per la stampa degli errori, ancora più sofisticata, che prende due argomenti
aggiuntivi per indicare linea e file su cui è avvenuto l’errore è error_at_line; il suo prototipo
è:
#include <stdio.h>
void error_at_line(int status, int errnum, const char *fname, unsigned int
lineno, const char *format, ...)
Stampa un messaggio di errore formattato.
La funzione non restituisce nulla e non riporta errori.

ed il suo comportamento `e identico a quello di error se non per il fatto che, separati con il
solito due punti-spazio, vengono inseriti un nome di ﬁle indicato da fname ed un numero di
linea subito dopo la stampa del nome del programma. Inoltre essa usa un’altra variabile globale,
error_one_per_line, che impostata ad un valore diverso da zero fa si che errori relativi alla
stessa linea non vengano ripetuti.

Capitolo 9
I segnali
I segnali sono il primo e più semplice meccanismo di comunicazione nei confronti dei processi.
Nella loro versione originale essi portano con sé nessuna informazione che non sia il loro tipo; si
tratta in sostanza di un’interruzione software portata ad un processo.
In genere essi vengono usati dal kernel per riportare ai processi situazioni eccezionali (come
errori di accesso, eccezioni aritmetiche, ecc.) ma possono anche essere usati come forma elemen-
tare di comunicazione fra processi (ad esempio vengono usati per il controllo di sessione), per
notificare eventi (come la terminazione di un processo figlio), ecc.
In questo capitolo esamineremo i vari aspetti della gestione dei segnali, partendo da una
introduzione relativa ai concetti base con cui essi vengono realizzati, per poi affrontarne la
classificazione a secondo di uso e modalità di generazione fino ad esaminare in dettaglio le
funzioni e le metodologie di gestione avanzate e le estensioni fatte all’interfaccia classica nelle
nuovi versioni dello standard POSIX.
9.1 Introduzione
In questa sezione esamineremo i concetti generali relativi ai segnali, vedremo le loro caratteri-
stiche di base, introdurremo le nozioni di fondo relative all’architettura del funzionamento dei
segnali e alle modalità con cui il sistema gestisce l’interazione fra di essi ed i processi.
9.1.1 I concetti base
Come il nome stesso indica i segnali sono usati per notificare ad un processo l’occorrenza di un
qualche evento. Gli eventi che possono generare un segnale sono vari; un breve elenco di possibili
cause per l’emissione di un segnale è il seguente:
• un errore del programma, come una divisione per zero o un tentativo di accesso alla
memoria fuori dai limiti validi;
• la terminazione di un processo figlio;
• la scadenza di un timer o di un allarme;
• il tentativo di effettuare un’operazione di input/output che non può essere eseguita;
• una richiesta dell’utente di terminare o fermare il programma. In genere si realizza attra-
verso un segnale mandato dalla shell in corrispondenza della pressione di tasti del terminale
come C-c o C-z;1
• l’esecuzione di una kill o di una raise da parte del processo stesso o di un altro (solo
nel caso della kill).
1
indichiamo con C-x la pressione simultanea al tasto x del tasto control (ctrl in molte tastiere).
259

260 CAPITOLO 9. I SEGNALI
Ciascuno di questi eventi (compresi gli ultimi due che pure sono controllati dall’utente o da
un altro processo) comporta l’intervento diretto da parte del kernel che causa la generazione di
un particolare tipo di segnale.
Quando un processo riceve un segnale, invece del normale corso del programma, viene ese-
guita una azione predefinita o una apposita funzione di gestione (quello che da qui in avanti
chiameremo il gestore del segnale, dall’inglese signal handler) che può essere stata specificata
dall’utente (nel qual caso si dice che si intercetta il segnale).
9.1.2 Le semantiche del funzionamento dei segnali
Negli anni il comportamento del sistema in risposta ai segnali è stato modificato in vari modi
nelle differenti implementazioni di Unix. Si possono individuare due tipologie fondamentali di
comportamento dei segnali (dette semantiche) che vengono chiamate rispettivamente semantica
affidabile (o reliable) e semantica inaffidabile (o unreliable).
Nella semantica inaffidabile (quella implementata dalle prime versioni di Unix) la funzione
di gestione del segnale specificata dall’utente non resta attiva una volta che è stata eseguita;
è perciò compito dell’utente stesso ripetere l’installazione all’interno del gestore del segnale, in
tutti quei casi in cui si vuole che esso resti attivo.
In questo caso è possibile una situazione in cui i segnali possono essere perduti. Si consideri il
segmento di codice riportato in fig. 9.1, nel programma principale viene installato un gestore (5),
ed in quest’ultimo la prima operazione (11) è quella di reinstallare se stesso. Se nell’esecuzione
del gestore un secondo segnale arriva prima che esso abbia potuto eseguire la reinstallazione,
verrà eseguito il comportamento predefinito assegnato al segnale stesso, il che può comportare, a
seconda dei casi, che il segnale viene perso (se l’impostazione predefinita era quello di ignorarlo)
o la terminazione immediata del processo; in entrambi i casi l’azione prevista non verrà eseguita.
1 int sig_handler (); /* handler function */
2 int main ()
3 {
4 ...
5 signal(SIGINT , sig_handler ); /* establish handler */
6 ...
7 }
8
9 int sig_handler ()
10 {
11 signal(SIGINT , sig_handler ); /* restablish handler */
12 ... /* process signal */
13 }
Figura 9.1: Esempio di codice di un gestore di segnale per la semantica inaffidabile.
Questa è la ragione per cui l’implementazione dei segnali secondo questa semantica viene
chiamata inaffidabile; infatti la ricezione del segnale e la reinstallazione del suo gestore non sono
operazioni atomiche, e sono sempre possibili delle race condition (sull’argomento vedi quanto
detto in sez. 3.6).
Un altro problema è che in questa semantica non esiste un modo per bloccare i segnali quando
non si vuole che arrivino; i processi possono ignorare il segnale, ma non è possibile istruire il
sistema a non fare nulla in occasione di un segnale, pur mantenendo memoria del fatto che è
avvenuto.
Nella semantica affidabile (quella utilizzata da Linux e da ogni Unix moderno) il gestore
una volta installato resta attivo e non si hanno tutti i problemi precedenti. In questa semantica

9.1. INTRODUZIONE 261
i segnali vengono generati dal kernel per un processo all’occorrenza dell’evento che causa il
segnale. In genere questo viene fatto dal kernel impostando l’apposito campo della task_struct
del processo nella process table (si veda fig. 3.2).
Si dice che il segnale viene consegnato al processo (dall’inglese delivered) quando viene ese-
guita l’azione per esso prevista, mentre per tutto il tempo che passa fra la generazione del segnale
e la sua consegna esso è detto pendente (o pending). In genere questa procedura viene effettuata
dallo scheduler quando, riprendendo l’esecuzione del processo in questione, verifica la presenza
del segnale nella task_struct e mette in esecuzione il gestore.
In questa semantica un processo ha la possibilità di bloccare la consegna dei segnali, in questo
caso, se l’azione per il suddetto segnale non è quella di ignorarlo, il segnale resta pendente fintanto
che il processo non lo sblocca (nel qual caso viene consegnato) o imposta l’azione corrispondente
per ignorarlo.
Si tenga presente che il kernel stabilisce cosa fare con un segnale che è stato bloccato al
momento della consegna, non quando viene generato; questo consente di cambiare l’azione per il
segnale prima che esso venga consegnato, e si può usare la funzione sigpending (vedi sez. 9.4.4)
per determinare quali segnali sono bloccati e quali sono pendenti.
9.1.3 Tipi di segnali
In generale gli eventi che generano segnali si possono dividere in tre categorie principali: errori,
eventi esterni e richieste esplicite.
Un errore significa che un programma ha fatto qualcosa di sbagliato e non può continuare
ad essere eseguito. Non tutti gli errori causano dei segnali, in genere le condizioni di errore più
comuni comportano la restituzione di un codice di errore da parte di una funzione di libreria; sono
gli errori che possono avvenire nella esecuzione delle istruzioni di un programma che causano
l’emissione di un segnale, come le divisioni per zero o l’uso di indirizzi di memoria non validi.
Un evento esterno ha in genere a che fare con l’I/O o con altri processi; esempi di segnali di
questo tipo sono quelli legati all’arrivo di dati di input, scadenze di un timer, terminazione di
processi figli.
Una richiesta esplicita significa l’uso di una chiamata di sistema (come kill o raise) per la
generazione di un segnale, cosa che viene fatta usualmente dalla shell quando l’utente invoca la
sequenza di tasti di stop o di suspend, ma può essere pure inserita all’interno di un programma.
Si dice poi che i segnali possono essere asincroni o sincroni. Un segnale sincrono è legato ad
una azione specifica di un programma ed è inviato (a meno che non sia bloccato) durante tale
azione; molti errori generano segnali sincroni, cos`ı come la richiesta esplicita da parte del processo
tramite le chiamate al sistema. Alcuni errori come la divisione per zero non sono completamente
sincroni e possono arrivare dopo qualche istruzione.
I segnali asincroni sono generati da eventi fuori dal controllo del processo che li riceve, e
arrivano in tempi impredicibili nel corso dell’esecuzione del programma. Eventi esterni come la
terminazione di un processo figlio generano segnali asincroni, cos`ı come le richieste di generazione
di un segnale effettuate da altri processi.
In generale un tipo di segnale o è sincrono o è asincrono, salvo il caso in cui esso sia generato
attraverso una richiesta esplicita tramite chiamata al sistema, nel qual caso qualunque tipo
di segnale (quello scelto nella chiamata) può diventare sincrono o asincrono a seconda che sia
generato internamente o esternamente al processo.
9.1.4 La notifica dei segnali
Come accennato quando un segnale viene generato, se la sua azione predefinita non è quella di
essere ignorato, il kernel prende nota del fatto nella task_struct del processo; si dice cos`ı che

il segnale diventa pendente (o pending), e rimane tale fino al momento in cui verrà notificato al
processo (o verrà specificata come azione quella di ignorarlo).
Normalmente l’invio al processo che deve ricevere il segnale è immediato ed avviene non
appena questo viene rimesso in esecuzione dallo scheduler che esegue l’azione specificata. Questo
a meno che il segnale in questione non sia stato bloccato prima della notifica, nel qual caso
l’invio non avviene ed il segnale resta pendente indefinitamente. Quando lo si sblocca il segnale
pendente sarà subito notificato. Si tenga presente però che i segnali pendenti non si accodano,
alla generazione infatti il kernel marca un flag nella task_struct del processo, per cui se prima
della notifica ne vengono generati altri il flag è comunque marcato, ed il gestore viene eseguito
sempre una sola volta.
Si ricordi però che se l’azione specificata per un segnale è quella di essere ignorato questo sarà
scartato immediatamente al momento della sua generazione, e questo anche se in quel momento
il segnale è bloccato (perché bloccare su un segnale significa bloccarne la notifica). Per questo
motivo un segnale, fintanto che viene ignorato, non sarà mai notificato, anche se prima è stato
bloccato ed in seguito si è specificata una azione diversa (nel qual caso solo i segnali successivi
alla nuova specificazione saranno notificati).
Una volta che un segnale viene notificato (che questo avvenga subito o dopo una attesa più
o meno lunga) viene eseguita l’azione specificata per il segnale. Per alcuni segnali (SIGKILL e
SIGSTOP) questa azione è fissa e non può essere cambiata, ma per tutti gli altri si può selezionare
una delle tre possibilità seguenti:
• ignorare il segnale;
• catturare il segnale, ed utilizzare il gestore specificato;
• accettare l’azione predefinita per quel segnale.
Un programma può specificare queste scelte usando le due funzioni signal e sigaction
(vedi sez. 9.3.2 e sez. 9.4.3). Se si è installato un gestore sarà quest’ultimo ad essere eseguito alla
notifica del segnale. Inoltre il sistema farà si che mentre viene eseguito il gestore di un segnale,
quest’ultimo venga automaticamente bloccato (cos`ı si possono evitare race condition).
Nel caso non sia stata specificata un’azione, viene utilizzata l’azione standard che (come
vedremo in sez. 9.2.1) è propria di ciascun segnale; nella maggior parte dei casi essa porta alla
terminazione del processo, ma alcuni segnali che rappresentano eventi innocui vengono ignorati.
Quando un segnale termina un processo, il padre può determinare la causa della terminazione
esaminando il codice di stato riportato dalle funzioni wait e waitpid (vedi sez. 3.2.4); questo
è il modo in cui la shell determina i motivi della terminazione di un programma e scrive un
eventuale messaggio di errore.
I segnali che rappresentano errori del programma (divisione per zero o violazioni di accesso)
hanno anche la caratteristica di scrivere un file di core dump che registra lo stato del processo
(ed in particolare della memoria e dello stack) prima della terminazione. Questo può essere
esaminato in seguito con un debugger per investigare sulla causa dell’errore. Lo stesso avviene
se i suddetti segnali vengono generati con una kill.
9.2 La classificazione dei segnali
Esamineremo in questa sezione quali sono i vari segnali definiti nel sistema, le loro caratteristiche
e tipologia, le varie macro e costanti che permettono di identificarli, e le funzioni che ne stampano
la descrizione.
9.2.1 I segnali standard
Ciascun segnale è identificato rispetto al sistema da un numero, ma l’uso diretto di questo numero
da parte dei programmi è da evitare, in quanto esso può variare a seconda dell’implementazione

9.2. LA CLASSIFICAZIONE DEI SEGNALI 263
del sistema, e nel caso di Linux, anche a seconda dell’architettura hardware. Per questo motivo
ad ogni segnale viene associato un nome, definendo con una macro di preprocessore una costante
uguale al suddetto numero. Sono questi nomi, che sono standardizzati e sostanzialmente uniformi
rispetto alle varie implementazioni, che si devono usare nei programmi. Tutti i nomi e le funzioni
che concernono i segnali sono definiti nell’header di sistema signal.h.
Il numero totale di segnali presenti è dato dalla macro NSIG, e dato che i numeri dei segnali
sono allocati progressivamente, essa corrisponde anche al successivo del valore numerico asse-
gnato all’ultimo segnale definito. In tab. 9.3 si è riportato l’elenco completo dei segnali definiti
in Linux (estratto dalle pagine di manuale), comparati con quelli definiti in vari standard.
Sigla Significato
A L’azione predefinita è terminare il processo.
B L’azione predefinita è ignorare il segnale.
C L’azione predefinita è terminare il processo e scrivere un
core dump.
D L’azione predefinita è fermare il processo.
E Il segnale non può essere intercettato.
F Il segnale non può essere ignorato.
Tabella 9.1: Legenda delle azioni predefinite dei segnali riportate in tab. 9.3.
In tab. 9.3 si sono anche riportate le azioni predefinite di ciascun segnale (riassunte con delle
lettere, la cui legenda completa è in tab. 9.1), quando nessun gestore è installato un segnale può
essere ignorato o causare la terminazione del processo. Nella colonna standard sono stati indicati
anche gli standard in cui ciascun segnale è definito, secondo lo schema di tab. 9.2.
Sigla Standard
P POSIX
B BSD
L Linux
S SUSv2
Tabella 9.2: Legenda dei valori della colonna Standard di tab. 9.3.
In alcuni casi alla terminazione del processo è associata la creazione di un file (posto nella
directory corrente del processo e chiamato core) su cui viene salvata un’immagine della memoria
del processo (il cosiddetto core dump), che può essere usata da un debugger per esaminare lo
stato dello stack e delle variabili al momento della ricezione del segnale.
La descrizione dettagliata del significato dei vari segnali, raggruppati per tipologia, verrà
affrontata nei paragrafi successivi.
9.2.2 Segnali di errore di programma
Questi segnali sono generati quando il sistema, o in certi casi direttamente l’hardware (come
per i page fault non validi) rileva un qualche errore insanabile nel programma in esecuzione.
In generale la generazione di questi segnali significa che il programma ha dei gravi problemi
(ad esempio ha dereferenziato un puntatore non valido o ha eseguito una operazione aritmetica
proibita) e l’esecuzione non può essere proseguita.
In genere si intercettano questi segnali per permettere al programma di terminare in maniera
pulita, ad esempio per ripristinare le impostazioni della console o eliminare i file di lock prima
dell’uscita. In questo caso il gestore deve concludersi ripristinando l’azione predefinita e rialzando
il segnale, in questo modo il programma si concluderà senza effetti spiacevoli, ma riportando lo
stesso stato di uscita che avrebbe avuto se il gestore non ci fosse stato.
L’azione predefinita per tutti questi segnali è causare la terminazione del processo che li ha
causati. In genere oltre a questo il segnale provoca pure la registrazione su disco di un file di

Segnale Standard Azione Descrizione
SIGHUP PL A Hangup o terminazione del processo di controllo.
SIGINT PL A Interrupt da tastiera (C-c).
SIGQUIT PL C Quit da tastiera (C-y).
SIGILL PL C Istruzione illecita.
SIGABRT PL C Segnale di abort da abort.
SIGFPE PL C Errore aritmetico.
SIGKILL PL AEF Segnale di terminazione forzata.
SIGSEGV PL C Errore di accesso in memoria.
SIGPIPE PL A Pipe spezzata.
SIGALRM PL A Segnale del timer da alarm.
SIGTERM PL A Segnale di terminazione C-.
SIGUSR1 PL A Segnale utente numero 1.
SIGUSR2 PL A Segnale utente numero 2.
SIGCHLD PL B Figlio terminato o fermato.
SIGCONT PL Continua se fermato.
SIGSTOP PL DEF Ferma il processo.
SIGTSTP PL D Pressione del tasto di stop sul terminale.
SIGTTIN PL D Input sul terminale per un processo in background.
SIGTTOU PL D Output sul terminale per un processo in background.
SIGBUS SL C Errore sul bus (bad memory access).
SIGPOLL SL A Pollable event (Sys V); Sinonimo di SIGIO.
SIGPROF SL A Timer del profiling scaduto.
SIGSYS SL C Argomento sbagliato per una subroutine (SVID).
SIGTRAP SL C Trappole per un Trace/breakpoint.
SIGURG SLB B Ricezione di una urgent condition su un socket.
SIGVTALRM SLB A Timer di esecuzione scaduto.
SIGXCPU SLB C Ecceduto il limite sul tempo di CPU.
SIGXFSZ SLB C Ecceduto il limite sulla dimensione dei file.
SIGIOT L C IOT trap. Sinonimo di SIGABRT.
SIGEMT L
SIGSTKFLT L A Errore sullo stack del coprocessore.
SIGIO LB A L’I/O è possibile (4.2 BSD).
SIGCLD L Sinonimo di SIGCHLD.
SIGPWR L A Fallimento dell’alimentazione.
SIGINFO L Sinonimo di SIGPWR.
SIGLOST L A Perso un lock sul file (per NFS).
SIGWINCH LB B Finestra ridimensionata (4.3 BSD, Sun).
SIGUNUSED L A Segnale inutilizzato (diventerà SIGSYS).
Tabella 9.3: Lista dei segnali in Linux.
core dump che viene scritto in un file core nella directory corrente del processo al momento
dell’errore, che il debugger può usare per ricostruire lo stato del programma al momento della
terminazione. Questi segnali sono:
SIGFPE Riporta un errore aritmetico fatale. Benché il nome derivi da floating point exception
si applica a tutti gli errori aritmetici compresa la divisione per zero e l’overflow.
Se il gestore ritorna il comportamento del processo è indefinito, ed ignorare questo
segnale può condurre ad un ciclo infinito.
SIGILL Il nome deriva da illegal instruction, significa che il programma sta cercando di
eseguire una istruzione privilegiata o inesistente, in generale del codice illecito.
Poiché il compilatore del C genera del codice valido si ottiene questo segnale se
il file eseguibile è corrotto o si stanno cercando di eseguire dei dati. Quest’ultimo
caso può accadere quando si passa un puntatore sbagliato al posto di un puntatore
a funzione, o si eccede la scrittura di un vettore di una variabile locale, andando a
corrompere lo stack. Lo stesso segnale viene generato in caso di overflow dello stack

o di problemi nell’esecuzione di un gestore. Se il gestore ritorna il comportamento
del processo è indefinito.
SIGSEGV Il nome deriva da segment violation, e significa che il programma sta cercando
di leggere o scrivere in una zona di memoria protetta al di fuori di quella che
gli è stata riservata dal sistema. In genere è il meccanismo della protezione della
memoria che si accorge dell’errore ed il kernel genera il segnale. Se il gestore ritorna
il comportamento del processo è indefinito.
È tipico ottenere questo segnale dereferenziando un puntatore nullo o non inizia-
lizzato leggendo al di là della fine di un vettore.
SIGBUS Il nome deriva da bus error. Come SIGSEGV questo è un segnale che viene generato
di solito quando si dereferenzia un puntatore non inizializzato, la differenza è che
SIGSEGV indica un accesso non permesso su un indirizzo esistente (tipo fuori dallo
heap o dallo stack), mentre SIGBUS indica l’accesso ad un indirizzo non valido,
come nel caso di un puntatore non allineato.
SIGABRT Il nome deriva da abort. Il segnale indica che il programma stesso ha rilevato un
errore che viene riportato chiamando la funzione abort che genera questo segnale.
SIGTRAP È il segnale generato da un’istruzione di breakpoint o dall’attivazione del traccia-
mento per il processo. È usato dai programmi per il debugging e un programma
normale non dovrebbe ricevere questo segnale.
SIGSYS Sta ad indicare che si è eseguita una istruzione che richiede l’esecuzione di una
system call, ma si è fornito un codice sbagliato per quest’ultima.
9.2.3 I segnali di terminazione
Questo tipo di segnali sono usati per terminare un processo; hanno vari nomi a causa del differente
uso che se ne può fare, ed i programmi possono trattarli in maniera differente.
La ragione per cui può essere necessario trattare questi segnali è che il programma può
dover eseguire una serie di azioni di pulizia prima di terminare, come salvare informazioni sullo
stato in cui si trova, cancellare file temporanei, o ripristinare delle condizioni alterate durante il
funzionamento (come il modo del terminale o le impostazioni di una qualche periferica).
L’azione predefinita di questi segnali è di terminare il processo, questi segnali sono:
SIGTERM Il nome sta per terminate. È un segnale generico usato per causare la conclusione di
un programma. Al contrario di SIGKILL può essere intercettato, ignorato, bloccato.
In genere lo si usa per chiedere in maniera “educata” ad un processo di concludersi.
SIGINT Il nome sta per interrupt. È il segnale di interruzione per il programma. È quello che
viene generato di default dal comando kill o dall’invio sul terminale del carattere
di controllo INTR (interrupt, generato dalla sequenza C-c).
SIGQUIT È analogo a SIGINT con la differenza che è controllato da un altro carattere di con-
trollo, QUIT, corrispondente alla sequenza C-. A differenza del precedente l’azione
predefinita, oltre alla terminazione del processo, comporta anche la creazione di un
core dump.
In genere lo si può pensare come corrispondente ad una condizione di errore del
programma rilevata dall’utente. Per questo motivo non è opportuno fare eseguire
al gestore di questo segnale le operazioni di pulizia normalmente previste (tipo
la cancellazione di file temporanei), dato che in certi casi esse possono eliminare
informazioni utili nell’esame dei core dump.

SIGKILL Il nome è utilizzato per terminare in maniera immediata qualunque programma.
Questo segnale non può essere né intercettato, né ignorato, né bloccato, per cui
causa comunque la terminazione del processo. In genere esso viene generato solo
per richiesta esplicita dell’utente dal comando (o tramite la funzione) kill. Dato
che non lo si può intercettare è sempre meglio usarlo come ultima risorsa quando
metodi meno brutali, come SIGTERM o C-c non funzionano.
Se un processo non risponde a nessun altro segnale SIGKILL ne causa sempre la
terminazione (in effetti il fallimento della terminazione di un processo da parte di
SIGKILL costituirebbe un malfunzionamento del kernel). Talvolta è il sistema stesso
che può generare questo segnale quando per condizioni particolari il processo non
può più essere eseguito neanche per eseguire un gestore.
SIGHUP Il nome sta per hang-up. Segnala che il terminale dell’utente si è disconnesso (ad
esempio perché si è interrotta la rete). Viene usato anche per riportare la termina-
zione del processo di controllo di un terminale a tutti i processi della sessione, in
modo che essi possano disconnettersi dal relativo terminale.
Viene inoltre usato in genere per segnalare ai demoni (che non hanno un terminale
di controllo) la necessità di reinizializzarsi e rileggere il/i file di configurazione.
9.2.4 I segnali di allarme
Questi segnali sono generati dalla scadenza di un timer (vedi sez. 9.3.4). Il loro comportamento
predefinito è quello di causare la terminazione del programma, ma con questi segnali la scelta
predefinita è irrilevante, in quanto il loro uso presuppone sempre la necessità di un gestore.
Questi segnali sono:
SIGALRM Il nome sta per alarm. Segnale la scadenza di un timer misurato sul tempo reale o
sull’orologio di sistema. È normalmente usato dalla funzione alarm.
SIVGTALRM Il nome sta per virtual alarm. È analogo al precedente ma segnala la scadenza di
un timer sul tempo di CPU usato dal processo.
SIGPROF Il nome sta per profiling. Indica la scadenza di un timer che misura sia il tempo
di CPU speso direttamente dal processo che quello che il sistema ha speso per
conto di quest’ultimo. In genere viene usato dagli strumenti che servono a fare la
profilazione dell’utilizzo del tempo di CPU da parte del processo.
9.2.5 I segnali di I/O asincrono
Questi segnali operano in congiunzione con le funzioni di I/O asincrono. Per questo occorre co-
munque usare fcntl per abilitare un file descriptor a generare questi segnali. L’azione predefinita
è di essere ignorati. Questi segnali sono:
SIGIO Questo segnale viene inviato quando un file descriptor è pronto per eseguire del-
l’input/output. In molti sistemi solo i socket e i terminali possono generare questo
segnale, in Linux questo può essere usato anche per i file, posto che la fcntl abbia
avuto successo.
SIGURG Questo segnale è inviato quando arrivano dei dati urgenti o out-of-band su di un
socket; per maggiori dettagli al proposito si veda sez. 19.1.3.
SIGPOLL Questo segnale è equivalente a SIGIO, è definito solo per compatibilità con i sistemi
System V.

9.2.6 I segnali per il controllo di sessione
Questi sono i segnali usati dal controllo delle sessioni e dei processi, il loro uso è specializzato e
viene trattato in maniera specifica nelle sezioni in cui si trattano gli argomenti relativi. Questi
segnali sono:
SIGCHLD Questo è il segnale mandato al processo padre quando un figlio termina o viene
fermato. L’azione predefinita è di ignorare il segnale, la sua gestione è trattata in
sez. 3.2.4.
SIGCLD Per Linux questo è solo un segnale identico al precedente, il nome è obsoleto e
andrebbe evitato.
SIGCONT Il nome sta per continue. Il segnale viene usato per fare ripartire un programma
precedentemente fermato da SIGSTOP. Questo segnale ha un comportamento spe-
ciale, e fa sempre ripartire il processo prima della sua consegna. Il comportamento
predefinito è di fare solo questo; il segnale non può essere bloccato. Si può anche
installare un gestore, ma il segnale provoca comunque il riavvio del processo.
La maggior pare dei programmi non hanno necessità di intercettare il segnale, in
quanto esso è completamente trasparente rispetto all’esecuzione che riparte senza
che il programma noti niente. Si possono installare dei gestori per far si che un
programma produca una qualche azione speciale se viene fermato e riavviato, come
per esempio riscrivere un prompt, o inviare un avviso.
SIGSTOP Il segnale ferma un processo (lo porta cioè in uno stato di sleep, vedi sez. 3.4.1); il
segnale non può essere né intercettato, né ignorato, né bloccato.
SIGTSTP Il nome sta per interactive stop. Il segnale ferma il processo interattivamente, ed
è generato dal carattere SUSP (prodotto dalla combinazione C-z), ed al contrario
di SIGSTOP può essere intercettato e ignorato. In genere un programma installa un
gestore per questo segnale quando vuole lasciare il sistema o il terminale in uno
stato definito prima di fermarsi; se per esempio un programma ha disabilitato l’eco
sul terminale può installare un gestore per riabilitarlo prima di fermarsi.
SIGTTIN Un processo non può leggere dal terminale se esegue una sessione di lavoro in
background. Quando un processo in background tenta di leggere da un terminale
viene inviato questo segnale a tutti i processi della sessione di lavoro. L’azione
predefinita è di fermare il processo. L’argomento è trattato in sez. 10.1.1.
SIGTTOU Segnale analogo al precedente SIGTTIN, ma generato quando si tenta di scrivere o
modificare uno dei modi del terminale. L’azione predefinita è di fermare il processo,
l’argomento è trattato in sez. 10.1.1.
9.2.7 I segnali di operazioni errate
Questi segnali sono usati per riportare al programma errori generati da operazioni da lui eseguite;
non indicano errori del programma quanto errori che impediscono il completamento dell’esecu-
zione dovute all’interazione con il resto del sistema. L’azione predefinita di questi segnali è di
terminare il processo, questi segnali sono:
SIGPIPE Sta per Broken pipe. Se si usano delle pipe, (o delle FIFO o dei socket) è necessario,
prima che un processo inizi a scrivere su una di esse, che un altro l’abbia aperta
in lettura (si veda sez. 11.1.1). Se il processo in lettura non è partito o è termina-
to inavvertitamente alla scrittura sulla pipe il kernel genera questo segnale. Se il

segnale è bloccato, intercettato o ignorato la chiamata che lo ha causato fallisce,
restituendo l’errore EPIPE.
SIGLOST Sta per Resource lost. Tradizionalmente è il segnale che viene generato quando si
perde un advisory lock su un file su NFS perché il server NFS è stato riavviato. Il
progetto GNU lo utilizza per indicare ad un client il crollo inaspettato di un server.
In Linux è definito come sinonimo di SIGIO.2
SIGXCPU Sta per CPU time limit exceeded. Questo segnale è generato quando un processo
eccede il limite impostato per il tempo di CPU disponibile, vedi sez. 8.3.2.
SIGXFSZ Sta per File size limit exceeded. Questo segnale è generato quando un processo
tenta di estendere un file oltre le dimensioni specificate dal limite impostato per le
dimensioni massime di un file, vedi sez. 8.3.2.
9.2.8 Ulteriori segnali
Raccogliamo qui infine una serie di segnali che hanno scopi differenti non classificabili in maniera
omogenea. Questi segnali sono:
SIGUSR1 Insieme a SIGUSR2 è un segnale a disposizione dell’utente che lo può usare per
quello che vuole. Viene generato solo attraverso l’invocazione della funzione kill.
Entrambi i segnali possono essere utili per implementare una comunicazione ele-
mentare fra processi diversi, o per eseguire a richiesta una operazione utilizzando
un gestore. L’azione predefinita è di terminare il processo.
SIGUSR2 È il secondo segnale a disposizione degli utenti. Vedi quanto appena detto per
SIGUSR1.
SIGWINCH Il nome sta per window (size) change e viene generato in molti sistemi (GNU/Li-
nux compreso) quando le dimensioni (in righe e colonne) di un terminale vengono
cambiate. Viene usato da alcuni programmi testuali per riformattare l’uscita su
schermo quando si cambia dimensione a quest’ultimo. L’azione predefinita è di
essere ignorato.
SIGINFO Il segnale indica una richiesta di informazioni. È usato con il controllo di sessione,
causa la stampa di informazioni da parte del processo leader del gruppo associato
al terminale di controllo, gli altri processi lo ignorano.
9.2.9 Le funzioni strsignal e psignal
Per la descrizione dei segnali il sistema mette a disposizione due funzioni che stampano un
messaggio di descrizione dato il numero. In genere si usano quando si vuole notificare all’utente
il segnale ricevuto (nel caso di terminazione di un processo figlio o di un gestore che gestisce
più segnali); la prima funzione, strsignal, è una estensione GNU, accessibile avendo definito
_GNU_SOURCE, ed è analoga alla funzione strerror (si veda sez. 8.5.2) per gli errori:
#include <string.h>
char *strsignal(int signum)
Ritorna il puntatore ad una stringa che contiene la descrizione del segnale signum.
dato che la stringa è allocata staticamente non se ne deve modificare il contenuto, che resta
valido solo fino alla successiva chiamata di strsignal. Nel caso si debba mantenere traccia del
messaggio sarà necessario copiarlo.
2
ed è segnalato come BUG nella pagina di manuale.

9.3. LA GESTIONE DI BASE DEI SEGNALI 269
La seconda funzione, psignal, deriva da BSD ed è analoga alla funzione perror descritta
sempre in sez. 8.5.2; il suo prototipo è:
#include <signal.h>
void psignal(int sig, const char *s)
Stampa sullo standard error un messaggio costituito dalla stringa s, seguita da due punti
ed una descrizione del segnale indicato da sig.
Una modalità alternativa per utilizzare le descrizioni restituite da strsignal e psignal è
quello di usare la variabile sys_siglist, che è definita in signal.h e può essere acceduta con
la dichiarazione:
extern const char *const sys_siglist [];
L’array sys_siglist contiene i puntatori alle stringhe di descrizione, indicizzate per numero
di segnale, per cui una chiamata del tipo di char *decr = strsignal(SIGINT) può essere
sostituita dall’equivalente char *decr = sys_siglist[SIGINT].
9.3 La gestione di base dei segnali
I segnali sono il primo e più classico esempio di eventi asincroni, cioè di eventi che possono
accadere in un qualunque momento durante l’esecuzione di un programma. Per questa loro
caratteristica la loro gestione non può essere effettuata all’interno del normale flusso di esecuzione
dello stesso, ma è delegata appunto agli eventuali gestori che si sono installati.
In questa sezione vedremo come si effettua la gestione dei segnali, a partire dalla loro inte-
razione con le system call, passando per le varie funzioni che permettono di installare i gestori
e controllare le reazioni di un processo alla loro occorrenza.
9.3.1 Il comportamento generale del sistema
Abbiamo già trattato in sez. 9.1 le modalità con cui il sistema gestisce l’interazione fra segnali
e processi, ci resta da esaminare però il comportamento delle system call; in particolare due di
esse, fork ed exec, dovranno essere prese esplicitamente in considerazione, data la loro stretta
relazione con la creazione di nuovi processi.
Come accennato in sez. 3.2.2 quando viene creato un nuovo processo esso eredita dal padre
sia le azioni che sono state impostate per i singoli segnali, che la maschera dei segnali bloccati
(vedi sez. 9.4.4). Invece tutti i segnali pendenti e gli allarmi vengono cancellati; essi infatti devono
essere recapitati solo al padre, al figlio dovranno arrivare solo i segnali dovuti alle sue azioni.
Quando si mette in esecuzione un nuovo programma con exec (si ricordi quanto detto in
sez. 3.2.5) tutti i segnali per i quali è stato installato un gestore vengono reimpostati a SIG_DFL.
Non ha più senso infatti fare riferimento a funzioni definite nel programma originario, che non
sono presenti nello spazio di indirizzi del nuovo programma.
Si noti che questo vale solo per le azioni per le quali è stato installato un gestore; viene man-
tenuto invece ogni eventuale impostazione dell’azione a SIG_IGN. Questo permette ad esempio
alla shell di impostare ad SIG_IGN le risposte per SIGINT e SIGQUIT per i programmi eseguiti in
background, che altrimenti sarebbero interrotti da una successiva pressione di C-c o C-y.
Per quanto riguarda il comportamento di tutte le altre system call si danno sostanzialmente
due casi, a seconda che esse siano lente (slow) o veloci (fast). La gran parte di esse appartiene
a quest’ultima categoria, che non è influenzata dall’arrivo di un segnale. Esse sono dette veloci
in quanto la loro esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre
data dopo che la system call è stata completata, in quanto attendere per eseguire un gestore non
comporta nessun inconveniente.
In alcuni casi però alcune system call (che per questo motivo vengono chiamate lente) possono
bloccarsi indefinitamente. In questo caso non si può attendere la conclusione della system call,

perché questo renderebbe impossibile una risposta pronta al segnale, per cui il gestore viene
eseguito prima che la system call sia ritornata. Un elenco dei casi in cui si presenta questa
situazione è il seguente:
• la lettura da file che possono bloccarsi in attesa di dati non ancora presenti (come per certi
file di dispositivo, i socket o le pipe);
• la scrittura sugli stessi file, nel caso in cui dati non possano essere accettati immediatamente
(di nuovo comune per i socket);
• l’apertura di un file di dispositivo che richiede operazioni non immediate per una risposta
(ad esempio l’apertura di un nastro che deve essere riavvolto);
• le operazioni eseguite con ioctl che non è detto possano essere eseguite immediatamente;
• le funzioni di intercomunicazione che si bloccano in attesa di risposte da altri processi;
• la funzione pause (usata appunto per attendere l’arrivo di un segnale);
• la funzione wait (se nessun processo figlio è ancora terminato).
In questo caso si pone il problema di cosa fare una volta che il gestore sia ritornato. La scelta
originaria dei primi Unix era quella di far ritornare anche la system call restituendo l’errore
di EINTR. Questa è a tutt’oggi una scelta corrente, ma comporta che i programmi che usano
dei gestori controllino lo stato di uscita delle funzioni che eseguono una system call lenta per
ripeterne la chiamata qualora l’errore fosse questo.
Dimenticarsi di richiamare una system call interrotta da un segnale è un errore comune,
tanto che le glibc provvedono una macro TEMP_FAILURE_RETRY(expr) che esegue l’operazione
automaticamente, ripetendo l’esecuzione dell’espressione expr fintanto che il risultato non è
diverso dall’uscita con un errore EINTR.
La soluzione è comunque poco elegante e BSD ha scelto un approccio molto diverso, che
è quello di fare ripartire automaticamente una system call interrotta invece di farla fallire. In
questo caso ovviamente non c’è bisogno di preoccuparsi di controllare il codice di errore; si perde
però la possibilità di eseguire azioni specifiche all’occorrenza di questa particolare condizione.
Linux e le glibc consentono di utilizzare entrambi gli approcci, attraverso una opportuna
opzione di sigaction (vedi sez. 9.4.3). È da chiarire comunque che nel caso di interruzione nel
mezzo di un trasferimento parziale di dati, le system call ritornano sempre indicando i byte
trasferiti.
9.3.2 La funzione signal
L’interfaccia più semplice per la gestione dei segnali è costituita dalla funzione signal che è
definita fin dallo standard ANSI C. Quest’ultimo però non considera sistemi multitasking, per
cui la definizione è tanto vaga da essere del tutto inutile in un sistema Unix; è questo il motivo
per cui ogni implementazione successiva ne ha modificato e ridefinito il comportamento, pur
mantenendone immutato il prototipo3 che è:
#include <signal.h>
sighandler_t signal(int signum, sighandler_t handler)
Installa la funzione di gestione handler (il gestore) per il segnale signum.
La funzione ritorna il precedente gestore in caso di successo o SIG_ERR in caso di errore.
In questa definizione si è usato un tipo di dato, sighandler_t, che è una estensione GNU,
definita dalle glibc, che permette di riscrivere il prototipo di signal nella forma appena vista,
molto più leggibile di quanto non sia la versione originaria, che di norma è definita come:
3
in realtà in alcune vecchie implementazioni (SVr4 e 4.3+BSD in particolare) vengono usati alcuni argomenti
aggiuntivi per definire il comportamento della funzione, vedremo in sez. 9.4.3 che questo è possibile usando la
funzione sigaction.

void (* signal(int signum , void (* handler )(int ))) int)
questa infatti, per la poca chiarezza della sintassi del C quando si vanno a trattare puntatori
a funzioni, è molto meno comprensibile. Da un confronto con il precedente prototipo si può
dedurre la definizione di sighandler_t che è:
typedef void (* sighandler_t )(int)
e cioè un puntatore ad una funzione void (cioè senza valore di ritorno) e che prende un argo-
mento di tipo int.4 La funzione signal quindi restituisce e prende come secondo argomento un
puntatore a una funzione di questo tipo, che è appunto la funzione che verrà usata come gestore
del segnale.
Il numero di segnale passato nell’argomento signum può essere indicato direttamente con
una delle costanti definite in sez. 9.2.1. L’argomento handler che indica il gestore invece, oltre
all’indirizzo della funzione da chiamare all’occorrenza del segnale, può assumere anche i due
valori costanti SIG_IGN e SIG_DFL; il primo indica che il segnale deve essere ignorato,5 mentre
il secondo ripristina l’azione predefinita.6
La funzione restituisce l’indirizzo dell’azione precedente, che può essere salvato per poterlo
ripristinare (con un’altra chiamata a signal) in un secondo tempo. Si ricordi che se si imposta
come azione SIG_IGN (o si imposta un SIG_DFL per un segnale la cui azione predefinita è di
essere ignorato), tutti i segnali pendenti saranno scartati, e non verranno mai notificati.
L’uso di signal è soggetto a problemi di compatibilità, dato che essa si comporta in maniera
diversa per sistemi derivati da BSD o da System V. In questi ultimi infatti la funzione è conforme
al comportamento originale dei primi Unix in cui il gestore viene disinstallato alla sua chiamata,
secondo la semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie librerie
del C come le libc4 e le libc5.7
Al contrario BSD segue la semantica affidabile, non disinstallando il gestore e bloccando il
segnale durante l’esecuzione dello stesso. Con l’utilizzo delle glibc dalla versione 2 anche Linux
è passato a questo comportamento. Il comportamento della versione originale della funzione, il
cui uso è deprecato per i motivi visti in sez. 9.1.2, può essere ottenuto chiamando sysv_signal,
una volta che si sia definita la macro _XOPEN_SOURCE. In generale, per evitare questi problemi,
l’uso di signal, che tra l’altro ha un comportamento indefinito in caso di processo multi-thread,
è da evitare; tutti i nuovi programmi dovrebbero usare sigaction.
È da tenere presente che, seguendo lo standard POSIX, il comportamento di un processo che
ignora i segnali SIGFPE, SIGILL, o SIGSEGV (qualora questi non originino da una chiamata ad
una kill o ad una raise) è indefinito. Un gestore che ritorna da questi segnali può dare luogo
ad un ciclo infinito.
9.3.3 Le funzioni kill e raise
Come precedentemente accennato in sez. 9.1.3, un segnale può anche essere generato diretta-
mente nell’esecuzione di un programma, attraverso la chiamata ad una opportuna system call.
Le funzioni che si utilizzano di solito per inviare un segnale generico ad un processo sono due:
raise e kill.
4
si devono usare le parentesi intorno al nome della funzione per via delle precedenze degli operatori del C,
senza di esse si sarebbe definita una funzione che ritorna un puntatore a void e non un puntatore ad una funzione
void.
5
si ricordi però che i due segnali SIGKILL e SIGSTOP non possono essere né ignorati né intercettati; l’uso di
SIG_IGN per questi segnali non ha alcun effetto.
6
e serve a tornare al comportamento di default quando non si intende più gestire direttamente un segnale.
7
nelle libc5 esiste però la possibilità di includere bsd/signal.h al posto di signal.h, nel qual caso la funzione
signal viene ridefinita per seguire la semantica affidabile usata da BSD.

La prima funzione è raise, che è definita dallo standard ANSI C, e serve per inviare un
segnale al processo corrente,8 il suo prototipo è:
#include <signal.h>
int raise(int sig)
Invia il segnale sig al processo corrente.
La funzione restituisce zero in caso di successo e −1 per un errore, il solo errore restituito è EINVAL
qualora si sia specificato un numero di segnale invalido.
Il valore di sig specifica il segnale che si vuole inviare e può essere specificato con una delle
macro definite in sez. 9.2. In genere questa funzione viene usata per riprodurre il comportamento
predefinito di un segnale che sia stato intercettato. In questo caso, una volta eseguite le operazioni
volute, il gestore dovrà prima reinstallare l’azione predefinita, per poi attivarla chiamando raise.
Mentre raise è una funzione di libreria, quando si vuole inviare un segnale generico ad
un processo occorre utilizzare la apposita system call, questa può essere chiamata attraverso la
funzione kill, il cui prototipo è:
#include <signal.h>
int kill(pid_t pid, int sig)
Invia il segnale sig al processo specificato con pid.
La funzione restituisce 0 in caso di successo e −1 in caso di errore nel qual caso errno assumerà
uno dei valori:
EINVAL il segnale specificato non esiste.
ESRCH il processo selezionato non esiste.
EPERM non si hanno privilegi sufficienti ad inviare il segnale.
Lo standard POSIX prevede che il valore 0 per sig sia usato per specificare il segnale nullo.
Se la funzione viene chiamata con questo valore non viene inviato nessun segnale, ma viene
eseguito il controllo degli errori, in tal caso si otterrà un errore EPERM se non si hanno i permessi
necessari ed un errore ESRCH se il processo specificato non esiste. Si tenga conto però che il
sistema ricicla i pid (come accennato in sez. 3.2.1) per cui l’esistenza di un processo non significa
che esso sia realmente quello a cui si intendeva mandare il segnale.
Il valore dell’argomento pid specifica il processo (o i processi) di destinazione a cui il segnale
deve essere inviato e può assumere i valori riportati in tab. 9.4.
Si noti pertanto che la funzione raise(sig) può essere definita in termini di kill, ed è
sostanzialmente equivalente ad una kill(getpid(), sig). Siccome raise, che è definita nello
standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale l’uso di kill finisce
per essere più portabile.
Una seconda funzione che può essere definita in termini di kill è killpg, che è sostanzial-
mente equivalente a kill(-pidgrp, signal); il suo prototipo è:
#include <signal.h>
int killpg(pid_t pidgrp, int signal)
Invia il segnale signal al process group pidgrp.
La funzione restituisce 0 in caso di successo e −1 in caso di errore, gli errori sono gli stessi di kill.
e permette di inviare un segnale a tutto un process group (vedi sez. 10.1.2).
Solo l’amministratore può inviare un segnale ad un processo qualunque, in tutti gli altri casi
l’user-ID reale o l’user-ID effettivo del processo chiamante devono corrispondere all’user-ID reale
8
non prevedendo la presenza di un sistema multiutente lo standard ANSI C non poteva che definire una funzione
che invia il segnale al programma in esecuzione. Nel caso di Linux questa viene implementata come funzione di
compatibilità.

Valore Significato
> 0 Il segnale è mandato al processo con il pid indicato.
0 Il segnale è mandato ad ogni processo del process group del chiamante.
−1 Il segnale è mandato ad ogni processo (eccetto init).
< −1 Il segnale è mandato ad ogni processo del process group |pid|.
Tabella 9.4: Valori dell’argomento pid per la funzione kill.
o all’user-ID salvato della destinazione. Fa eccezione il caso in cui il segnale inviato sia SIGCONT,
nel quale occorre che entrambi i processi appartengano alla stessa sessione. Inoltre, dato il ruolo
fondamentale che riveste nel sistema (si ricordi quanto visto in sez. 9.2.3), non è possibile inviare
al processo 1 (cioè a init) segnali per i quali esso non abbia un gestore installato.
Infine, seguendo le specifiche POSIX 1003.1-2001, l’uso della chiamata kill(-1, sig) com-
porta che il segnale sia inviato (con la solita eccezione di init) a tutti i processi per i quali i
permessi lo consentano. Lo standard permette comunque alle varie implementazioni di esclude-
re alcuni processi specifici: nel caso in questione Linux non invia il segnale al processo che ha
effettuato la chiamata.
9.3.4 Le funzioni alarm, abort ed i timer
Un caso particolare di segnali generati a richiesta è quello che riguarda i vari segnali di tem-
porizzazione e SIGABRT, per ciascuno di questi segnali sono previste funzioni specifiche che ne
effettuino l’invio. La più comune delle funzioni usate per la temporizzazione è alarm il cui
prototipo è:
#include <unistd.h>
unsigned int alarm(unsigned int seconds)
Predispone l’invio di SIGALRM dopo seconds secondi.
La funzione restituisce il numero di secondi rimanenti ad un precedente allarme, o zero se non
c’erano allarmi pendenti.
La funzione fornisce un meccanismo che consente ad un processo di predisporre un’interru-
zione nel futuro, (ad esempio per effettuare una qualche operazione dopo un certo periodo di
tempo), programmando l’emissione di un segnale (nel caso in questione SIGALRM) dopo il numero
di secondi specificato da seconds.
Se si specifica per seconds un valore nullo non verrà inviato nessun segnale; siccome alla
chiamata viene cancellato ogni precedente allarme, questo può essere usato per cancellare una
programmazione precedente.
La funzione inoltre ritorna il numero di secondi rimanenti all’invio dell’allarme programmato
in precedenza. In questo modo è possibile controllare se non si è cancellato un precedente allarme
e predisporre eventuali misure che permettano di gestire il caso in cui servono più interruzioni.
In sez. 8.4.1 abbiamo visto che ad ogni processo sono associati tre tempi diversi: il clock time,
l’user time ed il system time. Per poterli calcolare il kernel mantiene per ciascun processo tre
diversi timer:
• un real-time timer che calcola il tempo reale trascorso (che corrisponde al clock time). La
scadenza di questo timer provoca l’emissione di SIGALRM;
• un virtual timer che calcola il tempo di processore usato dal processo in user space (che
corrisponde all’user time). La scadenza di questo timer provoca l’emissione di SIGVTALRM;
• un profiling timer che calcola la somma dei tempi di processore utilizzati direttamente dal
processo in user space, e dal kernel nelle system call ad esso relative (che corrisponde a
quello che in sez. 8.4.1 abbiamo chiamato CPU time). La scadenza di questo timer provoca
l’emissione di SIGPROF.

Il timer usato da alarm è il clock time, e corrisponde cioè al tempo reale. La funzione come
abbiamo visto è molto semplice, ma proprio per questo presenta numerosi limiti: non consente di
usare gli altri timer, non può specificare intervalli di tempo con precisione maggiore del secondo
e genera il segnale una sola volta.
Per ovviare a questi limiti Linux deriva da BSD la funzione setitimer che permette di usare
un timer qualunque e l’invio di segnali periodici, al costo però di una maggiore complessità d’uso
e di una minore portabilità. Il suo prototipo è:
int setitimer(int which, const struct itimerval *value, struct itimerval *ovalue)
Predispone l’invio di un segnale di allarme alla scadenza dell’intervallo value sul timer
specificato da which.
uno dei valori EINVAL o EFAULT.
Il valore di which permette di specificare quale dei tre timer illustrati in precedenza usare; i
possibili valori sono riportati in tab. 9.5.
Valore Timer
ITIMER_REAL real-time timer
ITIMER_VIRTUAL virtual timer
ITIMER_PROF profiling timer
Tabella 9.5: Valori dell’argomento which per la funzione setitimer.
Il valore della struttura specificata value viene usato per impostare il timer, se il puntatore
ovalue non è nullo il precedente valore viene salvato qui. I valori dei timer devono essere indicati
attraverso una struttura itimerval, definita in fig. 5.5.
La struttura è composta da due membri, il primo, it_interval definisce il periodo del timer;
il secondo, it_value il tempo mancante alla scadenza. Entrambi esprimono i tempi tramite una
struttura timeval che permette una precisione fino al microsecondo.
Ciascun timer decrementa il valore di it_value fino a zero, poi invia il segnale e reimposta
it_value al valore di it_interval, in questo modo il ciclo verrà ripetuto; se invece il valore di
it_interval è nullo il timer si ferma.
struct itimerval
{
struct timeval it_interval; /* next value */
struct timeval it_value; /* current value */
};
Figura 9.2: La struttura itimerval, che definisce i valori dei timer di sistema.
L’uso di setitimer consente dunque un controllo completo di tutte le caratteristiche dei
timer, ed in effetti la stessa alarm, benché definita direttamente nello standard POSIX.1, può a
sua volta essere espressa in termini di setitimer, come evidenziato dal manuale delle glibc [5]
che ne riporta la definizione mostrata in fig. 9.3.9
Si deve comunque tenere presente che fino al kernel 2.6.16 la precisione di queste funzioni era
limitata dalla frequenza del timer di sistema,10 in quanto le temporizzazioni erano calcolate in
numero di interruzioni del timer (i cosiddetti ”jiffies”), ed era assicurato soltanto che il segnale
non sarebbe stato mai generato prima della scadenza programmata (l’arrotondamento cioè era
9
questo comporta anche che non è il caso di mescolare chiamate ad abort e a setitimer.
10
il valore della costante HZ, di cui abbiamo già parlato in sez. 3.1.1.

unsigned int alarm(unsigned int seconds)
{
struct itimerval old , new;
new.it_interval.tv_usec = 0;
new.it_interval.tv_sec = 0;
new.it_value.tv_usec = 0;
new.it_value.tv_sec = (long int) seconds;
if (setitimer(ITIMER_REAL , &new , &old) < 0) {
return 0;
}
else {
return old.it_value.tv_sec;
}
}
Figura 9.3: Definizione di alarm in termini di setitimer.
effettuato per eccesso).11 L’uso del contatore dei jiffies, un intero a 32 bit, comportava inoltre
l’impossibilità di specificare tempi molto lunghi.12 Con il cambiamento della rappresentazione
effettuato nel kernel 2.6.16 questo problema è scomparso e con l’introduzione dei timer ad alta
risoluzione (vedi sez. 9.5.2) nel kernel 2.6.21 la precisione è diventata quella fornita dall’hardware
disponibile.
Una seconda causa di potenziali ritardi è che il segnale viene generato alla scadenza del
timer, ma poi deve essere consegnato al processo; se quest’ultimo è attivo (questo è sempre vero
per ITIMER_VIRT) la consegna è immediata, altrimenti può esserci un ulteriore ritardo che può
variare a seconda del carico del sistema.
Questo ha una conseguenza che può indurre ad errori molto subdoli, si tenga conto poi che
in caso di sistema molto carico, si può avere il caso patologico in cui un timer scade prima che il
segnale di una precedente scadenza sia stato consegnato; in questo caso, per il comportamento
dei segnali descritto in sez. 9.3.6, un solo segnale sarà consegnato. Per questo oggi l’uso di questa
funzione è deprecato a favore dei POSIX timer che tratteremo in sez. 9.5.2.
Dato che sia alarm che setitimer non consentono di leggere il valore corrente di un timer
senza modificarlo, è possibile usare la funzione getitimer, il cui prototipo è:
int getitimer(int which, struct itimerval *value)
Legge in value il valore del timer specificato da which.
La funzione restituisce 0 in caso di successo e −1 in caso di errore e restituisce gli stessi errori di
getitimer.
i cui argomenti hanno lo stesso significato e formato di quelli di setitimer.
L’ultima funzione che permette l’invio diretto di un segnale è abort, che, come accennato in
sez. 3.2.3, permette di abortire l’esecuzione di un programma tramite l’invio di SIGABRT. Il suo
prototipo è:
#include <stdlib.h>
void abort(void)
Abortisce il processo corrente.
La funzione non ritorna, il processo è terminato inviando il segnale di SIGABRT.
11
questo in realtà non è del tutto vero a causa di un bug, presente fino al kernel 2.6.12, che in certe circostanze
causava l’emissione del segnale con un arrotondamento per difetto.
12
superiori al valore della costante MAX_SEC_IN_JIFFIES, pari, nel caso di default di un valore di HZ di 250, a
circa 99 giorni e mezzo.

La differenza fra questa funzione e l’uso di raise è che anche se il segnale è bloccato o
ignorato, la funzione ha effetto lo stesso. Il segnale può però essere intercettato per effettuare
eventuali operazioni di chiusura prima della terminazione del processo.
Lo standard ANSI C richiede inoltre che anche se il gestore ritorna, la funzione non ritorni
comunque. Lo standard POSIX.1 va oltre e richiede che se il processo non viene terminato diret-
tamente dal gestore sia la stessa abort a farlo al ritorno dello stesso. Inoltre, sempre seguendo
lo standard POSIX, prima della terminazione tutti i file aperti e gli stream saranno chiusi ed i
buffer scaricati su disco. Non verranno invece eseguite le eventuali funzioni registrate con atexit
e on_exit.
9.3.5 Le funzioni di pausa e attesa
Sono parecchie le occasioni in cui si può avere necessità di sospendere temporaneamente l’esecu-
zione di un processo. Nei sistemi più elementari in genere questo veniva fatto con un opportuno
loop di attesa, ma in un sistema multitasking un loop di attesa è solo un inutile spreco di CPU,
per questo ci sono apposite funzioni che permettono di mettere un processo in stato di attesa.13
Il metodo tradizionale per fare attendere ad un processo fino all’arrivo di un segnale è quello
di usare la funzione pause, il cui prototipo è:
#include <unistd.h>
int pause(void)
Pone il processo in stato di sleep fino al ritorno di un gestore.
La funzione ritorna solo dopo che un segnale è stato ricevuto ed il relativo gestore è ritornato, nel
qual caso restituisce −1 e errno assumerà il valore EINTR.
La funzione segnala sempre una condizione di errore (il successo sarebbe quello di aspettare
indefinitamente). In genere si usa questa funzione quando si vuole mettere un processo in attesa
di un qualche evento specifico che non è sotto il suo diretto controllo (ad esempio la si può
usare per interrompere l’esecuzione del processo fino all’arrivo di un segnale inviato da un altro
processo).
Quando invece si vuole fare attendere un processo per un intervallo di tempo già noto nello
standard POSIX.1 viene definita la funzione sleep, il cui prototipo è:
#include <unistd.h>
unsigned int sleep(unsigned int seconds)
Pone il processo in stato di sleep per seconds secondi.
La funzione restituisce zero se l’attesa viene completata, o il numero di secondi restanti se viene
interrotta da un segnale.
La funzione attende per il tempo specificato, a meno di non essere interrotta da un segnale.
In questo caso non è una buona idea ripetere la chiamata per il tempo rimanente, in quanto
la riattivazione del processo può avvenire in un qualunque momento, ma il valore restituito
sarà sempre arrotondato al secondo, con la conseguenza che, se la successione dei segnali è
particolarmente sfortunata e le differenze si accumulano, si potranno avere ritardi anche di
parecchi secondi. In genere la scelta più sicura è quella di stabilire un termine per l’attesa, e
ricalcolare tutte le volte il numero di secondi da aspettare.
In alcune implementazioni inoltre l’uso di sleep può avere conflitti con quello di SIGALRM,
dato che la funzione può essere realizzata con l’uso di pause e alarm (in maniera analoga
all’esempio che vedremo in sez. 9.4.1). In tal caso mescolare chiamata di alarm e sleep o
modificare l’azione di SIGALRM, può causare risultati indefiniti. Nel caso delle glibc è stata usata
una implementazione completamente indipendente e questi problemi non ci sono.
13
si tratta in sostanza di funzioni che permettono di portare esplicitamente il processo in stato di sleep, vedi
sez. 3.4.1.

La granularità di sleep permette di specificare attese soltanto in secondi, per questo sia sotto
BSD4.3 che in SUSv2 è stata definita la funzione usleep (dove la u è intesa come sostituzione
di µ); i due standard hanno delle definizioni diverse, ma le glibc seguono14 seguono quella di
SUSv2 che prevede il seguente prototipo:
#include <unistd.h>
int usleep(unsigned long usec)
Pone il processo in stato di sleep per usec microsecondi.
La funzione restituisce zero se l’attesa viene completata, o −1 in caso di errore, nel qual caso
errno assumerà il valore EINTR.
Anche questa funzione, a seconda delle implementazioni, può presentare problemi nell’inte-
razione con alarm e SIGALRM. È pertanto deprecata in favore della funzione nanosleep, definita
dallo standard POSIX1.b, il cui prototipo è:
#include <unistd.h>
int nanosleep(const struct timespec *req, struct timespec *rem)
Pone il processo in stato di sleep per il tempo specificato da req. In caso di interruzione
restituisce il tempo restante in rem.
La funzione restituisce zero se l’attesa viene completata, o −1 in caso di errore, nel qual caso
EINVAL si è specificato un numero di secondi negativo o un numero di nanosecondi maggiore
di 999.999.999.
Lo standard richiede che la funzione sia implementata in maniera del tutto indipendente
da alarm15 e sia utilizzabile senza interferenze con l’uso di SIGALRM. La funzione prende come
argomenti delle strutture di tipo timespec, la cui definizione è riportata in fig. 5.8, che permette
di specificare un tempo con una precisione fino al nanosecondo.
La funzione risolve anche il problema di proseguire l’attesa dopo l’interruzione dovuta ad un
segnale; infatti in tal caso in rem viene restituito il tempo rimanente rispetto a quanto richiesto
inizialmente,16 e basta richiamare la funzione per completare l’attesa.17
Chiaramente, anche se il tempo può essere specificato con risoluzioni fino al nanosecondo, la
precisione di nanosleep è determinata dalla risoluzione temporale del timer di sistema. Perciò
la funzione attenderà comunque il tempo specificato, ma prima che il processo possa tornare ad
essere eseguito occorrerà almeno attendere la successiva interruzione del timer di sistema, cioè
un tempo che a seconda dei casi può arrivare fino a 1/HZ, (sempre che il sistema sia scarico ed
il processa venga immediatamente rimesso in esecuzione); per questo motivo il valore restituito
in rem è sempre arrotondato al multiplo successivo di 1/HZ.
Con i kernel della serie 2.4 in realtà era possibile ottenere anche pause più precise del cen-
tesimo di secondo usando politiche di scheduling real-time come SCHED_FIFO o SCHED_RR; in tal
caso infatti il calcolo sul numero di interruzioni del timer veniva evitato utilizzando direttamen-
te un ciclo di attesa con cui si raggiungevano pause fino ai 2 ms con precisioni del µs. Questa
estensione è stata rimossa con i kernel della serie 2.6, che consentono una risoluzione più alta
del timer di sistema; inoltre a partire dal kernel 2.6.21, nanosleep può avvalersi del supporto
dei timer ad alta risoluzione, ottenendo la massima precisione disponibile sull’hardware della
propria macchina.
14
secondo la pagina di manuale almeno dalla versione 2.2.2.
15
nel caso di Linux questo è fatto utilizzando direttamente il timer del kernel.
16
con l’eccezione, valida solo nei kernel della serie 2.4, in cui, per i processi riavviati dopo essere stati fermati
da un segnale, il tempo passato in stato T non viene considerato nel calcolo della rimanenza.
17
anche qui però occorre tenere presente che i tempi sono arrotondati, per cui la precisione, per quanto migliore
di quella ottenibile con sleep, è relativa e in caso di molte interruzioni si può avere una deriva, per questo esiste
la funzione clock_nanosleep (vedi sez. 9.5.2) che permette di specificare un tempo assoluto anziché un tempo
relativo.

9.3.6 Un esempio elementare
Un semplice esempio per illustrare il funzionamento di un gestore di segnale è quello della
gestione di SIGCHLD. Abbiamo visto in sez. 3.2.3 che una delle azioni eseguite dal kernel alla
conclusione di un processo è quella di inviare questo segnale al padre.18 In generale dunque,
quando non interessa elaborare lo stato di uscita di un processo, si può completare la gestione
della terminazione installando un gestore per SIGCHLD il cui unico compito sia quello di chiamare
waitpid per completare la procedura di terminazione in modo da evitare la formazione di zombie.
In fig. 9.4 è mostrato il codice contenente una implementazione generica di una funzione di
gestione per SIGCHLD, (che si trova nei sorgenti allegati nel file SigHand.c); se ripetiamo i test
di sez. 3.2.3, invocando forktest con l’opzione -s (che si limita ad effettuare l’installazione di
questa funzione come gestore di SIGCHLD) potremo verificare che non si ha più la creazione di
zombie.
1 void HandSigCHLD(int sig)
2 {
3 int errno_save;
4 int status;
5 pid_t pid;
6 /* save errno current value */
7 errno_save = errno;
8 /* loop until no */
9 do {
10 errno = 0;
11 pid = waitpid(WAIT_ANY , &status , WNOHANG );
12 } while (pid > 0);
13 /* restore errno value */
14 errno = errno_save;
15 /* return */
16 return;
17 }
Figura 9.4: Codice di una funzione generica di gestione per il segnale SIGCHLD.
Il codice del gestore è di lettura immediata; come buona norma di programmazione (si
ricordi quanto accennato sez. 8.5.1) si comincia (6-7) con il salvare lo stato corrente di errno, in
modo da poterlo ripristinare prima del ritorno del gestore (16-17). In questo modo si preserva il
valore della variabile visto dal corso di esecuzione principale del processo, che altrimenti sarebbe
sovrascritto dal valore restituito nella successiva chiamata di waitpid.
Il compito principale del gestore è quello di ricevere lo stato di terminazione del processo,
cosa che viene eseguita nel ciclo in (9-15). Il ciclo è necessario a causa di una caratteristica
fondamentale della gestione dei segnali: abbiamo già accennato come fra la generazione di un
segnale e l’esecuzione del gestore possa passare un certo lasso di tempo e niente ci assicura che
il gestore venga eseguito prima della generazione di ulteriori segnali dello stesso tipo. In questo
caso normalmente i segnali successivi vengono “fusi” col primo ed al processo ne viene recapitato
soltanto uno.
Questo può essere un caso comune proprio con SIGCHLD, qualora capiti che molti processi
figli terminino in rapida successione. Esso inoltre si presenta tutte le volte che un segnale viene
18
in realtà in SVr4 eredita la semantica di System V, in cui il segnale si chiama SIGCLD e viene trattato in
maniera speciale; in System V infatti se si imposta esplicitamente l’azione a SIG_IGN il segnale non viene generato
ed il sistema non genera zombie (lo stato di terminazione viene scartato senza dover chiamare una wait). L’azione
predefinita è sempre quella di ignorare il segnale, ma non attiva questo comportamento. Linux, come BSD e
POSIX, non supporta questa semantica ed usa il nome di SIGCLD come sinonimo di SIGCHLD.

9.4. LA GESTIONE AVANZATA DEI SEGNALI 279
bloccato: per quanti siano i segnali emessi durante il periodo di blocco, una volta che quest’ultimo
sarà rimosso verrà recapitato un solo segnale.
Allora, nel caso della terminazione dei processi figli, se si chiamasse waitpid una sola volta,
essa leggerebbe lo stato di terminazione per un solo processo, anche se i processi terminati sono
più di uno, e gli altri resterebbero in stato di zombie per un tempo indefinito.
Per questo occorre ripetere la chiamata di waitpid fino a che essa non ritorni un valore nullo,
segno che non resta nessun processo di cui si debba ancora ricevere lo stato di terminazione (si
veda sez. 3.2.4 per la sintassi della funzione). Si noti anche come la funzione venga invocata con
il parametro WNOHANG che permette di evitare il suo blocco quando tutti gli stati di terminazione
sono stati ricevuti.
9.4 La gestione avanzata dei segnali
Le funzioni esaminate finora fanno riferimento alle modalità più elementari della gestione dei
segnali; non si sono pertanto ancora prese in considerazione le tematiche più complesse, collegate
alle varie race condition che i segnali possono generare e alla natura asincrona degli stessi.
Affronteremo queste problematiche in questa sezione, partendo da un esempio che le evi-
denzi, per poi prendere in esame le varie funzioni che permettono di risolvere i problemi più
complessi connessi alla programmazione con i segnali, fino a trattare le caratteristiche generali
della gestione dei medesimi nella casistica ordinaria.
9.4.1 Alcune problematiche aperte
Come accennato in sez. 9.3.5 è possibile implementare sleep a partire dall’uso di pause e alarm.
A prima vista questo può sembrare di implementazione immediata; ad esempio una semplice
versione di sleep potrebbe essere quella illustrata in fig. 9.5.
1 void alarm_hand(int sig) {
2 /* check if the signal is the right one */
3 if (sig != SIGALRM) { /* if not exit with error */
4 printf("Something wrong , handler for SIGALRMn");
5 exit (1);
6 } else { /* do nothing , just interrupt pause */
7 return;
8 }
9 }
10 unsigned int sleep(unsigned int seconds)
11 {
12 sighandler_t prev_handler;
13 /* install and check new handler */
14 if (( prev_handler = signal(SIGALRM , alarm_hand )) == SIG_ERR) {
15 printf("Cannot set handler for alarmn");
16 exit (-1);
17 }
18 /* set alarm and go to sleep */
19 alarm(seconds );
20 pause ();
21 /* restore previous signal handler */
22 signal(SIGALRM , prev_handler );
23 /* return remaining time */
24 return alarm (0);
25 }
Figura 9.5: Una implementazione pericolosa di sleep.

Dato che è nostra intenzione utilizzare SIGALRM il primo passo della nostra implementazione
sarà quello di installare il relativo gestore salvando il precedente (14-17). Si effettuerà poi una
chiamata ad alarm per specificare il tempo d’attesa per l’invio del segnale a cui segue la chiamata
a pause per fermare il programma (18-20) fino alla sua ricezione. Al ritorno di pause, causato
dal ritorno del gestore (1-9), si ripristina il gestore originario (21-22) restituendo l’eventuale
tempo rimanente (23-24) che potrà essere diverso da zero qualora l’interruzione di pause venisse
causata da un altro segnale.
Questo codice però, a parte il non gestire il caso in cui si è avuta una precedente chiamata
a alarm (che si è tralasciato per brevità), presenta una pericolosa race condition. Infatti, se
il processo viene interrotto fra la chiamata di alarm e pause, può capitare (ad esempio se
il sistema è molto carico) che il tempo di attesa scada prima dell’esecuzione di quest’ultima,
cosicché essa sarebbe eseguita dopo l’arrivo di SIGALRM. In questo caso ci si troverebbe di fronte
ad un deadlock, in quanto pause non verrebbe mai più interrotta (se non in caso di un altro
segnale).
Questo problema può essere risolto (ed è la modalità con cui veniva fatto in SVr2) usando
la funzione longjmp (vedi sez. 2.4.4) per uscire dal gestore; in questo modo, con una condizione
sullo stato di uscita di quest’ultima, si può evitare la chiamata a pause, usando un codice del
tipo di quello riportato in fig. 9.6.
1 static jmp_buff alarm_return;
3 {
4 signandler_t prev_handler;
5 if (( prev_handler = signal(SIGALRM , alarm_hand )) == SIG_ERR) {
6 printf("Cannot set handler for alarmn");
7 exit (1);
8 }
9 if (setjmp(alarm_return) == 0) { /* if not returning from handler */
10 alarm(second ); /* call alarm */
11 pause (); /* then wait */
12 }
13 /* restore previous signal handler */
14 signal(SIGALRM , prev_handler );
15 /* remove alarm , return remaining time */
17 }
18 void alarm_hand(int sig)
19 {
20 /* check if the signal is the right one */
21 if (sig != SIGALRM) { /* if not exit with error */
22 printf("Something wrong , handler for SIGALRMn");
23 exit (1);
24 } else { /* return in main after the call to pause */
25 longjump(alarm_return , 1);
26 }
27 }
Figura 9.6: Una implementazione ancora malfunzionante di sleep.
In questo caso il gestore (18-27) non ritorna come in fig. 9.5, ma usa longjmp (25) per
rientrare nel corpo principale del programma; dato che in questo caso il valore di uscita di
setjmp è 1, grazie alla condizione in (9-12) si evita comunque che pause sia chiamata a vuoto.
Ma anche questa implementazione comporta dei problemi; in questo caso infatti non viene
gestita correttamente l’interazione con gli altri segnali; se infatti il segnale di allarme interrompe
un altro gestore, l’esecuzione non riprenderà nel gestore in questione, ma nel ciclo principale,

interrompendone inopportunamente l’esecuzione. Lo stesso tipo di problemi si presenterebbero
se si volesse usare alarm per stabilire un timeout su una qualunque system call bloccante.
Un secondo esempio è quello in cui si usa il segnale per notificare una qualche forma di evento;
in genere quello che si fa in questo caso è impostare nel gestore un opportuno flag da controllare
nel corpo principale del programma (con un codice del tipo di quello riportato in fig. 9.7).
La logica è quella di far impostare al gestore (14-19) una variabile globale preventivamente
inizializzata nel programma principale, il quale potrà determinare, osservandone il contenuto,
l’occorrenza o meno del segnale, e prendere le relative azioni conseguenti (6-11).
1 sig_atomic_t flag;
2 int main ()
3 {
4 flag = 0;
5 ...
6 if (flag) { /* test if signal occurred */
7 flag = 0; /* reset flag */
8 do_response (); /* do things */
9 } else {
10 do_other (); /* do other things */
11 }
12 ...
13 }
15 {
16 /* set the flag */
17 flag = 1;
18 return;
19 }
Figura 9.7: Un esempio non funzionante del codice per il controllo di un evento generato da un segnale.
Questo è il tipico esempio di caso, già citato in sez. 3.6.2, in cui si genera una race condition;
infatti, in una situazione in cui un segnale è già arrivato (e flag è già ad 1) se un altro segnale
arriva immediatamente dopo l’esecuzione del controllo (6) ma prima della cancellazione del flag
(7), la sua occorrenza sarà perduta.
Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono delle funzioni
più sofisticate di quelle finora illustrate, queste hanno la loro origine nella semplice interfaccia
dei primi sistemi Unix, ma con esse non è possibile gestire in maniera adeguata di tutti i possibili
aspetti con cui un processo deve reagire alla ricezione di un segnale.
9.4.2 Gli insiemi di segnali o signal set
Come evidenziato nel paragrafo precedente, le funzioni di gestione dei segnali originarie, nate con
la semantica inaffidabile, hanno dei limiti non superabili; in particolare non è prevista nessuna
funzione che permetta di gestire il blocco dei segnali o di verificare lo stato dei segnali pendenti.
Per questo motivo lo standard POSIX.1, insieme alla nuova semantica dei segnali ha introdotto
una interfaccia di gestione completamente nuova, che permette di ottenere un controllo molto
più dettagliato. In particolare lo standard ha introdotto un nuovo tipo di dato sigset_t, che
permette di rappresentare un insieme di segnali (un signal set, come viene usualmente chiamato),
tale tipo di dato viene usato per gestire il blocco dei segnali.
In genere un insieme di segnali è rappresentato da un intero di dimensione opportuna, di solito

pari al numero di bit dell’architettura della macchina,19 ciascun bit del quale è associato ad uno
specifico segnale; in questo modo è di solito possibile implementare le operazioni direttamente
con istruzioni elementari del processore. Lo standard POSIX.1 definisce cinque funzioni per
la manipolazione degli insiemi di segnali: sigemptyset, sigfillset, sigaddset, sigdelset e
sigismember, i cui prototipi sono:
#include <signal.h>
int sigemptyset(sigset_t *set)
Inizializza un insieme di segnali vuoto (in cui non c’è nessun segnale).
int sigfillset(sigset_t *set)
Inizializza un insieme di segnali pieno (in cui ci sono tutti i segnali).
int sigaddset(sigset_t *set, int signum)
Aggiunge il segnale signum all’insieme di segnali set.
int sigdelset(sigset_t *set, int signum)
Toglie il segnale signum dall’insieme di segnali set.
int sigismember(const sigset_t *set, int signum)
Controlla se il segnale signum è nell’insieme di segnali set.
Le prime quattro funzioni ritornano 0 in caso di successo, mentre sigismember ritorna 1 se signum
è in set e 0 altrimenti. In caso di errore tutte ritornano −1, con errno impostata a EINVAL (il solo
errore possibile è che signum non sia un segnale valido).
Dato che in generale non si può fare conto sulle caratteristiche di una implementazione (non
è detto che si disponga di un numero di bit sufficienti per mettere tutti i segnali in un intero,
o in sigset_t possono essere immagazzinate ulteriori informazioni) tutte le operazioni devono
essere comunque eseguite attraverso queste funzioni.
In genere si usa un insieme di segnali per specificare quali segnali si vuole bloccare, o per
riottenere dalle varie funzioni di gestione la maschera dei segnali attivi (vedi sez. 9.4.4). Essi
possono essere definiti in due diverse maniere, aggiungendo i segnali voluti ad un insieme vuoto
ottenuto con sigemptyset o togliendo quelli che non servono da un insieme completo ottenuto
con sigfillset. Infine sigismember permette di verificare la presenza di uno specifico segnale
in un insieme.
9.4.3 La funzione sigaction
Abbiamo già accennato in sez. 9.3.2 i problemi di compatibilità relativi all’uso di signal. Per ov-
viare a tutto questo lo standard POSIX.1 ha ridefinito completamente l’interfaccia per la gestione
dei segnali, rendendola molto più flessibile e robusta, anche se leggermente più complessa.
La funzione principale dell’interfaccia POSIX.1 per i segnali è sigaction. Essa ha sostan-
zialmente lo stesso uso di signal, permette cioè di specificare le modalità con cui un segnale
può essere gestito da un processo. Il suo prototipo è:
#include <signal.h>
int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact)
Installa una nuova azione per il segnale signum.
La funzione restituisce zero in caso di successo e −1 per un errore, nel qual caso errno assumerà
i valori:
EINVAL si è specificato un numero di segnale invalido o si è cercato di installare il gestore per
SIGKILL o SIGSTOP.
EFAULT si sono specificati indirizzi non validi.
La funzione serve ad installare una nuova azione per il segnale signum; si parla di azione e
non di gestore come nel caso di signal, in quanto la funzione consente di specificare le varie
19
nel caso dei PC questo comporta un massimo di 32 segnali distinti: dato che in Linux questi sono sufficienti
non c’è necessità di nessuna struttura più complicata.

caratteristiche della risposta al segnale, non solo la funzione che verrà eseguita alla sua occor-
renza. Per questo lo standard raccomanda di usare sempre questa funzione al posto di signal
(che in genere viene definita tramite essa), in quanto permette un controllo completo su tutti gli
aspetti della gestione di un segnale, sia pure al prezzo di una maggiore complessità d’uso.
Se il puntatore act non è nullo, la funzione installa la nuova azione da esso specificata,
se oldact non è nullo il valore dell’azione corrente viene restituito indietro. Questo permette
(specificando act nullo e oldact non nullo) di superare uno dei limiti di signal, che non consente
di ottenere l’azione corrente senza installarne una nuova.
Entrambi i puntatori fanno riferimento alla struttura sigaction, tramite la quale si specifica-
no tutte le caratteristiche dell’azione associata ad un segnale. Anch’essa è descritta dallo standard
POSIX.1 ed in Linux è definita secondo quanto riportato in fig. 9.8. Il campo sa_restorer, non
previsto dallo standard, è obsoleto e non deve essere più usato.
struct sigaction
{
void (* sa_handler )(int);
void (* sa_sigaction )(int , siginfo_t *, void *);
sigset_t sa_mask;
int sa_flags;
void (* sa_restorer )( void );
}
Figura 9.8: La struttura sigaction.
Il campo sa_mask serve ad indicare l’insieme dei segnali che devono essere bloccati durante
l’esecuzione del gestore, ad essi viene comunque sempre aggiunto il segnale che ne ha causato la
chiamata, a meno che non si sia specificato con sa_flag un comportamento diverso. Quando il
gestore ritorna comunque la maschera dei segnali bloccati (vedi sez. 9.4.4) viene ripristinata al
valore precedente l’invocazione.
L’uso di questo campo permette ad esempio di risolvere il problema residuo dell’implemen-
tazione di sleep mostrata in fig. 9.6. In quel caso infatti se il segnale di allarme avesse interrotto
un altro gestore questo non sarebbe stato eseguito correttamente; la cosa poteva essere prevenuta
installando gli altri gestori usando sa_mask per bloccare SIGALRM durante la loro esecuzione. Il
valore di sa_flag permette di specificare vari aspetti del comportamento di sigaction, e della
reazione del processo ai vari segnali; i valori possibili ed il relativo significato sono riportati in
tab. 9.6.
Come si può notare in fig. 9.8 sigaction permette di utilizzare due forme diverse di gestore,21
da specificare, a seconda dell’uso o meno del flag SA_SIGINFO, rispettivamente attraverso i campi
sa_sigaction o sa_handler,22 Quest’ultima è quella classica usata anche con signal, mentre
la prima permette di usare un gestore più complesso, in grado di ricevere informazioni più
dettagliate dal sistema, attraverso la struttura siginfo_t, riportata in fig. 9.9.
Installando un gestore di tipo sa_sigaction diventa allora possibile accedere alle informa-
zioni restituite attraverso il puntatore a questa struttura. Tutti i segnali impostano i campi
si_signo, che riporta il numero del segnale ricevuto, si_errno, che riporta, quando diverso
da zero, il codice dell’errore associato al segnale, e si_code, che viene usato dal kernel per
specificare maggiori dettagli riguardo l’evento che ha causato l’emissione del segnale.
20
questa funzionalità è stata introdotta nel kernel 2.6 e va a modificare il comportamento di waitpid.
21
la possibilità è prevista dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x con l’intro-
duzione dei segnali real-time (vedi sez. 9.5.1); in precedenza era possibile ottenere alcune informazioni addizionali
usando sa_handler con un secondo parametro addizionale di tipo sigcontext, che adesso è deprecato.
22
i due campi devono essere usati in maniera alternativa, in certe implementazioni questi campi vengono

Valore Significato
SA_NOCLDSTOP Se il segnale è SIGCHLD allora non deve essere notificato
quando il processo figlio viene fermato da uno dei segnali
SIGSTOP, SIGTSTP, SIGTTIN o SIGTTOU.
SA_RESETHAND Ristabilisce l’azione per il segnale al valore predefinito
una volta che il gestore è stato lanciato, riproduce cioè il
comportamento della semantica inaffidabile.
SA_ONESHOT Nome obsoleto, sinonimo non standard di SA_RESETHAND;
da evitare.
SA_ONSTACK Stabilisce l’uso di uno stack alternativo per l’esecuzione
del gestore (vedi sez. 9.5.3).
SA_RESTART Riavvia automaticamente le slow system call quando ven-
gono interrotte dal suddetto segnale; riproduce cioè il
comportamento standard di BSD.
SA_NODEFER Evita che il segnale corrente sia bloccato durante
l’esecuzione del gestore.
SA_NOMASK Nome obsoleto, sinonimo non standard di SA_NODEFER.
SA_SIGINFO Deve essere specificato quando si vuole usare un ge-
store in forma estesa usando sa_sigaction al posto di
sa_handler.
SA_NOCLDWAIT Se il segnale è SIGCHLD allora i processi figli non diventano
zombie quando terminano.20
Tabella 9.6: Valori del campo sa_flag della struttura sigaction.
siginfo_t {
int si_signo; /* Signal number */
int si_errno; /* An errno value */
int si_code; /* Signal code */
int si_trapno; /* Trap number that caused hardware -generated
signal (unused on most architectures) */
pid_t si_pid; /* Sending process ID */
uid_t si_uid; /* Real user ID of sending process */
int si_status; /* Exit value or signal */
clock_t si_utime; /* User time consumed */
clock_t si_stime; /* System time consumed */
sigval_t si_value; /* Signal value */
int si_int; /* POSIX .1b signal */
void * si_ptr; /* POSIX .1b signal */
int si_overrun; /* Timer overrun count; POSIX .1b timers */
int si_timerid; /* Timer ID; POSIX .1b timers */
void * si_addr; /* Memory location which caused fault */
long si_band; /* Band event (was int before glibc 2.3.2) */
int si_fd; /* File descriptor */
}
Figura 9.9: La struttura siginfo_t.
In generale si_code contiene, per i segnali generici, per quelli real-time e per tutti quelli
inviati tramite da un processo con kill o affini, le informazioni circa l’origine del segnale stesso,
ad esempio se generato dal kernel, da un timer, da kill, ecc. Il valore viene sempre espresso
come una costante,23 ed i valori possibili in questo caso sono riportati in tab. 9.7.
Nel caso di alcuni segnali però il valore di si_code viene usato per fornire una informazione
specifica relativa alle motivazioni della ricezione dello stesso; ad esempio i vari segnali di errore
addirittura definiti come union.
23
le definizioni di tutti i valori possibili si trovano in bits/siginfo.h.

(SIGILL, SIGFPE, SIGSEGV e SIGBUS) lo usano per fornire maggiori dettagli riguardo l’errore,
come il tipo di errore aritmetico, di istruzione illecita o di violazione di memoria; mentre alcuni
segnali di controllo (SIGCHLD, SIGTRAP e SIGPOLL) forniscono altre informazioni specifiche.
Valore Significato
SI_USER generato da kill o raise.
SI_KERNEL inviato dal kernel.
SI_QUEUE inviato con sigqueue (vedi sez. 9.5.1).
SI_TIMER scadenza di un POSIX timer (vedi sez. 9.5.2).
SI_MESGQ inviato al cambiamento di stato di una coda di messaggi
POSIX (vedi sez. 11.4.2).24
SI_ASYNCIO una operazione di I/O asincrono (vedi sez. 12.3) è stata
completata.
SI_SIGIO segnale di SIGIO da una coda (vedi sez. 12.3.1).
SI_TKILL inviato da tkill o tgkill (vedi sez. ??).25
Tabella 9.7: Valori del campo si_code della struttura sigaction per i segnali generici.
In questo caso il valore del campo si_code deve essere verificato nei confronti delle diverse
costanti previste per ciascuno di detti segnali;26 l’elenco dettagliato dei nomi di queste costanti
è riportato nelle diverse sezioni di tab. 9.8 che sono state ordinate nella sequenza in cui si sono
appena citati i rispettivi segnali.27
Il resto della struttura siginfo_t è definito come union ed i valori eventualmente presenti
dipendono dal segnale, cos`ı SIGCHLD ed i segnali real-time (vedi sez. 9.5.1) inviati tramite kill
avvalorano si_pid e si_uid coi valori corrispondenti al processo che ha emesso il segnale,
SIGCHLD avvalora anche i campi si_status, si_utime e si_stime che indicano rispettivamente
lo stato di uscita, l’user time e il system time (vedi sez. 8.4.2) usati dal processo; SIGILL,
SIGFPE, SIGSEGV e SIGBUS avvalorano si_addr con l’indirizzo in cui è avvenuto l’errore, SIGIO
(vedi sez. 12.3.3) avvalora si_fd con il numero del file descriptor e si_band per i dati urgenti
(vedi sez. 19.1.3) su un socket, il segnale inviato alla scadenza di un timer POSIX (vedi sez. 9.5.2)
avvalora i campi si_timerid e si_overrun.
Benché sia possibile usare nello stesso programma sia sigaction che signal occorre molta
attenzione, in quanto le due funzioni possono interagire in maniera anomala. Infatti l’azione
specificata con sigaction contiene un maggior numero di informazioni rispetto al semplice
indirizzo del gestore restituito da signal. Per questo motivo se si usa quest’ultima per installare
un gestore sostituendone uno precedentemente installato con sigaction, non sarà possibile
effettuare un ripristino corretto dello stesso.
Per questo è sempre opportuno usare sigaction, che è in grado di ripristinare correttamente
un gestore precedente, anche se questo è stato installato con signal. In generale poi non è il
caso di usare il valore di ritorno di signal come campo sa_handler, o viceversa, dato che in
certi sistemi questi possono essere diversi. In definitiva dunque, a meno che non si sia vincolati
all’aderenza stretta allo standard ISO C, è sempre il caso di evitare l’uso di signal a favore di
sigaction.
Per questo motivo si è provveduto, per mantenere un’interfaccia semplificata che abbia le stes-
se caratteristiche di signal, a definire attraverso sigaction una funzione equivalente Signal,
il cui codice è riportato in fig. 9.10 (il codice completo si trova nel file SigHand.c nei sorgenti al-
24
25
26
dato che si tratta di una costante, e non di una maschera binaria, i valori numerici vengono riutilizzati e
ciascuno di essi avrà un significato diverso a seconda del segnale a cui è associato.
27
il prefisso del nome indica comunque in maniera diretta il segnale a cui le costanti fanno riferimento.

Valore Significato
ILL_ILLOPC codice di operazione illegale.
ILL_ILLOPN operando illegale.
ILL_ILLADR modo di indirizzamento illegale.
ILL_ILLTRP trappola di processore illegale.
ILL_PRVOPC codice di operazione privilegiato.
ILL_PRVREG registro privilegiato.
ILL_COPROC errore del coprocessore.
ILL_BADSTK errore nello stack interno.
FPE_INTDIV divisione per zero intera.
FPE_INTOVF overflow intero.
FPE_FLTDIV divisione per zero in virgola mobile.
FPE_FLTOVF overflow in virgola mobile.
FPE_FLTUND underflow in virgola mobile.
FPE_FLTRES risultato in virgola mobile non esatto.
FPE_FLTINV operazione in virgola mobile non valida.
FPE_FLTSUB mantissa? fuori intervallo.
SEGV_MAPERR indirizzo non mappato.
SEGV_ACCERR permessi non validi per l’indirizzo.
BUS_ADRALN allineamento dell’indirizzo non valido.
BUS_ADRERR indirizzo fisico inesistente.
BUS_OBJERR errore hardware sull’indirizzo.
TRAP_BRKPT breakpoint sul processo.
TRAP_TRACE trappola di tracciamento del processo.
CLD_EXITED il figlio è uscito.
CLD_KILLED il figlio è stato terminato.
CLD_DUMPED il figlio è terminato in modo anormale.
CLD_TRAPPED un figlio tracciato ha raggiunto una trappola.
CLD_STOPPED il figlio è stato fermato.
CLD_CONTINUED il figlio è ripartito.
POLL_IN disponibili dati in ingresso.
POLL_OUT spazio disponibile sul buffer di uscita.
POLL_MSG disponibili messaggi in ingresso.
POLL_ERR errore di I/O.
POLL_PRI disponibili dati di alta priorità in ingresso.
POLL_HUP il dispositivo è stato disconnesso.
Tabella 9.8: Valori del campo si_code della struttura sigaction impostati rispettivamente dai segnali SIGILL,
SIGFPE, SIGSEGV, SIGBUS, SIGCHLD, SIGTRAP e SIGPOLL/SIGIO.
1 typedef void SigFunc(int);
2 inline SigFunc * Signal(int signo , SigFunc *func)
3 {
4 struct sigaction new_handl , old_handl;
5 new_handl.sa_handler = func;
6 /* clear signal mask: no signal blocked during execution of func */
7 if (sigemptyset (& new_handl.sa_mask )!=0){ /* initialize signal set */
8 return SIG_ERR;
9 }
10 new_handl.sa_flags =0; /* init to 0 all flags */
11 /* change action for signo signal */
12 if (sigaction(signo , &new_handl , &old_handl )){
13 return SIG_ERR;
14 }
15 return (old_handl.sa_handler );
16 }
Figura 9.10: La funzione Signal, equivalente a signal, definita attraverso sigaction.

legati). Si noti come, essendo la funzione estremamente semplice, essa è definita come inline;28
per semplificare ulteriormente la definizione si è poi definito un apposito tipo SigFunc.
9.4.4 La gestione della maschera dei segnali o signal mask
Come spiegato in sez. 9.1.2 tutti i moderni sistemi unix-like permettono di bloccare tempora-
neamente (o di eliminare completamente, impostando SIG_IGN come azione) la consegna dei
segnali ad un processo. Questo è fatto specificando la cosiddetta maschera dei segnali (o signal
mask) del processo29 cioè l’insieme dei segnali la cui consegna è bloccata. Abbiamo accennato
in sez. 3.2.2 che la signal mask viene ereditata dal padre alla creazione di un processo figlio, e
abbiamo visto al paragrafo precedente che essa può essere modificata, durante l’esecuzione di un
gestore, attraverso l’uso dal campo sa_mask di sigaction.
Uno dei problemi evidenziatisi con l’esempio di fig. 9.7 è che in molti casi è necessario
proteggere delle sezioni di codice (nel caso in questione la sezione fra il controllo e la eventuale
cancellazione del flag che testimoniava l’avvenuta occorrenza del segnale) in modo da essere
sicuri che essi siano eseguite senza interruzioni.
Le operazioni più semplici, come l’assegnazione o il controllo di una variabile (per essere
sicuri si può usare il tipo sig_atomic_t) di norma sono atomiche; quando si devono eseguire
operazioni più complesse si può invece usare la funzione sigprocmask che permette di bloccare
uno o più segnali; il suo prototipo è:
#include <signal.h>
int sigprocmask(int how, const sigset_t *set, sigset_t *oldset)
Cambia la maschera dei segnali del processo corrente.
i valori:
EINVAL si è specificato un numero di segnale invalido.
La funzione usa l’insieme di segnali dato all’indirizzo set per modificare la maschera dei
segnali del processo corrente. La modifica viene effettuata a seconda del valore dell’argomento
how, secondo le modalità specificate in tab. 9.9. Qualora si specifichi un valore non nullo per
oldset la maschera dei segnali corrente viene salvata a quell’indirizzo.
Valore Significato
SIG_BLOCK L’insieme dei segnali bloccati è l’unione fra quello
specificato e quello corrente.
SIG_UNBLOCK I segnali specificati in set sono rimossi dalla maschera
dei segnali, specificare la cancellazione di un segnale non
bloccato è legale.
SIG_SETMASK La maschera dei segnali è impostata al valore specificato
da set.
Tabella 9.9: Valori e significato dell’argomento how della funzione sigprocmask.
28
la direttiva inline viene usata per dire al compilatore di trattare la funzione cui essa fa riferimento in maniera
speciale inserendo il codice direttamente nel testo del programma. Anche se i compilatori più moderni sono in grado
di effettuare da soli queste manipolazioni (impostando le opportune ottimizzazioni) questa è una tecnica usata
per migliorare le prestazioni per le funzioni piccole ed usate di frequente (in particolare nel kernel, dove in certi
casi le ottimizzazioni dal compilatore, tarate per l’uso in user space, non sono sempre adatte). In tal caso infatti
le istruzioni per creare un nuovo frame nello stack per chiamare la funzione costituirebbero una parte rilevante
del codice, appesantendo inutilmente il programma. Originariamente questo comportamento veniva ottenuto con
delle macro, ma queste hanno tutta una serie di problemi di sintassi nel passaggio degli argomenti (si veda ad
esempio [11]) che in questo modo possono essere evitati.
29
nel caso di Linux essa è mantenuta dal campo blocked della task_struct del processo.

In questo modo diventa possibile proteggere delle sezioni di codice bloccando l’insieme di
segnali voluto per poi riabilitarli alla fine della sezione critica. La funzione permette di risolvere
problemi come quelli mostrati in fig. 9.7, proteggendo la sezione fra il controllo del flag e la sua
cancellazione.
La funzione può essere usata anche all’interno di un gestore, ad esempio per riabilitare la
consegna del segnale che l’ha invocato, in questo caso però occorre ricordare che qualunque
modifica alla maschera dei segnali viene perduta alla conclusione del terminatore.
Benché con l’uso di sigprocmask si possano risolvere la maggior parte dei casi di race con-
dition restano aperte alcune possibilità legate all’uso di pause; il caso è simile a quello del
problema illustrato nell’esempio di fig. 9.6, e cioè la possibilità che il processo riceva il segnale
che si intende usare per uscire dallo stato di attesa invocato con pause immediatamente prima
dell’esecuzione di quest’ultima. Per poter effettuare atomicamente la modifica della maschera
dei segnali (di solito attivandone uno specifico) insieme alla sospensione del processo lo standard
POSIX ha previsto la funzione sigsuspend, il cui prototipo è:
#include <signal.h>
int sigsuspend(const sigset_t *mask)
Imposta la signal mask specificata, mettendo in attesa il processo.
i valori:
EINVAL si è specificato un numero di segnale invalido.
Come esempio dell’uso di queste funzioni proviamo a riscrivere un’altra volta l’esempio di
implementazione di sleep. Abbiamo accennato in sez. 9.4.3 come con sigaction sia possibile
bloccare SIGALRM nell’installazione dei gestori degli altri segnali, per poter usare l’implemen-
tazione vista in fig. 9.6 senza interferenze. Questo però comporta una precauzione ulteriore al
semplice uso della funzione, vediamo allora come usando la nuova interfaccia è possibile ottenere
un’implementazione, riportata in fig. 9.11 che non presenta neanche questa necessità.
Per evitare i problemi di interferenza con gli altri segnali in questo caso non si è usato
l’approccio di fig. 9.6 evitando l’uso di longjmp. Come in precedenza il gestore (27-30) non
esegue nessuna operazione, limitandosi a ritornare per interrompere il programma messo in
attesa.
La prima parte della funzione (6-10) provvede ad installare l’opportuno gestore per SIGALRM,
salvando quello originario, che sarà ripristinato alla conclusione della stessa (23); il passo succes-
sivo è quello di bloccare SIGALRM (11-14) per evitare che esso possa essere ricevuto dal processo
fra l’esecuzione di alarm (16) e la sospensione dello stesso. Nel fare questo si salva la maschera
corrente dei segnali, che sarà ripristinata alla fine (22), e al contempo si prepara la maschera dei
segnali sleep_mask per riattivare SIGALRM all’esecuzione di sigsuspend.
In questo modo non sono più possibili race condition dato che SIGALRM viene disabilitato
con sigprocmask fino alla chiamata di sigsuspend. Questo metodo è assolutamente generale e
può essere applicato a qualunque altra situazione in cui si deve attendere per un segnale, i passi
sono sempre i seguenti:
1. leggere la maschera dei segnali corrente e bloccare il segnale voluto con sigprocmask;
2. mandare il processo in attesa con sigsuspend abilitando la ricezione del segnale voluto;
3. ripristinare la maschera dei segnali originaria.
Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi riabilitarla im-
mediatamente dopo, in questo modo si evita il deadlock dovuto all’arrivo del segnale prima
dell’esecuzione di sigsuspend.

1 void alarm_hand(int);
3 {
4 struct sigaction new_action , old_action;
5 sigset_t old_mask , stop_mask , sleep_mask;
6 /* set the signal handler */
7 sigemptyset (& new_action.sa_mask ); /* no signal blocked */
8 new_action.sa_handler = alarm_hand; /* set handler */
9 new_action.sa_flags = 0; /* no flags */
10 sigaction(SIGALRM , &new_action , &old_action ); /* install action */
11 /* block SIGALRM to avoid race conditions */
12 sigemptyset (& stop_mask ); /* init mask to empty */
13 sigaddset (& stop_mask , SIGALRM ); /* add SIGALRM */
14 sigprocmask(SIG_BLOCK , &stop_mask , &old_mask ); /* add SIGALRM to blocked */
15 /* send the alarm */
16 alarm(seconds );
17 /* going to sleep enabling SIGALRM */
18 sleep_mask = old_mask; /* take mask */
19 sigdelset (& sleep_mask , SIGALRM ); /* remove SIGALRM */
20 sigsuspend (& sleep_mask ); /* go to sleep */
21 /* restore previous settings */
22 sigprocmask(SIG_SETMASK , &old_mask , NULL ); /* reset signal mask */
23 sigaction(SIGALRM , &old_action , NULL ); /* reset signal action */
24 /* return remaining time */
26 }
28 {
29 return; /* just return to interrupt sigsuspend */
30 }
Figura 9.11: Una implementazione completa di sleep.
9.4.5 Criteri di programmazione per i gestori dei segnali
Abbiamo finora parlato dei gestori dei segnali come funzioni chiamate in corrispondenza della
consegna di un segnale. In realtà un gestore non può essere una funzione qualunque, in quanto
esso può essere eseguito in corrispondenza all’interruzione in un punto qualunque del programma
principale, cosa che ad esempio può rendere problematico chiamare all’interno di un gestore di
segnali la stessa funzione che dal segnale è stata interrotta.
Il concetto è comunque più generale e porta ad una distinzione fra quelle che POSIX chiama
funzioni insicure (signal unsafe function) e funzioni sicure (o più precisamente signal safe func-
tion); quando un segnale interrompe una funzione insicura ed il gestore chiama al suo interno
una funzione insicura il sistema può dare luogo ad un comportamento indefinito, la cosa non
avviene invece per le funzioni sicure.
Tutto questo significa che la funzione che si usa come gestore di segnale deve essere pro-
grammata con molta cura per evirare questa evenienza e che non è possibile utilizzare al suo
interno una qualunque funzione di sistema, se si vogliono evitare questi problemi si può ricorrere
soltanto all’uso delle funzioni considerate sicure.
L’elenco delle funzioni considerate sicure varia a seconda della implementazione utilizzata e
dello standard a cui si fa riferimento;30 secondo quanto riportato dallo standard POSIX 1003.1
30
non è riportata una lista specifica delle funzioni sicure per Linux, si suppone pertanto che siano quelle richieste
dallo standard.

nella revisione del 2003, le “signal safe function” che possono essere chiamate anche all’interno
di un gestore di segnali sono tutte quelle della lista riportata in fig. 9.12.
_exit, abort, accept, access, aio_error aio_return, aio_suspend, alarm, bind, cfgetispeed,
cfgetospeed, cfsetispeed, cfsetospeed, chdir, chmod, chown, clock_gettime, close, connect,
creat, dup, dup2, execle, execve, fchmod, fchown, fcntl, fdatasync, fork, fpathconf, fstat,
fsync, ftruncate, getegid, geteuid, getgid, getgroups, getpeername, getpgrp, getpid, getppid,
getsockname, getsockopt, getuid, kill, link, listen, lseek, lstat, mkdir, mkfifo, open,
pathconf, pause, pipe, poll, posix_trace_event, pselect, raise, read, readlink, recv, recvfrom,
recvmsg, rename, rmdir, select, sem_post, send, sendmsg, sendto, setgid, setpgid, setsid,
setsockopt, setuid, shutdown, sigaction, sigaddset, sigdelset, sigemptyset, sigfillset,
sigismember, signal, sigpause, sigpending, sigprocmask, sigqueue, sigset, sigsuspend, sleep,
socket, socketpair, stat, symlink, sysconf, tcdrain, tcflow, tcflush, tcgetattr, tcgetgrp,
tcsendbreak, tcsetattr, tcsetpgrp, time, timer_getoverrun, timer_gettime, timer_settime,
times, umask, uname, unlink, utime, wait, waitpid, write.
Figura 9.12: Elenco delle funzioni sicure secondo lo standard POSIX 1003.1-2003.
Lo standard POSIX.1-2004 modifica la lista di fig. 9.12 aggiungendo le funzioni _Exit e
sockatmark, mentre lo standard POSIX.1-2008 rimuove della lista le tre funzioni fpathconf,
pathconf, sysconf e vi aggiunge le ulteriori funzioni in fig. 9.13.
execl, execv, faccessat, fchmodat, fchownat, fexecve, fstatat, futimens, linkat, mkdirat,
mkfifoat, mknod, mknodat, openat, readlinkat, renameat, symlinkat, unlinkat, utimensat,
utimes.
Figura 9.13: Ulteriori funzioni sicure secondo lo standard POSIX.1-2008.
Per questo motivo è opportuno mantenere al minimo indispensabile le operazioni effettuate
all’interno di un gestore di segnali, qualora si debbano compiere operazioni complesse è sempre
preferibile utilizzare la tecnica in cui si usa il gestore per impostare il valore di una qualche
variabile globale, e poi si eseguono le operazioni complesse nel programma verificando (con tutti
gli accorgimenti visti in precedenza) il valore di questa variabile tutte le volte che si è rilevata
una interruzione dovuta ad un segnale.
9.5 Funzionalità avanzate
Tratteremo in questa ultima sezione alcune funzionalità avanzate relativa ai segnali ed in generale
ai meccanismi di notifica, a partire dalla funzioni introdotte per la gestione dei cosiddetti“segnali
real-time”, alla gestione avanzata delle temporizzazioni e le nuove interfacce per la gestione di
segnali ed eventi attraverso l’uso di file descriptor.
9.5.1 I segnali real-time
Lo standard POSIX.1b, nel definire una serie di nuove interfacce per i servizi real-time, ha intro-
dotto una estensione del modello classico dei segnali che presenta dei significativi miglioramenti,31
in particolare sono stati superati tre limiti fondamentali dei segnali classici:
I segnali non sono accumulati
se più segnali vengono generati prima dell’esecuzione di un gestore questo sarà eseguito
una sola volta, ed il processo non sarà in grado di accorgersi di quante volte l’evento che
ha generato il segnale è accaduto;
31
questa estensione è stata introdotta in Linux a partire dal kernel 2.1.43, e dalle glibc 2.1.

9.5. FUNZIONALITÀ AVANZATE 291
I segnali non trasportano informazione
i segnali classici non prevedono altra informazione sull’evento che li ha generati se non il
fatto che sono stati emessi (tutta l’informazione che il kernel associa ad un segnale è il
suo numero);
I segnali non hanno un ordine di consegna
l’ordine in cui diversi segnali vengono consegnati è casuale e non prevedibile. Non è
possibile stabilire una priorità per cui la reazione a certi segnali ha la precedenza rispetto
ad altri.
Per poter superare queste limitazioni lo standard POSIX.1b ha introdotto delle nuove carat-
teristiche, che sono state associate ad una nuova classe di segnali, che vengono chiamati segnali
real-time, in particolare le funzionalità aggiunte sono:
1. i segnali sono inseriti in una coda che permette di consegnare istanze multiple dello stesso
segnale qualora esso venga inviato più volte prima dell’esecuzione del gestore; si assicura
cos`ı che il processo riceva un segnale per ogni occorrenza dell’evento che lo genera.
2. è stata introdotta una priorità nella consegna dei segnali: i segnali vengono consegnati in
ordine a seconda del loro valore, partendo da quelli con un numero minore, che pertanto
hanno una priorità maggiore.
3. è stata introdotta la possibilità di restituire dei dati al gestore, attraverso l’uso di un
apposito campo si_value nella struttura siginfo_t, accessibile tramite gestori di tipo
sa_sigaction.
Tutte queste nuove funzionalità eccetto l’ultima, che, come illustrato in sez. 9.4.3, è dispo-
nibile anche con i segnali ordinari, si applicano solo ai nuovi segnali real-time; questi ultimi
sono accessibili in un intervallo di valori specificati dalle due costanti SIGRTMIN e SIGRTMAX, che
specificano il numero minimo e massimo associato ad un segnale real-time.
Su Linux di solito il primo valore è 33, mentre il secondo è _NSIG-1, che di norma (vale
a dire sulla piattaforma i386) è 64. Questo dà un totale di 32 segnali disponibili, contro gli
almeno 8 richiesti da POSIX.1b. Si tenga presente però che i primi segnali real-time disponibili
vendono usati dalle glibc per l’implementazione dei thread POSIX (vedi sez. 13.2), ed il valore
di SIGRTMIN viene modificato di conseguenza.32
Per questo motivo nei programmi che usano i segnali real-time non si deve mai usare un
valore assoluto dato che si correrebbe il rischio di utilizzare un segnale in uso alle librerie, ed
il numero del segnale deve invece essere sempre specificato in forma relativa a SIGRTMIN (come
SIGRTMIN + n) avendo inoltre cura di controllare di non aver mai superato SIGRTMAX.
I segnali con un numero più basso hanno una priorità maggiore e vengono consegnati per
primi, inoltre i segnali real-time non possono interrompere l’esecuzione di un gestore di un segnale
a priorità più alta; la loro azione predefinita è quella di terminare il programma. I segnali ordinari
hanno tutti la stessa priorità, che è più alta di quella di qualunque segnale real-time.33
Si tenga presente che questi nuovi segnali non sono associati a nessun evento specifico, a
meno di non richiedere specificamente il loro utilizzo in meccanismi di notifica come quelli per
l’I/O asincrono (vedi sez. 12.3.3) o per le code di messaggi POSIX (vedi sez. 11.4.2); pertanto
devono essere inviati esplicitamente.
Inoltre, per poter usufruire della capacità di restituire dei dati, i relativi gestori devono essere
installati con sigaction, specificando per sa_flags la modalità SA_SIGINFO che permette di
32
vengono usati i primi tre per la vecchia implementazione dei LinuxThread ed i primi due per la nuova NTPL
(New Thread Posix Library), il che comporta che SIGRTMIN a seconda dei casi può essere 34 o 35.
33
lo standard non definisce niente al riguardo ma Linux, come molte altre implementazioni, adotta questa
politica.

utilizzare la forma estesa sa_sigaction (vedi sez. 9.4.3). In questo modo tutti i segnali real-
time possono restituire al gestore una serie di informazioni aggiuntive attraverso l’argomento
siginfo_t, la cui definizione è stata già vista in fig. 9.9, nella trattazione dei gestori in forma
estesa.
In particolare i campi utilizzati dai segnali real-time sono si_pid e si_uid in cui vengono
memorizzati rispettivamente il pid e l’user-ID effettivo del processo che ha inviato il segnale,
mentre per la restituzione dei dati viene usato il campo si_value.
typedef union sigval {
int sival_int;
void *sival_ptr;
} sigval_t;
Figura 9.14: La definizione dell’unione sigval, definita anche come tipo sigval_t.
Questo è una union di tipo sigval (la sua definizione è in fig. 9.14) in cui può essere
memorizzato o un valore numerico, se usata nella forma sival_int, o un indirizzo, se usata nella
forma sival_ptr. L’unione viene usata dai segnali real-time e da vari meccanismi di notifica34
per restituire dati al gestore del segnale; in alcune definizioni essa viene identificata anche con
l’abbreviazione sigval_t.
A causa delle loro caratteristiche, la funzione kill non è adatta ad inviare segnali real-time,
poiché non è in grado di fornire alcun valore per sigval; per questo motivo lo standard ha
previsto una nuova funzione, sigqueue, il cui prototipo è:
#include <signal.h>
int sigqueue(pid_t pid, int signo, const union sigval value)
Invia il segnale signo al processo pid, restituendo al gestore il valore value.
uno dei valori:
EAGAIN la coda è esaurita, ci sono già SIGQUEUE_MAX segnali in attesa si consegna.
EPERM non si hanno privilegi appropriati per inviare il segnale al processo specificato.
EINVAL si è specificato un valore non valido per signo.
ed inoltre ENOMEM.
Il comportamento della funzione è analogo a quello di kill, ed i privilegi occorrenti ad
inviare il segnale ad un determinato processo sono gli stessi; un valore nullo di signo permette
di veri-13.55 Tdpalcune de ’(n)28(u4on)1(o)-341(gl)1(i)-339(s[(s)1(i)11(li)1(ioa333(i)1(l)27(v)1(i)1(ar)1-332

la coda ha una dimensione variabile; fino alla versione 2.6.7 c’era un limite massimo globale che
poteva essere impostato come parametro del kernel in /proc/sys/kernel/rtsig-max;36 a parti-
re dal kernel 2.6.8 il valore globale è stato rimosso e sostituito dalla risorsa RLIMIT_SIGPENDING
associata al singolo utente, che può essere modificata con setrlimit come illustrato in sez. 8.3.2.
Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di gestire l’attesa
di segnali specifici su una coda, esse servono in particolar modo nel caso dei thread, in cui si
possono usare i segnali real-time come meccanismi di comunicazione elementare; la prima di
queste funzioni è sigwait, il cui prototipo è:
#include <signal.h>
int sigwait(const sigset_t *set, int *sig)
Attende che uno dei segnali specificati in set sia pendente.
uno dei valori:
EINTR la funzione è stata interrotta.
EINVAL si è specificato un valore non valido per set.
ed inoltre EFAULT.
La funzione estrae dall’insieme dei segnali pendenti uno qualunque dei segnali specificati
da set, il cui valore viene restituito in sig. Se sono pendenti più segnali, viene estratto quello
a priorità più alta (cioè con il numero più basso). Se, nel caso di segnali real-time, c’è più di
un segnale pendente, ne verrà estratto solo uno. Una volta estratto il segnale non verrà più
consegnato, e se era in una coda il suo posto sarà liberato. Se non c’è nessun segnale pendente
il processo viene bloccato fintanto che non ne arriva uno.
Per un funzionamento corretto la funzione richiede che alla sua chiamata i segnali di set
siano bloccati. In caso contrario si avrebbe un conflitto con gli eventuali gestori: pertanto non
si deve utilizzare per lo stesso segnale questa funzione e sigaction. Se questo non avviene
il comportamento del sistema è indeterminato: il segnale può sia essere consegnato che essere
ricevuto da sigwait, il tutto in maniera non prevedibile.
Lo standard POSIX.1b definisce altre due funzioni, anch’esse usate prevalentemente con i
thread; sigwaitinfo e sigtimedwait, i relativi prototipi sono:
#include <signal.h>
int sigwaitinfo(const sigset_t *set, siginfo_t *info)
Analoga a sigwait, ma riceve anche le informazioni associate al segnale in info.
int sigtimedwait(const sigset_t *set, siginfo_t *info, const struct timespec
*timeout)
Analoga a sigwaitinfo, con un la possibilità di specificare un timeout in timeout.
Le funzioni restituiscono 0 in caso di successo e −1 in caso di errore, nel qual caso errno assumerà
uno dei valori già visti per sigwait, ai quali si aggiunge, per sigtimedwait:
EAGAIN si è superato il timeout senza che un segnale atteso fosse emesso.
Entrambe le funzioni sono estensioni di sigwait. La prima permette di ricevere, oltre al
numero del segnale, anche le informazioni ad esso associate tramite info; in particolare viene
restituito il numero del segnale nel campo si_signo, la sua causa in si_code, e se il segnale è
stato immesso sulla coda con sigqueue, il valore di ritorno ad esso associato viene riportato in
si_value, che altrimenti è indefinito.
La seconda è identica alla prima ma in più permette di specificare un timeout, scaduto il
quale ritornerà con un errore. Se si specifica un puntatore nullo il comportamento sarà identico a
sigwaitinfo, se si specifica un tempo di timeout nullo, e non ci sono segnali pendenti la funzione
ritornerà immediatamente; in questo modo si può eliminare un segnale dalla coda senza dover
essere bloccati qualora esso non sia presente.
36
ed il valore predefinito era pari a 1024.

L’uso di queste funzioni è principalmente associato alla gestione dei segnali con i thread. In
genere esse vengono chiamate dal thread incaricato della gestione, che al ritorno della funzione
esegue il codice che usualmente sarebbe messo nel gestore, per poi ripetere la chiamata per
mettersi in attesa del segnale successivo. Questo ovviamente comporta che non devono essere
installati gestori, che solo il thread di gestione deve usare sigwait e che i segnali gestiti in questa
maniera, per evitare che venga eseguita l’azione predefinita, devono essere mascherati per tutti i
thread, compreso quello dedicato alla gestione, che potrebbe riceverlo fra due chiamate successive.
9.5.2 La gestione avanzata delle temporizzazioni
Sia le funzioni per la gestione dei tempi viste in sez. 8.4.2 che quelle per la gestione dei timer
di sez. 9.3.4 sono state a lungo limitate dalla risoluzione massima dei tempi dell’orologio interno
del kernel, che era quella ottenibile dal timer di sistema che governa lo scheduler,37 i contatori
usati per il calcolo dei tempo infatti erano basati sul numero di jiffies che vengono incrementati
ad ogni clock tick del timer di sistema.38
Nelle architetture moderne però tutti i computer sono dotati di temporizzatori hardware che
possono supportare risoluzioni molto elevate, ed in maniera del tutto indipendente dalla frequen-
za scelta per il timer di sistema che governa lo scheduler;39 per questo lo standard POSIX.1-2001
ha previsto una serie di nuove funzioni relative a quelli che vengono chiamati “orologi real-time”,
in grado di supportare risoluzioni fino al nanosecondo. Inoltre le CPU più moderne sono dotate
a loro volta di contatori ad alta definizione che consentono una grande accuratezza nella misura
del tempo da esse dedicato all’esecuzione di un processo.
Per usare queste funzionalità ed ottenere risoluzioni temporali più accurate, occorre però un
opportuno supporto da parte del kernel, ed i cosiddetti high resolution timer che consentono di
fare ciò sono stati introdotti nel kernel ufficiale solo a partire dalla versione 2.6.21.40 Le funzioni
definite dallo standard POSIX per gestire orologi ad alta definizione però erano già presenti,
essendo stata introdotte insieme ad altre funzioni per il supporto delle estensioni real-time con
il rilascio del kernel 2.6, ma la risoluzione effettiva era nominale.
A tutte le implementazioni che si rifanno a queste estensioni è richiesto di disporre di una
versione real-time almeno per l’orologio generale di sistema, quello che mantiene il calendar time
(vedi sez. 8.4.3), che in questa forma deve indicare il numero di secondi e nanosecondi passati
a partire dal primo gennaio 1970 (The Epoch).41 Oltre all’orologio generale di sistema possono
essere presenti altri tipi di orologi real-time, ciascuno dei quali viene identificato da un opportuno
valore di una variabile di tipo clockid_t; un elenco di quelli disponibili su Linux è riportato in
tab. 9.10.
Per poter utilizzare queste funzionalità le glibc richiedono che la macro _POSIX_C_SOURCE
sia definita ad un valore maggiore o uguale di 199309L (vedi sez. 1.2.7), inoltre i programmi che
le usano devono essere collegati con la libreria delle estensioni real-time usando esplicitamente
l’opzione -lrt. Si tenga presente inoltre che la disponibilità di queste funzionalità avanzate può
37
e quindi limitate dalla frequenza dello stesso che si ricordi, come già illustrato in sez. 3.1.1, è data dal valore
della costante HZ.
38
il che comportava anche, come accennato in sez. 9.3.4 per setitimer, problemi per il massimo periodo di
tempo copribile da alcuni di questi orologi, come quelli associati al process time almeno fino a quando, con il
kernel 2.6.16, non è stato rimosso il limite di un valore a 32 bit per i jiffies.
39
normalmente si possono ottenere precisioni fino al microsecondo, andando molto oltre in caso di hardware
dedicato.
40
deve essere stata abilitata l’opzione di compilazione CONFIG_HIGH_RES_TIMERS, erano però disponibili anche in
precedenza come patch facenti parte dello sviluppo delle estensioni real-time del kernel, per cui alcune distribuzioni
possono avere questo supporto anche con versioni precedenti del kernel.
41
si ricordi che l’orologio ordinario usato dal calendar time riporta solo un numero di secondi, e che la risoluzione
effettiva normalmente non raggiunge il nanosecondo (a meno di hardware specializzato).
42
specifico di Linux, introdotto a partire dal kernel 2.6.28, non previsto da POSIX e non presente in altri sistemi
unix-like.

Valore Significato
CLOCK_REALTIME Orologio real-time di sistema, può essere impostato solo
con privilegi amministrativi.
CLOCK_MONOTONIC Orologio che indica un tempo monotono crescente (a
partire da un tempo iniziale non specificato) che non
può essere modificato e non cambia neanche in caso di
reimpostazione dell’orologio di sistema.
CLOCK_MONOTONIC_RAW Simile al precedente, ma non subisce gli aggiustamenti
dovuti all’uso di NTP (viene usato per fare riferimento
ad una fonte hardware).42
CLOCK_PROCESS_CPUTIME_ID contatore del tempo di CPU usato da un processo (il
process time di sez. 8.4.2, nel totale di system time e user
time) comprensivo di tutto il tempo di CPU usato da
eventuali thread.
CLOCK_THREAD_CPUTIME_ID contatore del tempo di CPU (user time e system time)
usato da un singolo thread.
Tabella 9.10: Valori possibili per una variabile di tipo clockid_t usata per indicare a quale tipo di orologio si
vuole fare riferimento.
essere controllato dalla definizione della macro _POSIX_TIMERS ad un valore maggiore di 0, e che
le ulteriori macro _POSIX_MONOTONIC_CLOCK, _POSIX_CPUTIME e _POSIX_THREAD_CPUTIME indi-
cano la presenza dei rispettivi orologi di tipo CLOCK_MONOTONIC, CLOCK_PROCESS_CPUTIME_ID e
CLOCK_PROCESS_CPUTIME_ID.43 Infine se il kernel ha il supporto per gli high resolution timer un
elenco degli orologi e dei timer può essere ottenuto tramite il file /proc/timer_list.
Le due funzioni che ci consentono rispettivamente di modificare o leggere il valore per uno
degli orologi real-time sono clock_settime e clock_gettime; i rispettivi prototipi sono:
#include <time.h>
int clock_settime(clockid_t clockid, const struct timespec *tp)
int clock_gettime(clockid_t clockid, struct timespec *tp)
Imposta o legge un orologio real-time.
uno dei seguenti valori:
EINVAL il valore specificato per clockid non è valido o il relativo orologio real-time non è
supportato dal sistema.
EPERM non si ha il permesso di impostare l’orologio indicato (solo per clock_settime).
EFAULT l’indirizzo tp non è valido.
Entrambe le funzioni richiedono che si specifichi come primo argomento il tipo di orologio
su cui si vuole operare con uno dei valori di tab. 9.10 o con il risultato di una chiamata a
clock_getcpuclockid (che tratteremo a breve), il secondo argomento invece è sempre il punta-
tore tp ad una struttura timespec (vedi fig. 5.8) che deve essere stata precedentemente allocata;
nel primo caso questa dovrà anche essere stata inizializzata con il valore che si vuole impostare
sull’orologio, mentre nel secondo verrà restituito al suo interno il valore corrente dello stesso.
Si tenga presente inoltre che per eseguire un cambiamento sull’orologio generale di sistema
CLOCK_REALTIME occorrono i privilegi amministrativi;44 inoltre ogni cambiamento ad esso ap-
portato non avrà nessun effetto sulle temporizzazioni effettuate in forma relativa, come quelle
impostate sulle quantità di process time o per un intervallo di tempo da trascorrere, ma solo
su quelle che hanno richiesto una temporizzazione ad un istante preciso (in termini di calendar
time). Si tenga inoltre presente che nel caso di Linux CLOCK_REALTIME è l’unico orologio per cui
43
tutte queste macro sono definite in unistd.h, che pertanto deve essere incluso per poterle controllarle.
44
ed in particolare la capability CAP_SYS_TIME.

si può effettuare una modifica, infatti nonostante lo standard preveda la possibilità di modifiche
anche per CLOCK_PROCESS_CPUTIME_ID e CLOCK_THREAD_CPUTIME_ID, il kernel non le consente.
Oltre alle due funzioni precedenti, lo standard POSIX prevede una terza funzione che con-
senta di ottenere la risoluzione effettiva fornita da un certo orologio, la funzione è clock_getres
ed il suo prototipo è:
#include <time.h>
int clock_getres(clockid_t clockid, struct timespec *res)
Legge la risoluzione di un orologio real-time.
uno dei seguenti valori:
EINVAL il valore specificato per clockid non è valido.
EFAULT l’indirizzo di res non è valido.
La funzione richiede come primo argomento l’indicazione dell’orologio di cui si vuole conoscere
la risoluzione (effettuata allo stesso modo delle due precedenti) e questa verrà restituita in una
struttura timespec all’indirizzo puntato dall’argomento res.
Come accennato il valore di questa risoluzione dipende sia dall’hardware disponibile che dalla
implementazione delle funzioni, e costituisce il limite minimo di un intervallo di tempo che si può
indicare. Qualunque valore si voglia utilizzare nelle funzioni di impostazione che non corrisponda
ad un multiplo intero di questa risoluzione, sarà troncato in maniera automatica.
Si tenga presente inoltre che con l’introduzione degli high resolution timer i due orologi
CLOCK_PROCESS_CPUTIME_ID e CLOCK_THREAD_CPUTIME_ID fanno riferimento ai contatori pre-
senti in opportuni registri interni del processore; questo sui sistemi multiprocessore può avere
delle ripercussioni sulla precisione delle misure di tempo che vanno al di là della risoluzione
teorica ottenibile con clock_getres, che può essere ottenuta soltanto quando si è sicuri che un
processo (o un thread) sia sempre stato eseguito sullo stesso processore.
Con i sistemi multiprocessore infatti ogni singola CPU ha i suoi registri interni, e se ciascu-
na di esse utilizza una base di tempo diversa (se cioè il segnale di temporizzazione inviato ai
processori non ha una sola provenienza) in genere ciascuna di queste potrà avere delle frequenze
leggermente diverse, e si otterranno pertanto dei valori dei contatori scorrelati fra loro, senza
nessuna possibilità di sincronizzazione.
Il problema si presenta, in forma più lieve, anche se la base di tempo è la stessa, dato che
un sistema multiprocessore non avvia mai tutte le CPU allo stesso istante, si potrà cos`ı avere
di nuovo una differenza fra i contatori, soggetta però soltanto ad uno sfasamento costante. Per
questo caso il kernel per alcune architetture ha del codice che consente di ridurre al minimo
la differenza, ma non può essere comunque garantito che questa si annulli (anche se in genere
risulta molto piccola e trascurabile nella gran parte dei casi).
Per poter gestire questo tipo di problematiche lo standard ha previsto una apposita funzione
che sia in grado di ottenere l’identificativo dell’orologio associato al process time di un processo,
la funzione è clock_getcpuclockid ed il suo prototipo è:
#include <time.h>
int clock_getcpuclockid(pid_t pid, clockid_t *clockid)
Ottiene l’identificatore dell’orologio di CPU usato da un processo.
La funzione restituisce 0 in caso di successo o un numero positivo in caso di errore, nel qual caso
errno assumerà uno dei seguenti valori:
ENOSYS non c’è il supporto per ottenere l’orologio relativo al process time di un altro processo,
e pid non corrisponde al processo corrente.
EPERM il chiamante non ha il permesso di accedere alle informazioni relative al processo pid.
ESRCH non esiste il processo pid.

La funzione ritorna l’identificativo di un orologio di sistema associato ad un processo indicato
tramite l’argomento pid. Un utente normale, posto che il kernel sia sufficientemente recente da
supportare questa funzionalità, può accedere soltanto ai dati relativi ai propri processi.
Del tutto analoga a clock_getcpuclockid, ma da utilizzare per ottenere l’orologio associato
ad un thread invece che a un processo, è pthread_getcpuclockid,45 il cui prototipo è:
#include <pthread.h>
#include <time.h>
int pthread_getcpuclockid(pthread_t thread, clockid_t *clockid)
Ottiene l’identificatore dell’orologio di CPU associato ad un thread.
La funzione restituisce 0 in caso di successo o un numero positivo in caso di errore, nel qual caso
errno assumerà uno dei seguenti valori:
ENOENT la funzione non è supportata dal sistema.
ESRCH non esiste il thread identificato da thread.
Con l’introduzione degli orologi ad alta risoluzione è divenuto possibile ottenere anche una ge-
stione più avanzata degli allarmi; abbiamo già visto in sez. 9.3.4 come l’interfaccia di setitimer
derivata da BSD presenti delle serie limitazioni,46 tanto che nello standard POSIX.1-2008 questa
viene marcata come obsoleta, e ne viene fortemente consigliata la sostituzione con nuova inter-
faccia definita dallo standard POSIX.1-2001 che va sotto il nome di Posix Timer API. Questa
interfaccia è stata introdotta a partire dal kernel 2.6, anche se il supporto di varie funzionalità
è stato a

GaPiL - Guida alla Programmazione in Linux

More Related Content

What's hot (20)

Similar to GaPiL - Guida alla Programmazione in Linux (19)

More from AmmLibera AL (20)

GaPiL - Guida alla Programmazione in Linux