From: Simone Piccardi Date: Fri, 29 Aug 2008 18:45:58 +0000 (+0000) Subject: Ristrutturazione della sezione sugli standard e le features macro, con X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=commitdiff_plain;h=6ca77550fb420b3948b95a60ff79f7e282c12d34 Ristrutturazione della sezione sugli standard e le features macro, con aggiornamento della stessa ed introduzione delle nuove macro. --- diff --git a/filestd.tex b/filestd.tex index 32e2fd8..1c69ca2 100644 --- a/filestd.tex +++ b/filestd.tex @@ -1306,7 +1306,10 @@ pu In Linux, a partire dalle glibc 2.1, sono presenti anche le due funzioni \func{fseeko} e \func{ftello}, che sono assolutamente identiche alle precedenti \func{fseek} e \func{ftell} ma hanno argomenti di tipo -\type{off\_t} anziché di tipo \ctyp{long int}. +\type{off\_t} anziché di tipo \ctyp{long int}. Dato che \ctyp{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. diff --git a/fileunix.tex b/fileunix.tex index 4e58de0..f0534ed 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -651,7 +651,7 @@ dagli albori di Unix, ma nella seconda versione delle \textit{Single Unix 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.} (quello che viene chiamato -normalmente Unix98, vedi sez.~\ref{sec:intro_opengroup}) è stata introdotta la +normalmente Unix98, vedi sez.~\ref{sec:intro_xopen}) è stata introdotta la definizione di un'altra funzione di lettura, \funcd{pread}, il cui prototipo è: \begin{prototype}{unistd.h} {ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)} diff --git a/intro.tex b/intro.tex index b7416db..4e77602 100644 --- a/intro.tex +++ b/intro.tex @@ -27,7 +27,7 @@ introdurremo alcuni degli standard principali a cui viene fatto riferimento. \label{sec:intro_unix_struct} In questa prima sezione faremo una breve panoramica sull'architettura del -sistema. Chi avesse già una conoscenza di questa materia può tranquillamente +sistema. Chi avesse già una conoscenza di questa materia può tranquillamente saltare questa sezione. @@ -44,9 +44,9 @@ alle risorse hardware tramite delle richieste a quest'ultimo. Fin dall'inizio uno Unix si presenta come un sistema operativo \textit{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). +una macchina eseguendo più programmi ``\textsl{in contemporanea}''; in realtà, +almeno per macchine a processore singolo, i programmi vengono eseguiti +singolarmente a rotazione. % Questa e` una distinzione essenziale da capire, %specie nei confronti dei sistemi operativi successivi, nati per i personal @@ -60,8 +60,8 @@ 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). +e non possono accedere direttamente alle zone di memoria riservate o alle +porte di input/output. Una parte del kernel, lo \itindex{scheduler} \textit{scheduler}, si occupa di stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle @@ -104,12 +104,10 @@ Per questa separazione non 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 che 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. +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 @@ -327,7 +325,7 @@ 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 del sistema o alle caratteristiche che si sono stabilite come standard di fatto in quanto facenti parte di alcune -implementazioni molto diffuse come BSD o SVr4. +implementazioni molto diffuse come BSD o System V. Ovviamente prenderemo in considerazione solo gli standard riguardanti interfacce di programmazione e le altre caratteristiche di un sistema @@ -341,10 +339,15 @@ particolare attenzione alle \acr{glibc}). \label{sec:intro_ansiC} Lo standard ANSI C è stato definito nel 1989 dall'\textit{American National - Standard Institute}, come standard del linguaggio C ed è stato -successivamente adottato dalla \textit{International Standard Organisation} -come standard internazionale con la sigla ISO/IEC 9899:1990, e va anche sotto -il nome di standard ISO C. + 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 (\textit{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. Scopo dello standard è quello di garantire la portabilità dei programmi C fra sistemi operativi diversi, ma oltre alla sintassi ed alla semantica del @@ -403,7 +406,6 @@ sezioni successive. \label{tab:intro_posix_header} \end{table} - In realtà \acr{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 @@ -474,30 +476,114 @@ utilizzati dalle funzioni di sistema dai tipi elementari supportati dal compilatore C. +\subsection{Lo standard System V} +\label{sec:intro_sysv} + +Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come +marchio depositato, sviluppandone una serie di versioni diverse; nel 1983 la +versione supportata ufficialmente 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 \textit{release 2} nel 1985, +a cui si fa riferimento con SVr2 e la \textit{release 3} nel 1986 (denominata +SVr3). Le interfacce di programmazione di queste due versioni vennero +descritte formalmente in due documenti denominati \textit{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 \textit{release 4} o +SVr4. Anche le relative interfacce vennero descritte in un documento dal +titolo \textit{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 semplicemente 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 +\textit{System V Interface Description}, che va sotto la denominazione di SVID +4. -\subsection{Lo standard IEEE -- POSIX} +Linux e le \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 +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.~\ref{sec:ipc_sysv}) le funzioni della famiglia +\func{hsearch} e \func{drand48}, \func{fmtmsg} e svariate funzioni +matematiche. + + +\subsection{Lo ``\textsl{standard}'' BSD} +\label{sec:intro_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 \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. + +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 precedenti 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 +\acr{glibc} forniscono tutte queste estensioni che sono state in gran parte +incorporate negli standard successivi. + + +\subsection{Gli standard IEEE -- POSIX} \label{sec:intro_posix} -Uno standard più attinente al sistema nel suo complesso (e che concerne sia il -kernel che le librerie) è 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. +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 Stallman, sta per \textit{Portable Operating System Interface}, ma la X finale denuncia la sua stretta relazione con i sistemi Unix. Esso nasce dal lavoro dell'IEEE (\textit{Institute of Electrical and Electronics Engeneers}) -che ne produsse una prima versione, nota come IEEE 1003.1-1988, mirante a -standardizzare l'interfaccia con il sistema operativo. +che ne produsse una prima versione, nota come \textsl{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 \textit{real-time} e per i -thread (1003.1d e 1003.1c) e vari altri. In tab.~\ref{tab:intro_posix_std} è -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 -si può parlare di POSIX.4 come di POSIX.1b). +thread (rispettivamente 1003.1d e 1003.1c) per i socket (1003.1g) e vari +altri. In tab.~\ref{tab:intro_posix_std} è 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. Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione si aggiungono continuamente, mentre le versioni precedenti vengono riviste; @@ -536,11 +622,7 @@ possono recuperare varie (e di norma piuttosto intricate) informazioni Benché l'insieme degli standard POSIX siano basati sui sistemi Unix, essi definiscono comunque 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). 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. +un'implementazione di POSIX.1 anche sotto Windows NT). Linux e le \acr{glibc} implementano tutte le funzioni definite nello standard POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per @@ -556,49 +638,73 @@ quanto riguarda i segnali e lo \itindex{scheduler} scheduling real-time tempo, i meccanismi di intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O asincrono (sez.~\ref{sec:file_asyncronous_io}). - - -\subsection{Lo standard X/Open} +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 +\textsl{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.~\ref{sec:intro_xopen}) 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 denominati \textit{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. + +Infine è in corso una ulteriore revisione degli standard POSIX e SUS, che +dovrebbe essere completata entro l'anno 2008 e che andrà presumibilmente +sotto il nome di POSIX.1-2008. È prevista l'incorporazione di molte interfacce +opzionali dentro le specifiche di base, oltre che le solite precisazioni ed +aggiornamenti. Anche in questo caso è prevista la suddivisione in una +conformità di base, e delle interfacce aggiuntive. + +% vedi anche man standards + +\subsection{Gli standard X/Open -- Opengroup -- Unix} \label{sec:intro_xopen} 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 \textit{X/Open Portability Guide} (a cui di norma si fa riferimento -con l'abbreviazione XPG$n$ con $n$ che indica la versione). +nome di \textit{X/Open Portability Guide} a cui di norma si fa riferimento con +l'abbreviazione XPG$n$, con $n$ che indica la versione. Nel 1989 il consorzio produsse una terza versione di questa guida particolarmente voluminosa (la \textit{X/Open Portability Guide, Issue 3}), -contenente un'ulteriore standardizzazione dell'interfaccia 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 API (\textit{Application Programmable Interface}) -per l'interfaccia grafica (X11). +contenente una dettagliata standardizzazione dell'interfaccia 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 API\footnote{le \textit{Application Programmable Interface}, in sostanze + le interfacce di programmazione.} 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 (\textit{X +Issue 4, da cui la sigla XPG4, che aggiungeva l'interfaccia XTI (\textit{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). +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 \textit{Single UNIX Specification}, l'ultima +specifiche sotto il nome di \textit{Single UNIX Specification} o SUS, l'ultima versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX - Specification}, SUSv1, più comunemente nota come \textit{Unix 95}. - - -\subsection{Gli standard Unix} -\label{sec:intro_opengroup} + Specification}, detta SUS o SUSv1, ma più comunemente nota anche come +\textit{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'\textit{Open Group}, un consorzio internazionale che raccoglie produttori, utenti industriali, entità accademiche e governative. - Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue il lavoro di standardizzazione delle varie implementazioni, rilasciando periodicamente nuove specifiche e strumenti per la verifica della conformità @@ -606,145 +712,240 @@ alle stesse. Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX Specification}, nota con la sigla SUSv2, in questa versione le interfacce -specificate salgono a 1434 (e 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 \textit{Unix 98}, usato spesso anche per riferirsi allo standard. - - -\subsection{Lo ``\textsl{standard}'' BSD} -\label{sec:intro_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 uno standard formalizzato, l'implementazione di Unix -dell'Università di Berkeley, ha provveduto nel tempo una serie di estensioni e -API di grande rilievo, come i link simbolici, la funzione \code{select} ed i -socket. - -Queste estensioni sono state via via aggiunte al sistema nelle varie versioni -del sistema (BSD 4.2, BSD 4.3 e BSD 4.4) come pure in alcuni derivati -commerciali come SunOS. Il kernel Linux e le \acr{glibc} provvedono tutte -queste estensioni che sono state in gran parte incorporate negli standard -successivi. - - -\subsection{Lo standard System V} -\label{sec:intro_sysv} - -Come noto Unix nasce nei laboratori della AT\&T, che ne registrò il nome come -marchio depositato, sviluppandone una serie di versioni diverse; nel 1983 la -versione supportata ufficialmente venne rilasciata al pubblico con il nome di -Unix System V. Negli anni successivi l'AT\&T proseguì lo sviluppo rilasciando -varie versioni con aggiunte e integrazioni; nel 1989 un accordo fra vari -venditori (AT\&T, Sun, HP, e altro) portò ad una versione che provvedeva -un'unificazione delle interfacce comprendente Xenix e BSD, la System V release -4. - -L'interfaccia di questa ultima release è descritta in un documento dal titolo -\textit{System V Interface Description}, o SVID; spesso però si fa riferimento -a questo standard con il nome della sua implementazione, usando la sigla SVr4. - -Anche questo 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. - -Linux e le \acr{glibc} implementano le principali funzionalità richieste da -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.~\ref{sec:ipc_sysv}) le funzioni della famiglia -\func{hsearch} e \func{drand48}, \func{fmtmsg} e svariate funzioni -matematiche. - - -\subsection{Il comportamento standard del \cmd{gcc} e delle \acr{glibc}} +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 \textit{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 \textit{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 con la prossima revisione dello standard POSIX.1 è previsto che, come +avviene per il POSIX.1-2001, la conformità completa a tutte quelle che saranno +le nuove estensioni XSI previste dall'aggiornamento andrà a definire la nuova +versione delle \textit{Single UNIX Specification} che verranno chiamate SUSv4. + + +\subsection{Il controllo di aderenza agli standard} \label{sec:intro_gcc_glibc_std} -In Linux, grazie alle \acr{glibc}, gli standard appena descritti sono -ottenibili sia attraverso l'uso di opzioni del compilatore (il \cmd{gcc}) che -definendo opportune costanti prima dell'inclusione dei file degli header. - -Se si vuole che i programmi seguano una stretta attinenza allo standard ANSI C -si può usare l'opzione \cmd{-ansi} del compilatore, e non potrà essere -utilizzata nessuna funzione non riconosciuta dalle specifiche standard ISO per -il C. +In Linux, grazie alle \acr{glibc}, la conformità agli standard appena +descritti può essere richiesta sia attraverso l'uso di opportune opzioni del +compilatore, il \texttt{gcc}, che definendo delle specifiche costanti prima +dell'inclusione dei file di dichiarazione (gli \textit{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 \texttt{-ansi} del compilatore, e non +potrà essere utilizzata nessuna funzione non riconosciuta dalle specifiche +standard ISO per il C. Il \texttt{gcc} possiede inoltre una specifica opzione +per richiedere la conformità ad uno standard, nella forma \texttt{-std=nome}, +dove \texttt{nome} può essere \texttt{c89} per indicare lo standard ANSI C +(vedi sez.~\ref{sec:intro_ansiC}) o \texttt{c99} per indicare la conformità +allo standard C99.\footnote{che non è al momento completa, esistono anche le + possibilità di usare i valori \texttt{gnu89}, l'attuale default, che indica + l'uso delle estensioni GNU al C89, riprese poi dal C99, o \texttt{gnu89} che + indica il dialetto GNU del C99, che diventerà il default quando la + conformità a quest'ultimo sarà completa.} + +Per attivare le varie opzioni di controllo di aderenza agli standard è poi +possibile definire delle macro di preprocessore che controllano le +funzionalità che le \acr{glibc} possono mettere a disposizione:\footnote{le + macro sono definite nel file di dichiarazione \file{}, 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 \texttt{\_}, + che non devono assolutamente mai essere usate direttamente. } questo può +essere fatto attraverso l'opzione \texttt{-D} del compilatore, ma è buona +norma farlo inserendo gli opportuni \code{\#define} prima della inclusione dei +propri \textit{header file}. + +Le macro disponibili per controllare l'aderenza ai vari standard messe a +disposizione delle \acr{glibc}, che rendono disponibili soltanto le funzioni +in esse definite, sono illustrate nel seguente elenco: +\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}} +\item[\macro{\_\_STRICT\_ANSI\_\_}] richiede l'aderenza stretta allo standard + C ISO; viene automaticamente predefinita qualora si invochi il \texttt{gcc} + con le opzione \texttt{-ansi} o \texttt{-std=c99}. -Per attivare le varie opzioni è possibile definire le macro di preprocessore, -che controllano le funzionalità che le \acr{glibc} possono mettere a -disposizione: questo può essere fatto attraverso l'opzione \cmd{-D} del -compilatore, ma è buona norma inserire gli opportuni \code{\#define} nei -propri header file. +\item[\macro{\_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 + \macro{\_POSIX\_C\_SOURCE} lo stato di questa non viene preso in + considerazione. -Le macro disponibili per i vari standard sono le seguenti: -\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}} -\item[\macro{\_POSIX\_SOURCE}] definendo questa macro 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 \macro{\_POSIX\_C\_SOURCE} lo stato - di questa non viene preso in considerazione. \item[\macro{\_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à. Se è uguale a ``\texttt{1}'' vengono attivate le funzionalità - specificate nella edizione del 1990 (IEEE Standard 1003.1-1990), valori - maggiori o uguali a ``\texttt{2}'' attivano le funzionalità POSIX.2 - specificate nell'edizione del 1992 (IEEE Standard 1003.2-1992). Un valore - maggiore o uguale a ``\texttt{199309L}'' attiva le funzionalità POSIX.1b - specificate nell'edizione del 1993 (IEEE Standard 1003.1b-1993). Un valore - maggiore o uguale a ``\texttt{199506L}'' attiva le funzionalità POSIX.1 - specificate nell'edizione del 1996 (ISO/IEC 9945-1: 1996). Valori superiori - abiliteranno ulteriori estensioni. -\item[\macro{\_BSD\_SOURCE}] definendo questa macro si attivano le + funzionalità: + \begin{itemize} + \item un valore uguale a ``\texttt{1}'' rende disponibili le funzionalità + specificate nella edizione del 1990 (IEEE Standard 1003.1-1990); + \item valori maggiori o uguali a ``\texttt{2}'' rendono disponibili le + funzionalità previste dallo standard POSIX.2 specificate nell'edizione del + 1992 (IEEE Standard 1003.2-1992), + \item un valore maggiore o uguale a ``\texttt{199309L}'' rende disponibili + le funzionalità previste dallo standard POSIX.1b specificate nell'edizione + del 1993 (IEEE Standard 1003.1b-1993); + \item un valore maggiore o uguale a ``\texttt{199506L}'' rende disponibili + le funzionalità previste dallo standard POSIX.1 specificate nell'edizione + del 1996 (\textit{ISO/IEC 9945-1:1996}), ed in particolare le definizioni + dello standard POSIX.1c per i \textit{thread}; + \item a partire dalla versione 2.3.3 delle \acr{glibc} un valore maggiore o + uguale a ``\texttt{200112L}'' rende disponibili le funzionalità di base + previste dallo standard POSIX.1-2001, escludendo le estensioni XSI; + \item in futuro valori superiori potranno abilitare ulteriori estensioni. + \end{itemize} + +\item[\macro{\_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 POSIX.2. Alcune delle funzionalità previste da BSD sono + ISO C, POSIX.1 e POSIX.2; alcune delle funzionalità previste da BSD sono però in conflitto con le corrispondenti definite nello standard POSIX.1, in - questo caso le definizioni previste da BSD4.3 hanno la precedenza rispetto a - POSIX. A causa della natura dei conflitti con POSIX per ottenere una piena - compatibilità con BSD4.3 è necessario anche usare una libreria di + 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 + compatibilità con BSD4.3 può essere necessario anche usare una libreria di compatibilità, dato che alcune funzioni sono definite in modo diverso. In - questo caso occorre pertanto anche usare l'opzione \cmd{-lbsd-compat} con il + questo caso occorrerà anche usare l'opzione \cmd{-lbsd-compat} con il compilatore per indicargli di utilizzare le versioni nella libreria di compatibilità prima di quelle normali. -\item[\macro{\_SVID\_SOURCE}] definendo questa macro si attivano le + + 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 (\macro{\_SVID\_SOURCE}, + \macro{\_POSIX\_SOURCE}, \macro{\_POSIX\_C\_SOURCE}, + \macro{\_XOPEN\_SOURCE}, \macro{\_XOPEN\_SOURCE\_EXTENDED} o + \macro{\_GNU\_SOURCE}) è stata a sua volta attivata, nel qual caso queste + hanno la precedenza. + +\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. -\item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si attivano le - funzionalità descritte nella \textit{X/Open Portability Guide}. Anche queste - sono un sovrainsieme di quelle definite in POSIX.1 e POSIX.2 ed in effetti - sia \macro{\_POSIX\_SOURCE} che \macro{\_POSIX\_C\_SOURCE} vengono + standard ISO C, POSIX.1, POSIX.2, e X/Open (XPG$n$) illustrati in + precedenza. + +\item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si rendono disponibili + le funzionalità descritte nella \textit{X/Open Portability Guide}. Anche + queste sono un sovrainsieme di quelle definite in POSIX.1 e POSIX.2 ed in + effetti sia \macro{\_POSIX\_SOURCE} che \macro{\_POSIX\_C\_SOURCE} vengono automaticamente definite. Sono incluse anche ulteriori funzionalità - disponibili in BSD e SVID. Se il valore della macro è posto a - ``\texttt{500}'' questo include anche le nuove definizioni introdotte con la - \textit{Single UNIX Specification, version 2}, cioè Unix98. -\item[\macro{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si attivano le - ulteriori funzionalità necessarie ad essere conformi al rilascio del marchio - \textit{X/Open Unix}. -\item[\macro{\_ISOC99\_SOURCE}] definendo questa macro si attivano le - funzionalità previste per la revisione delle librerie standard del C - denominato ISO C99. Dato che lo standard non è ancora adottato in maniera - ampia queste non sono abilitate automaticamente, ma le \acr{glibc} hanno già - un'implementazione completa che può essere attivata definendo questa macro. -\item[\macro{\_LARGEFILE\_SOURCE}] definendo questa macro si attivano le - funzionalità per il supporto dei file di grandi dimensioni (il \textit{Large - File Support} o LFS) con indici e dimensioni a 64 bit. -\item[\macro{\_GNU\_SOURCE}] definendo questa macro si attivano tutte le - funzionalità disponibili: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, - X/Open, LFS più le estensioni specifiche GNU. Nel caso in cui BSD e POSIX - confliggano viene data la precedenza a POSIX. + disponibili in BSD e SVID: + \begin{itemize} + \item la definizione della macro ad un valore qualunque attiva le + funzionalità specificate negli standard POSIX.1, POSIX.2 e XPG4; + \item un valore di ``\texttt{500}'' o superiore rende disponibili anche le + funzionalità introdotte con SUSv2, vale a dire la conformità ad Unix98; + \item a partire dalla versione 2.2 delle \acr{glibc} un valore uguale a + ``\texttt{600}'' o superiore rende disponibili anche le funzionalità + introdotte con SUSv3, corrispondenti allo standard POSIX.1-2001 più le + estensioni XSI. + \end{itemize} + +\item[\macro{\_XOPEN\_SOURCE\_EXTENDED}] definendo questa macro si rendono + disponibili le ulteriori funzionalità necessarie ad essere conformi al + rilascio del marchio \textit{X/Open Unix} corrispondenti allo standard + Unix95, vale a dire quelle specificate da SUSv1/XPG4v2. Questa macro viene + definita implicitamente tutte le volte che si imposta + \macro{\_XOPEN\_SOURCE} ad un valore maggiore o uguale a 500. + +\item[\macro{\_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 \acr{glibc}. + + Le precedenti versioni della serie 2.1.x riconoscevano le stesse estensioni + con la macro \macro{\_ISOC9X\_SOURCE}, dato che lo standard non era stato + finalizzato, ma le \acr{glibc} avevano già un'implementazione completa che + poteva essere attivata definendo questa macro. Benché questa sia obsoleta + viene tuttora riconosciuta come equivalente di \macro{\_ISOC99\_SOURCE} per + compatibilità. + +\item[\macro{\_GNU\_SOURCE}] definendo questa macro si rendono disponibili + tutte le funzionalità disponibili nei vari standard oltre a varie + estensioni. Gli standard coperti sono: ISO C89, ISO C99, POSIX.1, POSIX.2, + BSD, SVID, X/Open, SUS. + + L'uso di \macro{\_GNU\_SOURCE} è equivalente alla definizione contemporanea + delle macro: \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE}, + \macro{\_POSIX\_SOURCE}, \macro{\_ISOC99\_SOURCE}, inoltre + \macro{\_POSIX\_C\_SOURCE} con valore ``\texttt{200112L}'' (o + ``\texttt{199506L}'' per le versioni delle \acr{glibc} precedenti la 2.5), + \macro{\_XOPEN\_SOURCE\_EXTENDED} e \macro{\_XOPEN\_SOURCE} con valore 600 + (o 500 per le versioni delle \acr{glibc} precedenti la 2.2); oltre a queste + vengono pure attivate le ulteriori \macro{\_ATFILE\_SOURCE} e + \macro{\_LARGEFILE64\_SOURCE} che definiscono funzioni previste + esclusivamente dalle \acr{glibc}. + +\end{basedescript} + +Benché Linux supporti in maniera estensiva gli standard più diffusi, esistono +comunque delle estensioni specifiche e delle funzionalità specifiche, non +presenti in altri standard e lo stesso vale per le \acr{glibc} stesse, che +definiscono anche delle ulteriori funzioni di libreria. Ovviamente l'uso di +queste funzionalità 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 esplicitamente disponibili tramite la definizione di opportune +macro di preprocessore, che si sono illustrate nel seguente elenco: +\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}} + +\item[\macro{\_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 \func{fseeko} e \func{ftello} che al contrario + delle corrispettive \func{fseek} e \func{ftell} usano il tipo di dato + specifico \ctyp{off\_t} (vedi sez.~\ref{sec:file_fseek}). + +\item[\macro{\_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 \texttt{64} aggiunto ai vari nomi di + tipi di dato e funzioni (come \ctyp{off64\_t} al posto di \ctyp{off\_t} o + \func{lseek64} al posto di \func{lseek}). + + Le funzioni di questa interfaccia alternativa sono state proposte come una + estensione ad uso di transizione per le \textit{Single UNIX Specification}, + per consentire 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 2 gigabyte. Nei nuovi programmi queste funzioni devono essere + evitate, a favore dell'uso macro \macro{\_FILE\_OFFSET\_BITS}, che definita + al valore di \texttt{64} consente di usare in maniera trasparente le + funzioni dell'interfaccia classica. + +\item[\macro{\_FILE\_OFFSET\_BITS}] la definizione di questa macro al valore + di \texttt{64} consente di attivare la conversione 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 esplicitamente + 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.\footnote{basterà ricompilare il programma + dopo averla definita, e saranno usate in modo trasparente le funzioni a 64 + bit.} + + Se la macro non è definita o è definita con valore \texttt{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. + +\item[\macro{\_ATFILE\_SOURCE}] definendo questa macro si rendono disponibili + le funzioni + +\item[\macro{\_FORTIFY\_SOURCE}] definendo questa macro si rendono + disponibili le estensioni delle funzioni di creazione di file e directory + che consentono una specificazione coerente dei pathname relativi illustrate + in sez.~\ref{sec:file_openat}. + +\item[\macro{\_REENTRANT}] definendo questa macro si rendono disponibili + \end{basedescript} In particolare è da sottolineare che le \acr{glibc} supportano alcune @@ -754,6 +955,8 @@ definendo la macro \macro{\_GNU\_SOURCE} prima di includere i vari header file. +% vedi anche man feature_test_macros + %% \subsection{Gli standard di GNU/Linux} %% \label{sec:intro_linux_std} @@ -761,7 +964,7 @@ file. -% LocalWords: like kernel multitasking scheduler preemptive sez swap is cap +% LocalWords: like kernel multitasking scheduler preemptive sez swap is cap VM % LocalWords: everything bootstrap init shell Windows Foundation system call % LocalWords: fig libc uClib glibc embedded Library POSIX username PAM Methods % LocalWords: Pluggable Autentication group supplementary Name Service Switch @@ -777,8 +980,10 @@ file. % LocalWords: socket Spec Novell Specification SUSv CDE Motif Berkley select % LocalWords: SunOS l'AT Sun HP Xenix Description SVID Laboratories MP hsearch % LocalWords: drand fmtmsg define SOURCE lbsd compat XOPEN version ISOC Large -% LocalWords: LARGEFILE Support LFS dell' - +% LocalWords: LARGEFILE Support LFS dell' black rectangle node fill cpu draw +% LocalWords: ellipse mem anchor west proc SysV SV Definition SCO Austin XSI +% LocalWords: Technical TC SUS Opengroup features STRICT std ATFILE fseeko +% LocalWords: ftello fseek ftell lseek FORTIFY REENTRANT %%% Local Variables: %%% mode: latex