%% intro.tex
%%
-%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2015 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",
\label{fig:intro_sys_struct}
\end{figure}
-Una parte del kernel, lo \itindex{scheduler} \textit{scheduler}, si occupa di
-stabilire, sulla base di un opportuno calcolo delle priorità e con una
-suddivisione appropriata del tempo di processore, quali fra i vari
-``\textsl{processi}'' presenti nel sistema deve essere eseguito, realizzando
-il cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
+\itindbeg{scheduler}
+
+Una parte del kernel, lo \textit{scheduler}, si occupa di stabilire, sulla
+base di un opportuno calcolo delle priorità e con una suddivisione appropriata
+del tempo di processore, quali fra i vari ``\textsl{processi}'' presenti nel
+sistema deve essere eseguito, realizzando il cosiddetto
+\itindex{preemptive~multitasking} \textit{preemptive
multitasking}.\footnote{si chiama così quella gestione del
\textit{multitasking} in cui è il kernel a decidere a chi assegnare l'uso
della CPU, potendo interrompere l'esecuzione di un processo in qualunque
sez.~\ref{sec:intro_syscall}) che restituiranno il controllo al kernel per
eseguire le operazioni necessarie.
+\itindend{scheduler}
+
La memoria viene sempre gestita dal kernel attraverso il meccanismo della
\index{memoria~virtuale} \textsl{memoria virtuale}, che consente di assegnare
a ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi
\textit{system call} sono poi state codificate da vari standard, che
esamineremo brevemente in sez.~\ref{sec:intro_standard}.
-Normalmente ciascuna chiamata al sistema fornita dal kernel viene associata ad
-una funzione con lo stesso nome definita all'interno della libreria
+Normalmente ciascuna \textit{system call} fornita dal kernel viene associata
+ad una funzione con lo stesso nome definita all'interno della libreria
fondamentale del sistema, quella che viene chiamata \textsl{Libreria Standard
del C} (\textit{C Standard Library}) in ragione del fatto che il primo
kernel Unix e tutti i programmi eseguiti su di esso vennero scritti in C,
-usando le librerie di questo linguaggio. Questa libreria, oltre alle
-interfacce delle \textit{system call}, contiene anche tutta una serie di
-ulteriori funzioni di utilità che vengono comunemente usate nella
-programmazione e sono definite nei vari standard che documentano le interfacce
-di programmazione di un sistema unix-like.
-
-Questo concetto è importante da tener presente perché programmare in Linux
-significa anzitutto essere in grado di usare le funzioni fornite dalla
-\textsl{Libreria Standard del C}, in quanto né il kernel, né il linguaggio C
-implementano direttamente operazioni ordinarie come l'allocazione dinamica
-della memoria, l'input/output bufferizzato sui file o la manipolazione delle
-stringhe, che sono comunemente usate da qualunque programma.
+usando le librerie di questo linguaggio. In seguito faremo riferimento alle
+funzioni di questa libreria che si interfacciano alle \textit{system call}
+come ``\textsl{funzioni di sistema}''.
+
+Questa libreria infatti, oltre alle interfacce delle \textit{system call},
+contiene anche tutta una serie di ulteriori funzioni di utilità che vengono
+comunemente usate nella programmazione e sono definite nei vari standard che
+documentano le interfacce di programmazione di un sistema unix-like. Questo
+concetto è importante da tener presente perché programmare in Linux significa
+anche essere in grado di usare le funzioni fornite dalla \textsl{Libreria
+ Standard del C}, in quanto né il kernel, né il linguaggio C implementano
+direttamente operazioni ordinarie come l'allocazione dinamica della memoria,
+l'input/output bufferizzato sui file o la manipolazione delle stringhe, la
+matematica in virgola mobile, che sono comunemente usate da qualunque
+programma.
Tutto ciò mette nuovamente in evidenza il fatto che nella stragrande
maggioranza dei casi si dovrebbe usare il nome GNU/Linux in quanto una parte
la cui corrispondenza ad un nome espresso in caratteri è inserita nei due file
\conffile{/etc/passwd} e \conffile{/etc/group}.\footnote{in realtà negli
sistemi più moderni, come vedremo in sez.~\ref{sec:sys_user_group} queste
- informazioni possono essere mantenute, con l'uso del
- \itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch}, su varie
- tipologie di supporti, compresi server centralizzati come LDAP.} Questi
-identificativi sono l'\textit{user identifier}, detto in breve
-\textsl{user-ID}, ed indicato dall'acronimo \ids{UID}, e il \textit{group
- identifier}, detto in breve \textsl{group-ID}, ed identificato dall'acronimo
-\ids{GID}, torneremo in dettaglio su questo argomento in
+ informazioni possono essere mantenute, con l'uso del \textit{Name Service
+ Switch}, su varie tipologie di supporti, compresi server centralizzati
+ come LDAP.} Questi identificativi sono l'\textit{user identifier}, detto in
+breve \textsl{user-ID}, ed indicato dall'acronimo \ids{UID}, e il
+\textit{group identifier}, detto in breve \textsl{group-ID}, ed identificato
+dall'acronimo \ids{GID}, torneremo in dettaglio su questo argomento in
sez.~\ref{sec:proc_perms}. Il kernel conosce ed utilizza soltanto questi
valori numerici, i nomi ad essi associati sono interamente gestiti in
\textit{user space} con opportune funzioni di libreria, torneremo su questo
scrivere il contenuto. Tutto ciò ha due aspetti: il primo è che il kernel, per
il concetto dell'\textit{everything is a file}, deve fornire una interfaccia
che consenta di operare sui file, sia che questi corrispondano ai normali file
-di dati, sia che siano quei file speciali (i cosiddetti
-\index{file!di~dispositivo} file di dispositivo, o \textit{device file}) che
-permettono di accedere alle periferiche.
+di dati, o ai cosiddetti \index{file!speciali} ``\textsl{file speciali}'',
+come \index{file!di~dispositivo} i file di dispositivo (o \textit{device
+ file}) che permettono di accedere alle periferiche o le fifo ed i socket che
+forniscono funzionalità di comunicazione fra processi.
Il secondo aspetto è che per poter utilizzare dei normali file di dati il
kernel deve provvedere ad organizzare e rendere accessibile in maniera
\end{figure}
Questa interfaccia resta la stessa anche quando, invece che a dei normali
-file, si accede alle periferiche coi citati \index{file!di~dispositivo} file
-di dispositivo, solo che in questo caso invece di usare il codice del
-filesystem che accede al disco, il \textit{Virtual File System} eseguirà
-direttamente il codice del kernel che permette di accedere alla periferica.
+file, si accede alle periferiche coi citati file di dispositivo, solo che in
+questo caso invece di usare il codice del filesystem che accede al disco, il
+\textit{Virtual File System} eseguirà direttamente il codice del kernel che
+permette di accedere alla periferica.
\itindend{Virtual~File~System}
Tutti gli ulteriori filesystem che possono essere disponibili su altri
dispositivi dovranno a loro volta essere inseriti nell'albero, montandoli su
altrettante directory del filesystem radice, su quelli che vengono chiamati
-\index{mount~point} \textit{mount point}. Questo comunque avverrà sempre in
-un secondo tempo, in genere a cura dei programmi eseguiti nella procedura di
-inizializzazione del sistema, grazie alle funzioni che tratteremo in
-sez.~\ref{sec:sys_file_config}.
+\textit{mount point}. Questo comunque avverrà sempre in un secondo tempo, in
+genere a cura dei programmi eseguiti nella procedura di inizializzazione del
+sistema, grazie alle funzioni che tratteremo in
+sez.~\ref{sec:filesystem_mounting}.
\subsection{La risoluzione del nome di file e directory}
di \textit{filename} e di componente per il nome del file all'interno della
directory. Non seguiremo questa scelta dato che l'uso della parola
\textit{pathname} è ormai così comune che mantenerne l'uso è senz'altro più
- chiaro dell'alternativa proposta.} vale a dire tramite il percorso che si
-deve fare per accedere al file a partire da una certa ``\textit{directory}''.
+ chiaro dell'alternativa proposta.} vale a dire tramite il
+``\textsl{percorso}'' (nome che talvolta viene usato come traduzione di
+\textit{pathname}) che si deve fare per accedere al file a partire da una
+certa ``\textit{directory}''.
-Una directory in realta è anch'essa un file, nel senso che è anch'essa un
+Una directory in realtà è anch'essa un file, nel senso che è anch'essa un
oggetto di un filesystem, solo che è un file particolare che il kernel
riconosce appositamente come tale per poterlo utilizzare come directory. Il
suo scopo è quello di contenere una lista di nomi di file e le informazioni
-che associano ciascuno di questi nomi al relativo contenuto.
+che associano ciascuno di questi nomi al relativo contenuto (torneremo su
+questo in sez.~\ref{sec:file_arch_func}).
Dato che questi nomi possono corrispondere ad un qualunque altro oggetto del
filesystem, compresa un'altra directory, si ottiene naturalmente
un'organizzazione ad albero inserendo nomi di directory dentro altre
directory. All'interno dello stesso albero si potranno poi inserire anche
-tutti gli altri oggetti previsti l'interfaccia del VFS (su cui torneremo in
-sez.~\ref{sec:file_file_types}), come le fifo, i link, i socket e gli stessi
-\index{file!di~dispositivo} file di dispositivo.
+tutti gli altri oggetti previsti l'interfaccia del
+\itindex{Virtual~File~System} VFS (su cui torneremo in
+sez.~\ref{sec:file_file_types}), come le fifo, i collegamenti simbolici, i
+socket e gli stessi file di dispositivo.
La convenzione usata nei sistemi unix-like per indicare i \textit{pathname}
dei file è quella di usare il carattere ``\texttt{/}'' come separatore fra i
Un file può essere indicato rispetto ad una directory semplicemente
specificandone il nome, il manuale della \acr{glibc} chiama i nomi contenuti
-nelle directory \textsl{componenti} (in inglese \textit{file name
- components}), noi li chiameremo più semplicemente \textsl{nomi} o
-\textsl{voci}. Il procedimento con cui dato un \textit{pathname} si individua
-il file a cui esso fa riferimento è chiamato risoluzione del nome
-(\textit{filename resolution} o \textit{pathname resolution}).
-
-La risoluzione viene fatta esaminando il \textit{pathname} da sinistra a
-destra e localizzando ogni nome nella directory indicata dal nome precedente
-usando il carattere ``\texttt{/}'' come separatore. Nel caso si indichi un
-nome vuoto il costrutto ``\texttt{//}'' viene considerato equivalente a
-``\texttt{/}''. Ovviamente perché il procedimento funzioni occorre che i nomi
-indicati come directory esistano e siano effettivamente directory, inoltre i
-permessi (si veda sez.~\ref{sec:file_access_control}) devono consentire
-l'accesso all'intero \textit{pathname}.
+nelle directory ``componenti'' (in inglese \textit{file name components}), noi
+li chiameremo più semplicemente \textsl{nomi} o \textsl{voci}, riservando la
+parola \textsl{componenti} ai nomi che, separati da una ``\texttt{/}'',
+costituiscono il \textit{pathname}. Questi poi dovranno corrispondere, perché
+il \textit{pathname} sia valido, a voci effettivamente presenti nelle
+directory, ma non è detto che un \textit{pathname} debba per forza risultare
+valido.
+
+Il procedimento con cui dato un \textit{pathname} si individua il file a cui
+esso fa riferimento, è chiamato \textsl{risoluzione del percorso}
+(\textit{filename resolution} o \textit{pathname resolution}). Lo stesso
+procedimento ci può anche dire che il \textit{pathname} usato non è valido.
+La risoluzione viene eseguita esaminando il \textit{pathname} da sinistra a
+destra e localizzando ogni componente dello stesso come nome in una directory
+a partire dalla directory iniziale, usando il carattere ``\texttt{/}'' come
+separatore per scendere dall'una all'altra. Nel caso si indichi un componente
+vuoto il costrutto ``\texttt{//}'' viene considerato equivalente a
+``\texttt{/}''.
+
+Ovviamente perché la risoluzione abbia successo occorre che i componenti
+intermedi esistano e siano effettivamente directory, e che il file o la
+directory indicata dall'ultimo componente esista. Inoltre i permessi relativi
+alle directory indicate nel \textit{pathname} (torneremo su questo
+sez.~\ref{sec:file_access_control}) dovranno consentire l'accesso all'intero
+\textit{pathname}.
Se il \textit{pathname} comincia con il carattere ``\texttt{/}'' la ricerca
parte dalla directory radice del processo. Questa, a meno di non avere
eseguito una \func{chroot} (funzione su cui torneremo in
sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
-directory radice dell'albero dei file; in questo caso si parla di un
-\textsl{pathname assoluto} \itindsub{pathname}{assoluto}. Altrimenti la
-ricerca parte dalla \index{directory~di~lavoro} directory di lavoro corrente
-del processo (su cui torneremo in sez.~\ref{sec:file_work_dir}) ed il
-\textit{pathname} è detto \itindsub{pathname}{relativo} \textsl{pathname
- relativo}.
+directory radice dell'albero dei file montata dal kernel all'avvio del
+sistema; in questo caso si parla di un \textsl{pathname assoluto}
+\itindsub{pathname}{assoluto}. Altrimenti la ricerca parte dalla
+\index{directory~di~lavoro} directory di lavoro corrente del processo (su cui
+torneremo in sez.~\ref{sec:file_work_dir}) ed il \textit{pathname} è detto
+\itindsub{pathname}{relativo} \textsl{pathname relativo}.
Infine i nomi di directory ``\file{.}'' e ``\file{..}'' hanno un significato
speciale e vengono inseriti in ogni directory quando questa viene creata (vedi
corrente.
In questo modo con ``\file{..}'' si può usare un \itindsub{pathname}{relativo}
-pathname relativo per indicare un file posto al di sopra della directory
-corrente, tornando all'indietro nell'albero dei file. Questa retromarcia però
-su fermerà una volta raggiunta la directory radice, perché non esistendo in
-questo caso una directory superiore, il nome ``\file{..}'' farà riferimento
-alla radice stessa.
+\textit{pathname} relativo per indicare un file posto al di sopra della
+directory corrente, tornando all'indietro nell'albero dei file. Questa
+retromarcia però su fermerà una volta raggiunta la directory radice, perché
+non esistendo in questo caso una directory superiore, il nome ``\file{..}''
+farà riferimento alla radice stessa.
\itindend{pathname}
\itindend{pathname~resolution}
\multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
\hline
\hline
- \textit{regular file} & \textsl{file regolare} &
- Un file che contiene dei dati (l'accezione normale di file).\\
- \textit{directory} & \textsl{cartella o direttorio} &
- Un file che contiene una lista di nomi associati a degli
- \itindex{inode} \textit{inode} (vedi sez.~\ref{sec:file_vfs_work}).\\
- \textit{symbolic link} & \textsl{collegamento simbolico} &
- Un file che contiene un riferimento ad un altro file/directory.\\
- \textit{char device} & \textsl{dispositivo a caratteri} &
- Un file \textsl{speciale} che identifica una periferica ad accesso a
- caratteri.\\
- \textit{block device} & \textsl{dispositivo a blocchi} &
- Un file \textsl{speciale} che identifica una periferica ad accesso a
- blocchi.\\
- \textit{fifo} & ``\textsl{coda}'' &
- Un file \textsl{speciale} che identifica una linea di comunicazione
- unidirezionale (vedi sez.~\ref{sec:ipc_named_pipe}).\\
- \textit{socket} & ``\textsl{presa}''&
- Un file \textsl{speciale} che identifica una linea di comunicazione
- bidirezionale (vedi cap.~\ref{cha:socket_intro}).\\
+ \textit{regular file} & \textsl{file regolare} & Un file che contiene dei dati (l'accezione
+ normale di file).\\
+ \textit{directory} & \textsl{cartella o direttorio} & Un file che contiene una lista
+ di nomi associati a degli
+ \textit{inode} (vedi
+ sez.~\ref{sec:file_vfs_work}).\\
+ \textit{symbolic link} & \textsl{collegamento simbolico} & Un file che contiene un
+ riferimento ad un altro
+ file/directory.\\
+ \textit{char device} & \textsl{dispositivo a caratteri} & Un file \textsl{speciale}
+ che identifica una periferica
+ ad accesso a caratteri.\\
+ \textit{block device} & \textsl{dispositivo a blocchi} & Un file \textsl{speciale}
+ che identifica una periferica
+ ad accesso a blocchi.\\
+ \textit{fifo} & ``\textsl{coda}'' & Un file \textsl{speciale} che
+ identifica una linea di comunicazione
+ unidirezionale (vedi sez.~\ref{sec:ipc_named_pipe}).\\
+ \textit{socket} & ``\textsl{presa}''& Un file \textsl{speciale} che identifica una linea di
+ comunicazione bidirezionale (vedi
+ cap.~\ref{cha:socket_intro}).\\
\hline
\end{tabular}
\caption{Tipologia dei file definiti nel VFS}
sono rappresentati da numeri interi (cioè semplici variabili di tipo
\ctyp{int}). L'interfaccia è definita nell'\textit{header file}
\headfile{unistd.h} e la tratteremo in dettaglio in
-cap.~\ref{cha:file_unix_interface}.
+sez.~\ref{sec:file_unix_interface}.
\itindbeg{file~stream}
puntatori ad un opportuna struttura definita dalle librerie del C, ad essi si
accede sempre in maniera indiretta utilizzando il tipo \code{FILE *}.
L'interfaccia è definita nell'\textit{header file} \headfile{stdio.h} e la
-tratteremo in dettaglio nel cap.~\ref{cha:files_std_interface}.
+tratteremo in dettaglio in sez.~\ref{sec:files_std_interface}.
Entrambe le interfacce possono essere usate per l'accesso ai file come agli
altri oggetti del VFS, ma per poter accedere alle operazioni di controllo
-(descritte in sez.~\ref{sec:file_fcntl} e sez.~\ref{sec:file_ioctl}) 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
-\itindex{file~locking} \textit{file locking} o l'I/O non-bloccante (vedi
+(descritte in sez.~\ref{sec:file_fcntl_ioctl}) 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 \itindex{file~locking}
+\textit{file locking} o l'I/O non-bloccante (vedi
cap.~\ref{cha:file_advanced}).
Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
\type{dev\_t} & Numero di dispositivo (vedi sez.~\ref{sec:file_mknod}).\\
\type{gid\_t} & Identificatore di un gruppo (vedi
sez.~\ref{sec:proc_access_id}).\\
- \type{ino\_t} & Numero di \itindex{inode} \textit{inode}.\\
+ \type{ino\_t} & Numero di \textit{inode}
+ (vedi sez.~\ref{sec:file_vfs_work}).\\
\type{key\_t} & Chiave per il System V IPC (vedi
sez.~\ref{sec:ipc_sysv_generic}).\\
\type{loff\_t} & Posizione corrente in un file.\\
\type{mode\_t} & Attributi di un file.\\
- \type{nlink\_t} & Contatore dei link su un file.\\
+ \type{nlink\_t} & Contatore dei collegamenti su un file.\\
\type{off\_t} & Posizione corrente in un file.\\
\type{pid\_t} & Identificatore di un processo (vedi
sez.~\ref{sec:proc_pid}).\\
\type{size\_t} & Dimensione di un oggetto.\\
\type{ssize\_t} & Dimensione in numero di byte ritornata dalle funzioni.\\
\type{ptrdiff\_t}& Differenza fra due puntatori.\\
- \type{time\_t} & Numero di secondi (in \itindex{calendar~time}
- \textit{calendar time}, vedi
+ \type{time\_t} & Numero di secondi (in \textit{calendar time}, vedi
sez.~\ref{sec:sys_time}).\\
\type{uid\_t} & Identificatore di un utente (vedi
sez.~\ref{sec:proc_access_id}).\\
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
+serie di estensioni e interfacce di grandissima rilevanza, come i collegamenti
simbolici, la funzione \code{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.
\textbf{Standard} & \textbf{IEEE} & \textbf{ISO} & \textbf{Contenuto} \\
\hline
\hline
- 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 & --- & \itindex{thread} 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 \\
+ 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 & --- & \itindex{thread} 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. \\
\hline
\end{tabular}
\caption{Elenco dei vari standard POSIX e relative denominazioni.}
Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
-\itindex{thread} \textit{thread} (vedi cap.~\ref{cha:threads}), e dallo
-standard POSIX.1b per quanto riguarda i segnali e lo \itindex{scheduler}
-scheduling real-time (sez.~\ref{sec:sig_real_time} e
-sez.~\ref{sec:proc_real_time}), la misura del tempo, i meccanismi di
-intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O asincrono
-(sez.~\ref{sec:file_asyncronous_io}).
+\textit{thread} (vedi cap.~\ref{cha:threads}), e dallo standard POSIX.1b per
+quanto riguarda i segnali e lo scheduling real-time
+(sez.~\ref{sec:sig_real_time} e sez.~\ref{sec:proc_real_time}), la misura del
+tempo, i meccanismi di intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O
+asincrono (sez.~\ref{sec:file_asyncronous_io}).
Lo standard principale resta comunque POSIX.1, che continua ad evolversi; la
versione più nota, cui gran parte delle implementazioni fanno riferimento, e
\macro{\_GNU\_SOURCE}) è stata a sua volta attivata, nel qual caso queste
hanno la precedenza. Se però si definisce \macro{\_BSD\_SOURCE} dopo aver
definito una di queste macro, l'effetto sarà quello di dare la precedenza
- alle funzioni in forma BSD.
+ alle funzioni in forma BSD. Questa macro è stata deprecata a partire dalle
+ \acr{glibc} 2.20, essendo ricompresa in \macro{\_DEFAULT\_SOURCE} che è
+ definita di default.
\item[\macro{\_SVID\_SOURCE}] definendo questa macro si rendono disponibili le
funzionalità derivate da SVID. Esse comprendono anche quelle definite negli
standard ISO C, POSIX.1, POSIX.2, e X/Open (XPG$n$) illustrati in
- precedenza.
+ precedenza. Questa macro è stata deprecata a partire dalle \acr{glibc} 2.20,
+ essendo ricompresa in \macro{\_DEFAULT\_SOURCE} che è definita di default.
+
+\item[\macro{\_DEFAULT\_SOURCE}] questa macro abilita le definizioni
+ considerate il \textit{default}, comprese quelle richieste dalla standard
+ POSIX.1-2008, ed è sostanzialente equivalente a \macro{\_SVID\_SOURCE}
+ \macro{\_BSD\_SOURCE}] e \macro{\_POSIX\_C\_SOURCE}. Essendo predefinita non
+ è necessario usarla a meno di non aver richiesto delle definizioni più
+ restrittive sia con altre macro che con i flag del compilatore, nel qual
+ caso abilita le funzioni che altrimenti sarebbero disabilitate. Questa macro
+ è stata introdotta a partire dalle \acr{glibc} 2.19 e consente di deprecare
+ \macro{\_SVID\_SOURCE} e \macro{\_BSD\_SOURCE}].
\item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si rendono disponibili
le funzionalità descritte nella \textit{X/Open Portability Guide}. Anche
viene tuttora riconosciuta come equivalente di \macro{\_ISOC99\_SOURCE} per
compatibilità.
+\item[\macro{\_ISOC11\_SOURCE}] definendo questa macro si rendono disponibili
+ le funzionalità previste per la revisione delle librerie standard del C
+ introdotte con lo standard ISO C11, e abilita anche quelle previste dagli
+ standard C99 e C95. La macro è definita a partire dalla versione 2.16 della
+ \acr{glibc}.
+
\item[\macro{\_GNU\_SOURCE}] definendo questa macro si rendono disponibili
tutte le funzionalità disponibili nei vari standard oltre a varie estensioni
specifiche presenti solo nella \acr{glibc} ed in Linux. Gli standard coperti
presente negli standard con i file di grandi dimensioni, ed in particolare
definire le due funzioni \func{fseeko} e \func{ftello} che al contrario
delle corrispettive \func{fseek} e \func{ftell} usano il tipo di dato
- specifico \type{off\_t} (vedi sez.~\ref{sec:file_fseek}).
+ specifico \type{off\_t} (vedi sez.~\ref{sec:file_io}).
\item[\macro{\_LARGEFILE64\_SOURCE}] definendo questa macro si rendono
disponibili le funzioni di una interfaccia alternativa al supporto di valori
projects / gapil.git / blobdiff