1.. SPDX-License-Identifier: GPL-2.0
2
3.. include:: ../disclaimer-ita.rst
4
5:Original: :ref:`Documentation/process/deprecated.rst <deprecated>`
6:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
7
8.. _it_deprecated:
9
10==============================================================================
11Interfacce deprecate, caratteristiche del linguaggio, attributi, e convenzioni
12==============================================================================
13
14In un mondo perfetto, sarebbe possibile prendere tutti gli usi di
15un'interfaccia deprecata e convertirli in quella nuova, e così sarebbe
16possibile rimuovere la vecchia interfaccia in un singolo ciclo di sviluppo.
17Tuttavia, per via delle dimensioni del kernel, la gerarchia dei manutentori e
18le tempistiche, non è sempre possibile fare questo tipo di conversione tutta
19in una volta. Questo significa che nuove istanze di una vecchia interfaccia
20potrebbero aggiungersi al kernel proprio quando si sta cercando di rimuoverle,
21aumentando così il carico di lavoro. Al fine di istruire gli sviluppatori su
22cosa è considerato deprecato (e perché), è stata create la seguente lista a cui
23fare riferimento quando qualcuno propone modifiche che usano cose deprecate.
24
25__deprecated
26------------
27Nonostante questo attributo marchi visibilmente un interfaccia come deprecata,
28`non produce più alcun avviso durante la compilazione
29<https://git.kernel.org/linus/771c035372a036f83353eef46dbb829780330234>`_
30perché uno degli obiettivi del kernel è quello di compilare senza avvisi;
31inoltre, nessuno stava agendo per rimuovere queste interfacce. Nonostante l'uso
32di `__deprecated` in un file d'intestazione sia opportuno per segnare una
33interfaccia come 'vecchia', questa non è una soluzione completa. L'interfaccia
34deve essere rimossa dal kernel, o aggiunta a questo documento per scoraggiarne
35l'uso.
36
37Calcoli codificati negli argomenti di un allocatore
38----------------------------------------------------
39Il calcolo dinamico delle dimensioni (specialmente le moltiplicazioni) non
40dovrebbero essere fatto negli argomenti di funzioni di allocazione di memoria
41(o simili) per via del rischio di overflow. Questo può portare a valori più
42piccoli di quelli che il chiamante si aspettava. L'uso di questo modo di
43allocare può portare ad un overflow della memoria di heap e altri
44malfunzionamenti. (Si fa eccezione per valori numerici per i quali il
45compilatore può generare avvisi circa un potenziale overflow. Tuttavia usare
46i valori numerici come suggerito di seguito è innocuo).
47
48Per esempio, non usate ``count * size`` come argomento::
49
50	foo = kmalloc(count * size, GFP_KERNEL);
51
52Al suo posto, si dovrebbe usare l'allocatore a due argomenti::
53
54	foo = kmalloc_array(count, size, GFP_KERNEL);
55
56Se questo tipo di allocatore non è disponibile, allora dovrebbero essere usate
57le funzioni del tipo *saturate-on-overflow*::
58
59	bar = vmalloc(array_size(count, size));
60
61Un altro tipico caso da evitare è quello di calcolare la dimensione di una
62struttura seguita da un vettore di altre strutture, come nel seguente caso::
63
64	header = kzalloc(sizeof(*header) + count * sizeof(*header->item),
65			 GFP_KERNEL);
66
67Invece, usate la seguente funzione::
68
69	header = kzalloc(struct_size(header, item, count), GFP_KERNEL);
70
71Per maggiori dettagli fate riferimento a :c:func:`array_size`,
72:c:func:`array3_size`, e :c:func:`struct_size`, così come la famiglia di
73funzioni :c:func:`check_add_overflow` e :c:func:`check_mul_overflow`.
74
75simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull()
76----------------------------------------------------------------------
77Le funzioni :c:func:`simple_strtol`, :c:func:`simple_strtoll`,
78:c:func:`simple_strtoul`, e :c:func:`simple_strtoull` ignorano volutamente
79i possibili overflow, e questo può portare il chiamante a generare risultati
80inaspettati. Le rispettive funzioni :c:func:`kstrtol`, :c:func:`kstrtoll`,
81:c:func:`kstrtoul`, e :c:func:`kstrtoull` sono da considerarsi le corrette
82sostitute; tuttavia va notato che queste richiedono che la stringa sia
83terminata con il carattere NUL o quello di nuova riga.
84
85strcpy()
86--------
87La funzione :c:func:`strcpy` non fa controlli agli estremi del buffer
88di destinazione. Questo può portare ad un overflow oltre i limiti del
89buffer e generare svariati tipi di malfunzionamenti. Nonostante l'opzione
90`CONFIG_FORTIFY_SOURCE=y` e svariate opzioni del compilatore aiutano
91a ridurne il rischio, non c'è alcuna buona ragione per continuare ad usare
92questa funzione. La versione sicura da usare è :c:func:`strscpy`.
93
94strncpy() su stringe terminate con NUL
95--------------------------------------
96L'utilizzo di :c:func:`strncpy` non fornisce alcuna garanzia sul fatto che
97il buffer di destinazione verrà terminato con il carattere NUL. Questo
98potrebbe portare a diversi overflow di lettura o altri malfunzionamenti
99causati, appunto, dalla mancanza del terminatore. Questa estende la
100terminazione nel buffer di destinazione quando la stringa d'origine è più
101corta; questo potrebbe portare ad una penalizzazione delle prestazioni per
102chi usa solo stringe terminate. La versione sicura da usare è
103:c:func:`strscpy`. (chi usa :c:func:`strscpy` e necessita di estendere la
104terminazione con NUL deve aggiungere una chiamata a :c:func:`memset`)
105
106Se il chiamate no usa stringhe terminate con NUL, allore :c:func:`strncpy()`
107può continuare ad essere usata, ma i buffer di destinazione devono essere
108marchiati con l'attributo `__nonstring <https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_
109per evitare avvisi durante la compilazione.
110
111strlcpy()
112---------
113La funzione :c:func:`strlcpy`, per prima cosa, legge interamente il buffer di
114origine, magari leggendo più di quanto verrà effettivamente copiato. Questo
115è inefficiente e può portare a overflow di lettura quando la stringa non è
116terminata con NUL. La versione sicura da usare è :c:func:`strscpy`.
117
118Vettori a dimensione variabile (VLA)
119------------------------------------
120
121Usare VLA sullo stack produce codice molto peggiore rispetto a quando si usano
122vettori a dimensione fissa. Questi `problemi di prestazioni <https://git.kernel.org/linus/02361bc77888>`_,
123tutt'altro che banali, sono già un motivo valido per eliminare i VLA; in
124aggiunta sono anche un problema per la sicurezza. La crescita dinamica di un
125vettore nello stack potrebbe eccedere la memoria rimanente in tale segmento.
126Questo può portare a dei malfunzionamenti, potrebbe sovrascrivere
127dati importanti alla fine dello stack (quando il kernel è compilato senza
128`CONFIG_THREAD_INFO_IN_TASK=y`), o sovrascrivere un pezzo di memoria adiacente
129allo stack (quando il kernel è compilato senza `CONFIG_VMAP_STACK=y`).
130