X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=intro.tex;h=1fa1d24e303760926581831852ebf3c0388ea2a9;hp=aff48b7c446f22279c1309636fa82bafbc9acb35;hb=0196c376e39fc18f8cd5e7fef47b61264f943faf;hpb=e7010c3fbd41a2de44c7b513c5de6e2c6d7ab4b4 diff --git a/intro.tex b/intro.tex index aff48b7..1fa1d24 100644 --- a/intro.tex +++ b/intro.tex @@ -1,6 +1,6 @@ %% intro.tex %% -%% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2008 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", @@ -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,13 +60,13 @@ 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 priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il -cosiddetto \itindex{prehemptive~multitasking} \textit{prehemptive +cosiddetto \itindex{preemptive~multitasking} \textit{preemptive multitasking}). Questo verrà comunque eseguito in modalità protetta; quando necessario il processo potrà accedere alle risorse hardware soltanto attraverso delle opportune chiamate al sistema che restituiranno il controllo @@ -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 @@ -174,7 +172,46 @@ fig.~\ref{fig:intro_sys_struct}. \begin{figure}[htb] \centering - \includegraphics[width=10cm]{img/struct_sys} +% \includegraphics[width=10cm]{img/struct_sys} + \begin{tikzpicture} + \filldraw[fill=black!20] (0,0) rectangle (7.5,1); + \draw (3.75,0.5) node {System Call Interface}; + \filldraw[fill=black!35] (0,1) rectangle (7.5,4); + \draw (3.75,2.5) node {\huge{kernel}}; + \filldraw[fill=black!20] (0,4) rectangle (2.5,5); + \draw (1.25,4.5) node {scheduler}; + \filldraw[fill=black!20] (2.5,4) rectangle (5,5); + \draw (3.75,4.5) node {VM}; + \filldraw[fill=black!20] (5,4) rectangle (7.5,5); + \draw (6.25,4.5) node {driver}; + + \draw (1.25,7) node(cpu) [ellipse,draw] {CPU}; + \draw (3.75,7) node(mem) [ellipse,draw] {memoria}; + \draw (6.25,7) node(disk) [ellipse,draw] {disco}; + + \draw[<->] (cpu) -- (1.25,5); + \draw[<->] (mem) -- (3.75,5); + \draw[<->] (disk) -- (6.25,5); + + \draw (7.5,0) node [anchor=base west] {kernel space}; + \draw (7.5,-1) node [anchor=west] {user space}; + + \draw (-1,-0.5) -- (8.5, -0.5); + + \draw (0,-2) rectangle (7.5,-1); + \draw (3.75, -1.5) node {GNU C Library}; + \draw[->] (1.25,-1) -- (1.25,0); + \draw[->] (3.75,-1) -- (3.75,0); + \draw[->] (6.25,-1) -- (6.25,0); + + \draw (1.25,-3) node(proc1) [rectangle,draw] {processo}; + \draw (3.75,-3) node(proc2) [rectangle,draw] {processo}; + \draw (6.25,-3) node(proc3) [rectangle,draw] {processo}; + + \draw[->] (1.25,-2) -- (proc1); + \draw[->] (3.75,-2) -- (proc2); + \draw[->] (6.25,-2) -- (proc3); + \end{tikzpicture} \caption{Schema di massima della struttura di interazione fra processi, kernel e dispositivi in Linux.} \label{fig:intro_sys_struct} @@ -237,7 +274,7 @@ viene richiesto all'ingresso nel sistema dalla procedura di \textit{login} (descritta in dettaglio in sez.~\ref{sec:sess_login}). Questa procedura si incarica di verificare l'identità dell'utente, in genere attraverso la richiesta di una parola d'ordine (la \textit{password}), anche se sono -possibili meccanismi diversi.\footnote{Ad esempio usando la libreria PAM +possibili meccanismi diversi.\footnote{ad esempio usando la libreria PAM (\textit{Pluggable Autentication Methods}) è possibile astrarre completamente dai meccanismi di autenticazione e sostituire ad esempio l'uso delle password con meccanismi di identificazione biometrica.} @@ -288,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 @@ -302,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 @@ -349,9 +391,10 @@ sezioni successive. \file{malloc.h}&$\bullet$& & Allocazione della memoria.\\ \file{setjmp.h}&$\bullet$& & Salti non locali.\\ \file{signal.h}& &$\bullet$& Gestione dei segnali.\\ - \file{stdarg.h}&$\bullet$& & .\\ + \file{stdarg.h}&$\bullet$& & Gestione di funzioni a argomenti + variabili.\\ \file{stdio.h} &$\bullet$& & I/O bufferizzato in standard ANSI C.\\ - \file{stdlib.h}&$\bullet$& & definizioni della libreria standard.\\ + \file{stdlib.h}&$\bullet$& & Definizioni della libreria standard.\\ \file{string.h}&$\bullet$& & Manipolazione delle stringhe.\\ \file{time.h} & &$\bullet$& Gestione dei tempi.\\ \file{times.h} &$\bullet$& & Gestione dei tempi.\\ @@ -363,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 @@ -403,7 +445,7 @@ una infinita serie di problemi di portabilit \hline \type{caddr\_t} & Core address.\\ \type{clock\_t} & Contatore del tempo di sistema.\\ - \type{dev\_t} & Numero di dispositivo.\\ + \type{dev\_t} & Numero di dispositivo (vedi sez.~\ref{sec:file_mknod}).\\ \type{gid\_t} & Identificatore di un gruppo.\\ \type{ino\_t} & Numero di \index{inode} \textit{inode}.\\ \type{key\_t} & Chiave per il System V IPC.\\ @@ -434,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. + +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 standard IEEE -- POSIX} + +\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). +\itindex{thread} \textit{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; @@ -480,7 +606,7 @@ possono recuperare varie (e di norma piuttosto intricate) informazioni 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.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 \\ @@ -496,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 @@ -510,55 +632,80 @@ sistema e che sono definite nello standard POSIX.2. Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i -\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}). - - - -\subsection{Lo standard X/Open} +\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}). + +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à @@ -566,162 +713,286 @@ 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 Berkley 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 \itindex{thread} \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 (vale a dire una fra + \macro{\_POSIX\_C\_SOURCE}, \macro{\_POSIX\_SOURCE}, \macro{\_SVID\_SOURCE}, + \macro{\_XOPEN\_SOURCE}, \macro{\_XOPEN\_SOURCE\_EXTENDED} o + \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. + +\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 - 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. + 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 negli standard 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, più una serie di + estensioni a secondo dei seguenti valori: + \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 + specifiche presenti solo nelle \acr{glibc} ed in Linux. 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 due macro \macro{\_ATFILE\_SOURCE} e + \macro{\_LARGEFILE64\_SOURCE} che definiscono funzioni previste + esclusivamente dalle \acr{glibc}. + \end{basedescript} -In particolare è da sottolineare che le \acr{glibc} supportano alcune -estensioni specifiche GNU, che non sono comprese in nessuno degli standard -citati. Per poterle utilizzare esse devono essere attivate esplicitamente -definendo la macro \macro{\_GNU\_SOURCE} prima di includere i vari header -file. +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 \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, alcune di queste vengono attivate con la definizione +di \macro{\_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: -%% \subsection{Gli standard di GNU/Linux} -%% \label{sec:intro_linux_std} +\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 estensioni delle funzioni di creazione di file e directory che risolvono + i problemi di sicurezza insiti nell'uso di pathname relativi con programmi + \itindex{thread} \textit{multi-thread} illustrate in + sez.~\ref{sec:file_openat}. + +\item[\macro{\_REENTRANT}] definendo questa macro, o la equivalente + \macro{\_THREAD\_SAFE} (fornita per compatibilità) si rendono disponibili le + versioni \index{funzioni!rientranti} rientranti (vedi + sez.~\ref{sec:proc_reentrant}) di alcune funzioni, necessarie quando si + usano i \itindex{thread} \textit{thread}. Alcune di queste funzioni sono + anche previste nello standard POSIX.1c, ma ve ne sono altre che sono + disponibili soltanto su alcuni sistemi, o specifiche del \acr{glibc}, e + possono essere utilizzate una volta definita la macro. + +\item[\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 \textit{buffer overflow} nell'uso delle + stesse. La funzionalità è stata introdotta a partire dalla versione 2.3.4 + delle \acr{glibc} e richiede anche il supporto da parte del compilatore, che + è disponibile solo a partire dalla versione 4.0 del \texttt{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: \func{memcpy}, \func{mempcpy}, \func{memmove}, \func{memset}, + \func{stpcpy}, \func{strcpy}, \func{strncpy}, \func{strcat}, \func{strncat}, + \func{sprintf}, \func{snprintf}, \func{vsprintf}, \func{vsnprintf}, e + \func{gets}. + + La macro prevede due valori, con \texttt{1} vengono eseguiti dei controlli + di base che non cambiano il comportamento dei programmi se si richiede una + ottimizzazione di livello uno o superiore,\footnote{vale a dire se si usa + l'opzione \texttt{-O1} o superiore del \texttt{gcc}.} mentre con il + valore \texttt{2} vengono aggiunti maggiori controlli. -% TODO Da fare (o cassare, a seconda del tempo e della voglia). +\end{basedescript} +Se non è stata specificata esplicitamente nessuna di queste macro il default +assunto è che siano definite \macro{\_BSD\_SOURCE}, \macro{\_SVID\_SOURCE}, +\macro{\_POSIX\_SOURCE}, e \macro{\_POSIX\_C\_SOURCE} con valore +``\texttt{200112L}'' (o ``\texttt{199506L}'' per le versioni delle \acr{glibc} +precedenti la 2.4). Si ricordi infine che perché queste macro abbiano effetto +devono essere sempre definite prima dell'inclusione dei file di dichiarazione. -% LocalWords: like kernel multitasking scheduler prehemptive sez swap is cap +% vedi anche man feature_test_macros + +% 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 @@ -737,8 +1008,12 @@ 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 SAFE overflow memcpy +% LocalWords: mempcpy memmove memset stpcpy strcpy strncpy strcat strncat gets +% LocalWords: sprintf snprintf vsprintf vsnprintf %%% Local Variables: %%% mode: latex