(cioè accessibili con il comando \cmd{man 3 <nome>}) e come accennato non sono
direttamente associate ad una \textit{system call} anche se, ad esempio per la
gestione dei file o della allocazione dinamica della memoria, possono farne
-uso nella loro implementazione. Nonostante questa questa distinzione,
-fondamentale per capire il funzionamento del sistema, l'uso da parte dei
-programmi di una di queste funzioni resta lo stesso, sia che si tratti di una
-funzione interna della libreria che di una \textit{system call}.
+uso nella loro implementazione. Nonostante questa distinzione, fondamentale
+per capire il funzionamento del sistema, l'uso da parte dei programmi di una
+di queste funzioni resta lo stesso, sia che si tratti di una funzione interna
+della libreria che di una \textit{system call}.
\subsection{Un sistema multiutente}
file con gli \textit{extended attributes} (vedi sez.~\ref{sec:file_xattr}),
ma è una caratteristica tutt'ora poco utilizzata, dato che non corrisponde
al modello classico dei file in un sistema Unix.} ogni classificazione di
-questo tipo avviene sempre in \textit{user-space}. Gli unici file di cui il
+questo tipo avviene sempre in \textit{user space}. Gli unici file di cui il
kernel deve essere in grado di capire il contenuto sono i binari dei
programmi, per i quali sono supportati solo alcuni formati, anche se oggi
viene usato quasi esclusivamente
\itindbeg{file~descriptor}
In Linux le interfacce di programmazione per l'I/O su file due. La prima è
-l'interfaccia nativa del sistema, quella che il manuale delle \textsl{glibc}
+l'interfaccia nativa del sistema, quella che il manuale della \textsl{glibc}
chiama interfaccia dei ``\textit{file descriptor}'' (in italiano
\textsl{descrittori di file}). Si tratta di un'interfaccia specifica dei
sistemi unix-like che fornisce un accesso non bufferizzato.
kernel negli Unix derivati da \textit{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 \textit{stream}
- useremo il significato adottato dal manuale delle \acr{glibc}.} Essa
+ useremo il significato adottato dal manuale della \acr{glibc}.} Essa
fornisce funzioni più evolute e un accesso bufferizzato, controllato dalla
implementazione fatta nella \acr{glibc}. Questa è l'interfaccia specificata
dallo standard ANSI C e perciò si trova anche su tutti i sistemi non Unix. Gli
\textit{System V Interface Description}, che va sotto la denominazione di SVID
4.
-Linux e le \acr{glibc} implementano le principali funzionalità richieste dalle
+Linux e la \acr{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
definito una di queste macro, l'effetto sarà quello di dare la precedenza
alle funzioni in forma BSD. Questa macro, essendo ricompresa in
\macro{\_DEFAULT\_SOURCE} che è definita di default, è stata deprecata a
- partire dalle \acr{glibc} 2.20.
+ partire dalla \acr{glibc} 2.20.
\item[\macrod{\_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. Questa macro, essendo ricompresa in \macro{\_DEFAULT\_SOURCE}
- che è definita di default, è stata deprecata a partire dalle \acr{glibc}
+ che è definita di default, è stata deprecata a partire dalla \acr{glibc}
2.20.
\item[\macrod{\_DEFAULT\_SOURCE}] questa macro abilita le definizioni
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
+ dalla \acr{glibc} 2.19 e consente di deprecare \macro{\_SVID\_SOURCE} e
\macro{\_BSD\_SOURCE}.
\item[\macrod{\_XOPEN\_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
\textit{pathname} relativi con programmi \textit{multi-thread} illustrate in
- sez.~\ref{sec:file_openat}. Dalle \acr{glibc} 2.10 questa macro viene
+ sez.~\ref{sec:file_openat}. Dalla \acr{glibc} 2.10 questa macro viene
definita implicitamente se si definisce \macro{\_POSIX\_C\_SOURCE} ad un
valore maggiore o uguale di ``\texttt{200809L}''.
funzioni sono anche previste nello standard POSIX.1c, ma ve ne sono altre
che sono disponibili soltanto su alcuni sistemi, o specifiche della
\acr{glibc}, e possono essere utilizzate una volta definita la macro. Oggi
- la macro è obsoleta, già dalle \acr{glibc} 2.3 le librerie erano già
- completamente rientranti e dalle \acr{glibc} 2.25 la macro è equivalente ad
+ la macro è obsoleta, già dalla \acr{glibc} 2.3 le funzioni erano già
+ completamente rientranti e dalla \acr{glibc} 2.25 la macro è equivalente ad
definire \macro{\_POSIX\_C\_SOURCE} con un valore di ``\texttt{199606L}''
mentre se una qualunque delle altre macro che richiede un valore di
conformità più alto è definita, la sua definizione non ha alcun effetto.