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
versione di Spec 1170 diventò così la prima versione delle \textit{Single UNIX
- Specification}, più comunemente nota come \textit{Unix 95}.
+ Specification}, SUSv2, più comunemente nota come \textit{Unix 95}.
\subsection{Gli standard UNIX -- Open Group}
alla costituzione dell'Open Group, un consorzio internazionale che raccoglie
produttori, utenti industriali, entità accademiche e governative.
-Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
- Specification}, che portava le interfacce specificate a 1434 (e a 3030 per
-le stazioni grafiche, comprendendo pure la definizione di 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{Il comportamento standard del \cmd{gcc}}
-\label{sec:intro_gcc}
-
+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à
+alle stesse.
+Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
+ Specification}, nota con la sigla SUSv2, in queste 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 ``standard'' BSD}
+\subsection{Il comportamento standard del \cmd{gcc}}
+\label{sec:intro_gcc}
+\subsection{Gli standard nelle \acr{glibc}}
+\label{sec:intro_glibc_std}
-\subsection{Prototipi e puntatori}
-\label{sec:intro_function}
-\subsection{Tipi di dati primitivi}
+\subsection{Gli standard di Linux}
\label{sec:intro_data_types}
La funzione setta la variabile di ambiente \param{name} al valore
\param{value}.
- Entrembe le funzioni ritornano 0 in caso di successo e -1 per un errore, che
+ Entrambe le funzioni ritornano 0 in caso di successo e -1 per un errore, che
è sempre \macro{ENOMEM}.
\funcdecl{void unsetenv(const char *name)}
La funzione rimuove la variabile di ambiente \param{name}.
\end{functions}
-Per modificare o aggiungere una variabile di ambiente si possono usare le
-funzioni \func{putenv} e \func{setenv}. La prima prende come parametro una
-stringa analoga quella restituita da \func{getenv}, e sempre nella forma
-\texttt{NOME=valore}, se la variabile esiste verrà modificata, altrimenti sarà
-aggiunta. La seconda permette di specificare separatamente nome e valore,
-inoltre il valore di \param{overwrite} ne specifica il comportamento nel caso
-la variabile esista già, sovrascrivendola se diverso da zero, lasciandola
-immutata se uguale a zero.
-
Per cancellare una variabile di ambiente si usa \func{unsetenv}, che elimina
-ogni occorrenza della variabile, se questa non esiste non è considerato un
-errore.
-
+ogni occorrenza della variabile, se la variabile specificata non esiste non
+succede nulla, e non è previsto (dato che la funzione è \type{void}) nessuna
+segnalazione di errore.
+Per modificare o aggiungere una variabile di ambiente si possono usare le
+funzioni \func{setenv} e \func{putenv}. La prima permette di specificare
+separatamente nome e valore della variabile di ambiente, inoltre il valore di
+\param{overwrite} specifica il comportamento della funzione nel caso la
+variabile esista già, sovrascrivendola se diverso da zero, lasciandola
+immutata se uguale a zero.
+La seconda funzione prende come parametro una stringa analoga quella
+restituita da \func{getenv}, e sempre nella forma \texttt{NOME=valore}. Se la
+variabile specificata non esiste la stringa sarà aggiunta all'ambiente, se
+invece esiste il suo valore sarà settato a quello specificato da
+\func{string}. Si tenga presente che, seguendo lo standard SUSv2, le
+\acr{glibc} successive alla versione 2.1.2 aggiungono\footnote{il
+ comportamento è lo stesso delle vecchie \acr{libc4} e \acr{libc5}; nelle
+ \acr{glibc}, dalla versione 2.0 alla 2.1.1, veniva invece fatta una copia,
+ seguendo il comportamento di BSD4.4; dato che questo può dar luogo a perdite
+ di memoria e non rispetta lo standard il comportamento è stato modificato a
+ partire dalle 2.1.2, eliminando anche, sempre in conformità a SUSv2,
+ l'attributo \type{const} dal prototipo.} \func{string} alla lista delle
+variabili di ambiente; pertanto ogni cambiamento alla stringa in questione si
+riflette automaticamente sull'ambiente, e quindi si deve evitare di passare
+alla funzione variabili automatiche (per evitare i problemi esposti in
+\secref{sec:proc_auto_var}).
+
+Si tenga infine presente che se si passa a \func{putenv} solo il nome di una
+variabile (cioè \param{string} è nella forma \texttt{NAME} e non contiene un
+\var{=}) allora questa viene cancellata dall'ambiente. Infine se la chiamata
+di \func{putenv} comporta la necessità di allocare una nuova versione del
+vettore \var{environ} questo sarà allocato, ma la versione corrente sarà
+deallocata solo se anch'essa risultante da una allocazione fatta in precedenza
+da un'altra \func{putenv}, il vettore originale (in genere piazzato al di
+sopra dello stack, vedi \figref{fig:proc_mem_layout}), o la memoria associata
+alle variabili di ambiente eliminate non viene comunque liberata.
\section{Problematiche di programmazione generica}
projects / gapil.git / commitdiff