Documentation/translations/it_IT/process/deprecated.rst

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