Commit b67aa4ef authored by Federico Vaga's avatar Federico Vaga Committed by Jonathan Corbet

doc:it_IT: align Italian translation

Translation for the following patches:

commit c4f4af40 ("docs: Add documentation for Symbol Namespaces")
commit 36bc683d ("kernel-doc: rename the kernel-doc directive 'functions' to 'identifiers'")
commit a035d552 ("Makefile: Globally enable fall-through warning")
commit b9918bdc ("Documentation/process: Add fallthrough pseudo-keyword")
commit 58ad30cf ("docs: fix reference to core-api/namespaces.rst")
commit fb0e0ffe ("Documentation: bring process docs up to date")
commit 7af51678 ("docs: deprecated.rst: Add BUG()-family")
commit 7929b983 ("docs: Remove :c:func: from process/deprecated.rst")
commit 76136e02 ("docs: deprecated.rst: Clean up fall-through details")
commit d8401f50 ("docs: deprecated.rst: Add %p to the list")
commit b1735296 ("docs: locking: Drop :c:func: throughout")
commit 6adb7755 ("docs: locking: Add 'need' to hardirq section")
Signed-off-by: default avatarFederico Vaga <federico.vaga@vaga.pv.it>
Link: https://lore.kernel.org/r/20200430222037.4480-1-federico.vaga@vaga.pv.itSigned-off-by: default avatarJonathan Corbet <corbet@lwn.net>
parent 16a398d1
...@@ -515,6 +515,22 @@ internal: *[source-pattern ...]* ...@@ -515,6 +515,22 @@ internal: *[source-pattern ...]*
.. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c
:internal: :internal:
identifiers: *[ function/type ...]*
Include la documentazione per ogni *function* e *type* in *source*.
Se non vengono esplicitamente specificate le funzioni da includere, allora
verranno incluse tutte quelle disponibili in *source*.
Esempi::
.. kernel-doc:: lib/bitmap.c
:identifiers: bitmap_parselist bitmap_parselist_user
.. kernel-doc:: lib/idr.c
:identifiers:
functions: *[ function ...]*
Questo è uno pseudonimo, deprecato, per la direttiva 'identifiers'.
doc: *title* doc: *title*
Include la documentazione del paragrafo ``DOC:`` identificato dal titolo Include la documentazione del paragrafo ``DOC:`` identificato dal titolo
(*title*) all'interno del file sorgente (*source*). Gli spazi in *title* sono (*title*) all'interno del file sorgente (*source*). Gli spazi in *title* sono
...@@ -528,15 +544,6 @@ doc: *title* ...@@ -528,15 +544,6 @@ doc: *title*
.. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c
:doc: High Definition Audio over HDMI and Display Port :doc: High Definition Audio over HDMI and Display Port
functions: *function* *[...]*
Dal file sorgente (*source*) include la documentazione per le funzioni
elencate (*function*).
Esempio::
.. kernel-doc:: lib/bitmap.c
:functions: bitmap_parselist bitmap_parselist_user
Senza alcuna opzione, la direttiva kernel-doc include tutti i commenti di Senza alcuna opzione, la direttiva kernel-doc include tutti i commenti di
documentazione presenti nel file sorgente (*source*). documentazione presenti nel file sorgente (*source*).
......
...@@ -627,6 +627,24 @@ Alcuni manutentori e sviluppatori potrebbero comunque richiedere ...@@ -627,6 +627,24 @@ Alcuni manutentori e sviluppatori potrebbero comunque richiedere
:c:func:`EXPORT_SYMBOL_GPL()` quando si aggiungono nuove funzionalità o :c:func:`EXPORT_SYMBOL_GPL()` quando si aggiungono nuove funzionalità o
interfacce. interfacce.
:c:func:`EXPORT_SYMBOL_NS()`
----------------------------
Definita in ``include/linux/export.h``
Questa è una variate di `EXPORT_SYMBOL()` che permette di specificare uno
spazio dei nomi. Lo spazio dei nomi è documentato in
:doc:`../core-api/symbol-namespaces`
:c:func:`EXPORT_SYMBOL_NS_GPL()`
--------------------------------
Definita in ``include/linux/export.h``
Questa è una variate di `EXPORT_SYMBOL_GPL()` che permette di specificare uno
spazio dei nomi. Lo spazio dei nomi è documentato in
:doc:`../core-api/symbol-namespaces`
Procedure e convenzioni Procedure e convenzioni
======================= =======================
......
...@@ -23,18 +23,18 @@ ogni due o tre mesi viene effettuata un rilascio importante del kernel. ...@@ -23,18 +23,18 @@ ogni due o tre mesi viene effettuata un rilascio importante del kernel.
I rilasci più recenti sono stati: I rilasci più recenti sono stati:
====== ================= ====== =================
4.11 Aprile 30, 2017 5.0 3 marzo, 2019
4.12 Luglio 2, 2017 5.1 5 maggio, 2019
4.13 Settembre 3, 2017 5.2 7 luglio, 2019
4.14 Novembre 12, 2017 5.3 15 settembre, 2019
4.15 Gennaio 28, 2018 5.4 24 novembre, 2019
4.16 Aprile 1, 2018 5.5 6 gennaio, 2020
====== ================= ====== =================
Ciascun rilascio 4.x è un importante rilascio del kernel con nuove Ciascun rilascio 5.x è un importante rilascio del kernel con nuove
funzionalità, modifiche interne dell'API, e molto altro. Un tipico funzionalità, modifiche interne dell'API, e molto altro. Un tipico
rilascio 4.x contiene quasi 13,000 gruppi di modifiche con ulteriori rilascio contiene quasi 13,000 gruppi di modifiche con ulteriori
modifiche a parecchie migliaia di linee di codice. La 4.x. è pertanto la modifiche a parecchie migliaia di linee di codice. La 5.x. è pertanto la
linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema
di sviluppo continuo che integra costantemente nuove importanti modifiche. di sviluppo continuo che integra costantemente nuove importanti modifiche.
...@@ -55,8 +55,8 @@ verrà descritto dettagliatamente più avanti). ...@@ -55,8 +55,8 @@ verrà descritto dettagliatamente più avanti).
La finestra di inclusione resta attiva approssimativamente per due settimane. La finestra di inclusione resta attiva approssimativamente per due settimane.
Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è
chiusa e rilascerà il primo degli "rc" del kernel. chiusa e rilascerà il primo degli "rc" del kernel.
Per il kernel che è destinato ad essere 2.6.40, per esempio, il rilascio Per il kernel che è destinato ad essere 5.6, per esempio, il rilascio
che emerge al termine della finestra d'inclusione si chiamerà 2.6.40-rc1. che emerge al termine della finestra d'inclusione si chiamerà 5.6-rc1.
Questo rilascio indica che il momento di aggiungere nuovi componenti è Questo rilascio indica che il momento di aggiungere nuovi componenti è
passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel. passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.
...@@ -76,22 +76,23 @@ Mentre le correzioni si aprono la loro strada all'interno del ramo principale, ...@@ -76,22 +76,23 @@ Mentre le correzioni si aprono la loro strada all'interno del ramo principale,
il ritmo delle modifiche rallenta col tempo. Linus rilascia un nuovo il ritmo delle modifiche rallenta col tempo. Linus rilascia un nuovo
kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima
che il kernel venga considerato sufficientemente stabile e che il rilascio che il kernel venga considerato sufficientemente stabile e che il rilascio
finale 2.6.x venga fatto. A quel punto tutto il processo ricomincerà. finale venga fatto. A quel punto tutto il processo ricomincerà.
Esempio: ecco com'è andato il ciclo di sviluppo della versione 4.16 Esempio: ecco com'è andato il ciclo di sviluppo della versione 5.4
(tutte le date si collocano nel 2018) (tutte le date si collocano nel 2018)
============== ======================================= ============== =======================================
Gennaio 28 4.15 rilascio stabile 15 settembre 5.3 rilascio stabile
Febbraio 11 4.16-rc1, finestra di inclusione chiusa 30 settembre 5.4-rc1, finestra di inclusione chiusa
Febbraio 18 4.16-rc2 6 ottobre 5.4-rc2
Febbraio 25 4.16-rc3 13 ottobre 5.4-rc3
Marzo 4 4.16-rc4 20 ottobre 5.4-rc4
Marzo 11 4.16-rc5 27 ottobre 5.4-rc5
Marzo 18 4.16-rc6 3 novembre 5.4-rc6
Marzo 25 4.16-rc7 10 novembre 5.4-rc7
Aprile 1 4.17 rilascio stabile 17 novembre 5.4-rc8
24 novembre 5.4 rilascio stabile
============== ======================================= ============== =======================================
In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e
...@@ -108,43 +109,44 @@ tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili ...@@ -108,43 +109,44 @@ tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili
in un progetto di questa portata. Arriva un punto dove ritardare il rilascio in un progetto di questa portata. Arriva un punto dove ritardare il rilascio
finale peggiora la situazione; la quantità di modifiche in attesa della finale peggiora la situazione; la quantità di modifiche in attesa della
prossima finestra di inclusione crescerà enormemente, creando ancor più prossima finestra di inclusione crescerà enormemente, creando ancor più
regressioni al giro successivo. Quindi molti kernel 4.x escono con una regressioni al giro successivo. Quindi molti kernel 5.x escono con una
manciata di regressioni delle quali, si spera, nessuna è grave. manciata di regressioni delle quali, si spera, nessuna è grave.
Una volta che un rilascio stabile è fatto, il suo costante mantenimento è Una volta che un rilascio stabile è fatto, il suo costante mantenimento è
affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman. affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.
Questa squadra rilascia occasionalmente degli aggiornamenti relativi al Questa squadra rilascia occasionalmente degli aggiornamenti relativi al
rilascio stabile usando la numerazione 4.x.y. Per essere presa in rilascio stabile usando la numerazione 5.x.y. Per essere presa in
considerazione per un rilascio d'aggiornamento, una modifica deve: considerazione per un rilascio d'aggiornamento, una modifica deve:
(1) correggere un baco importante (2) essere già inserita nel ramo principale (1) correggere un baco importante (2) essere già inserita nel ramo principale
per il prossimo sviluppo del kernel. Solitamente, passato il loro rilascio per il prossimo sviluppo del kernel. Solitamente, passato il loro rilascio
iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo. iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.
Quindi, per esempio, la storia del kernel 4.13 appare così: Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019):
============== =============================== ============== ===============================
Settembre 3 4.13 rilascio stabile 15 settembre 5.2 rilascio stabile FIXME settembre è sbagliato
Settembre 13 4.13.1 14 luglio 5.2.1
Settembre 20 4.13.2 21 luglio 5.2.2
Settembre 27 4.13.3 26 luglio 5.2.3
Ottobre 5 4.13.4 28 luglio 5.2.4
Ottobre 12 4.13.5 31 luglio 5.2.5
... ... ... ...
Novembre 24 4.13.16 11 ottobre 5.2.21
============== =============================== ============== ===============================
La 4.13.16 fu l'aggiornamento finale per la versione 4.13. La 5.2.21 fu l'aggiornamento finale per la versione 5.2.
Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi
riceveranno assistenza per un lungo periodo di tempo. Al momento in cui riceveranno assistenza per un lungo periodo di tempo. Al momento in cui
scriviamo, i manutentori dei kernel stabili a lungo termine sono: scriviamo, i manutentori dei kernel stabili a lungo termine sono:
====== ====================== ========================================== ====== ================================ ==========================================
3.16 Ben Hutchings (kernel stabile molto più a lungo termine) 3.16 Ben Hutchings (kernel stabile molto più a lungo termine)
4.1 Sasha Levin 4.4 Greg Kroah-Hartman e Sasha Levin (kernel stabile molto più a lungo termine)
4.4 Greg Kroah-Hartman (kernel stabile molto più a lungo termine) 4.9 Greg Kroah-Hartman e Sasha Levin
4.9 Greg Kroah-Hartman 4.14 Greg Kroah-Hartman e Sasha Levin
4.14 Greg Kroah-Hartman 4.19 Greg Kroah-Hartman e Sasha Levin
====== ====================== ========================================== 5.4i Greg Kroah-Hartman e Sasha Levin
====== ================================ ==========================================
Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
...@@ -229,12 +231,13 @@ Come le modifiche finiscono nel Kernel ...@@ -229,12 +231,13 @@ Come le modifiche finiscono nel Kernel
-------------------------------------- --------------------------------------
Esiste una sola persona che può inserire le patch nel repositorio principale Esiste una sola persona che può inserire le patch nel repositorio principale
del kernel: Linus Torvalds. Ma, di tutte le 9500 patch che entrarono nella del kernel: Linus Torvalds. Ma, per esempio, di tutte le 9500 patch
versione 2.6.38 del kernel, solo 112 (circa l'1,3%) furono scelte direttamente che entrarono nella versione 2.6.38 del kernel, solo 112 (circa
da Linus in persona. Il progetto del kernel è cresciuto fino a raggiungere l'1,3%) furono scelte direttamente da Linus in persona. Il progetto
una dimensione tale per cui un singolo sviluppatore non può controllare e del kernel è cresciuto fino a raggiungere una dimensione tale per cui
selezionare indipendentemente ogni modifica senza essere supportato. un singolo sviluppatore non può controllare e selezionare
La via scelta dagli sviluppatori per indirizzare tale crescita è stata quella indipendentemente ogni modifica senza essere supportato. La via
scelta dagli sviluppatori per indirizzare tale crescita è stata quella
di utilizzare un sistema di "sottotenenti" basato sulla fiducia. di utilizzare un sistema di "sottotenenti" basato sulla fiducia.
Il codice base del kernel è spezzato in una serie si sottosistemi: rete, Il codice base del kernel è spezzato in una serie si sottosistemi: rete,
......
...@@ -313,7 +313,7 @@ che conta gli utenti attivi, dovreste chiamarla ``count_active_users()`` o ...@@ -313,7 +313,7 @@ che conta gli utenti attivi, dovreste chiamarla ``count_active_users()`` o
qualcosa di simile, **non** dovreste chiamarla ``cntusr()``. qualcosa di simile, **non** dovreste chiamarla ``cntusr()``.
Codificare il tipo di funzione nel suo nome (quella cosa chiamata notazione Codificare il tipo di funzione nel suo nome (quella cosa chiamata notazione
ungherese) fa male al cervello - il compilatore conosce comunque il tipo e ungherese) è stupido - il compilatore conosce comunque il tipo e
può verificarli, e inoltre confonde i programmatori. Non c'è da può verificarli, e inoltre confonde i programmatori. Non c'è da
sorprendersi che MicroSoft faccia programmi bacati. sorprendersi che MicroSoft faccia programmi bacati.
...@@ -825,8 +825,8 @@ linguaggio assembler. ...@@ -825,8 +825,8 @@ linguaggio assembler.
Agli sviluppatori del kernel piace essere visti come dotti. Tenete un occhio Agli sviluppatori del kernel piace essere visti come dotti. Tenete un occhio
di riguardo per l'ortografia e farete una belle figura. In inglese, evitate di riguardo per l'ortografia e farete una belle figura. In inglese, evitate
l'uso di parole mozzate come ``dont``: usate ``do not`` oppure ``don't``. l'uso incorretto di abbreviazioni come ``dont``: usate ``do not`` oppure
Scrivete messaggi concisi, chiari, e inequivocabili. ``don't``. Scrivete messaggi concisi, chiari, e inequivocabili.
I messaggi del kernel non devono terminare con un punto fermo. I messaggi del kernel non devono terminare con un punto fermo.
......
...@@ -34,6 +34,33 @@ interfaccia come 'vecchia', questa non è una soluzione completa. L'interfaccia ...@@ -34,6 +34,33 @@ interfaccia come 'vecchia', questa non è una soluzione completa. L'interfaccia
deve essere rimossa dal kernel, o aggiunta a questo documento per scoraggiarne deve essere rimossa dal kernel, o aggiunta a questo documento per scoraggiarne
l'uso. l'uso.
BUG() e BUG_ON()
----------------
Al loro posto usate WARN() e WARN_ON() per gestire le
condizioni "impossibili" e gestitele come se fosse possibile farlo.
Nonostante le funzioni della famiglia BUG() siano state progettate
per asserire "situazioni impossibili" e interrompere in sicurezza un
thread del kernel, queste si sono rivelate essere troppo rischiose
(per esempio, in quale ordine rilasciare i *lock*? Ci sono stati che
sono stati ripristinati?). Molto spesso l'uso di BUG()
destabilizza il sistema o lo corrompe del tutto, il che rende
impossibile un'attività di debug o anche solo leggere un rapporto
circa l'errore. Linus ha un'opinione molto critica al riguardo:
`email 1
<https://lore.kernel.org/lkml/CA+55aFy6jNLsywVYdGp83AMrXBo_P-pkjkphPGrO=82SPKCpLQ@mail.gmail.com/>`_,
`email 2
<https://lore.kernel.org/lkml/CAHk-=whDHsbK3HTOpTF=ue_o04onRwTEaK_ZoJp_fjbqq4+=Jw@mail.gmail.com/>`_
Tenete presente che la famiglia di funzioni WARN() dovrebbe essere
usato solo per situazioni che si suppone siano "impossibili". Se
volete avvisare gli utenti riguardo a qualcosa di possibile anche se
indesiderato, usare le funzioni della famiglia pr_warn(). Chi
amministra il sistema potrebbe aver attivato l'opzione sysctl
*panic_on_warn* per essere sicuri che il sistema smetta di funzionare
in caso si verifichino delle condizioni "inaspettate". (per esempio,
date un'occhiata al questo `commit
<https://git.kernel.org/linus/d4689846881d160a4d12a514e991a740bcb5d65a>`_)
Calcoli codificati negli argomenti di un allocatore Calcoli codificati negli argomenti di un allocatore
---------------------------------------------------- ----------------------------------------------------
Il calcolo dinamico delle dimensioni (specialmente le moltiplicazioni) non Il calcolo dinamico delle dimensioni (specialmente le moltiplicazioni) non
...@@ -68,52 +95,81 @@ Invece, usate la seguente funzione:: ...@@ -68,52 +95,81 @@ Invece, usate la seguente funzione::
header = kzalloc(struct_size(header, item, count), GFP_KERNEL); header = kzalloc(struct_size(header, item, count), GFP_KERNEL);
Per maggiori dettagli fate riferimento a :c:func:`array_size`, Per maggiori dettagli fate riferimento a array_size(),
:c:func:`array3_size`, e :c:func:`struct_size`, così come la famiglia di array3_size(), e struct_size(), così come la famiglia di
funzioni :c:func:`check_add_overflow` e :c:func:`check_mul_overflow`. funzioni check_add_overflow() e check_mul_overflow().
simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull() simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull()
---------------------------------------------------------------------- ----------------------------------------------------------------------
Le funzioni :c:func:`simple_strtol`, :c:func:`simple_strtoll`, Le funzioni simple_strtol(), simple_strtoll(),
:c:func:`simple_strtoul`, e :c:func:`simple_strtoull` ignorano volutamente simple_strtoul(), e simple_strtoull() ignorano volutamente
i possibili overflow, e questo può portare il chiamante a generare risultati i possibili overflow, e questo può portare il chiamante a generare risultati
inaspettati. Le rispettive funzioni :c:func:`kstrtol`, :c:func:`kstrtoll`, inaspettati. Le rispettive funzioni kstrtol(), kstrtoll(),
:c:func:`kstrtoul`, e :c:func:`kstrtoull` sono da considerarsi le corrette kstrtoul(), e kstrtoull() sono da considerarsi le corrette
sostitute; tuttavia va notato che queste richiedono che la stringa sia sostitute; tuttavia va notato che queste richiedono che la stringa sia
terminata con il carattere NUL o quello di nuova riga. terminata con il carattere NUL o quello di nuova riga.
strcpy() strcpy()
-------- --------
La funzione :c:func:`strcpy` non fa controlli agli estremi del buffer La funzione strcpy() non fa controlli agli estremi del buffer
di destinazione. Questo può portare ad un overflow oltre i limiti del di destinazione. Questo può portare ad un overflow oltre i limiti del
buffer e generare svariati tipi di malfunzionamenti. Nonostante l'opzione buffer e generare svariati tipi di malfunzionamenti. Nonostante l'opzione
`CONFIG_FORTIFY_SOURCE=y` e svariate opzioni del compilatore aiutano `CONFIG_FORTIFY_SOURCE=y` e svariate opzioni del compilatore aiutano
a ridurne il rischio, non c'è alcuna buona ragione per continuare ad usare a ridurne il rischio, non c'è alcuna buona ragione per continuare ad usare
questa funzione. La versione sicura da usare è :c:func:`strscpy`. questa funzione. La versione sicura da usare è strscpy().
strncpy() su stringe terminate con NUL strncpy() su stringe terminate con NUL
-------------------------------------- --------------------------------------
L'utilizzo di :c:func:`strncpy` non fornisce alcuna garanzia sul fatto che L'utilizzo di strncpy() non fornisce alcuna garanzia sul fatto che
il buffer di destinazione verrà terminato con il carattere NUL. Questo il buffer di destinazione verrà terminato con il carattere NUL. Questo
potrebbe portare a diversi overflow di lettura o altri malfunzionamenti potrebbe portare a diversi overflow di lettura o altri malfunzionamenti
causati, appunto, dalla mancanza del terminatore. Questa estende la causati, appunto, dalla mancanza del terminatore. Questa estende la
terminazione nel buffer di destinazione quando la stringa d'origine è più terminazione nel buffer di destinazione quando la stringa d'origine è più
corta; questo potrebbe portare ad una penalizzazione delle prestazioni per corta; questo potrebbe portare ad una penalizzazione delle prestazioni per
chi usa solo stringe terminate. La versione sicura da usare è chi usa solo stringe terminate. La versione sicura da usare è
:c:func:`strscpy`. (chi usa :c:func:`strscpy` e necessita di estendere la strscpy(). (chi usa strscpy() e necessita di estendere la
terminazione con NUL deve aggiungere una chiamata a :c:func:`memset`) terminazione con NUL deve aggiungere una chiamata a memset())
Se il chiamate no usa stringhe terminate con NUL, allore :c:func:`strncpy()` Se il chiamate no usa stringhe terminate con NUL, allore strncpy()()
può continuare ad essere usata, ma i buffer di destinazione devono essere può continuare ad essere usata, ma i buffer di destinazione devono essere
marchiati con l'attributo `__nonstring <https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_ marchiati con l'attributo `__nonstring <https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_
per evitare avvisi durante la compilazione. per evitare avvisi durante la compilazione.
strlcpy() strlcpy()
--------- ---------
La funzione :c:func:`strlcpy`, per prima cosa, legge interamente il buffer di La funzione strlcpy(), per prima cosa, legge interamente il buffer di
origine, magari leggendo più di quanto verrà effettivamente copiato. Questo origine, magari leggendo più di quanto verrà effettivamente copiato. Questo
è inefficiente e può portare a overflow di lettura quando la stringa non è è inefficiente e può portare a overflow di lettura quando la stringa non è
terminata con NUL. La versione sicura da usare è :c:func:`strscpy`. terminata con NUL. La versione sicura da usare è strscpy().
Segnaposto %p nella stringa di formato
--------------------------------------
Tradizionalmente, l'uso del segnaposto "%p" nella stringa di formato
esponne un indirizzo di memoria in dmesg, proc, sysfs, eccetera. Per
evitare che questi indirizzi vengano sfruttati da malintenzionati,
tutto gli usi di "%p" nel kernel rappresentano l'hash dell'indirizzo,
rendendolo di fatto inutilizzabile. Nuovi usi di "%p" non dovrebbero
essere aggiunti al kernel. Per una rappresentazione testuale di un
indirizzo usate "%pS", l'output è migliore perché mostrerà il nome del
simbolo. Per tutto il resto, semplicemente non usate "%p".
Parafrasando la `guida
<https://lore.kernel.org/lkml/CA+55aFwQEd_d40g4mUCSsVRZzrFPUJt74vc6PPpb675hYNXcKw@mail.gmail.com/>`_
di Linus:
- Se il valore hash di "%p" è inutile, chiediti se il puntatore stesso
è importante. Forse dovrebbe essere rimosso del tutto?
- Se credi davvero che il vero valore del puntatore sia importante,
perché alcuni stati del sistema o i livelli di privilegi di un
utente sono considerati "special"? Se pensi di poterlo giustificare
(in un commento e nel messaggio del commit) abbastanza bene da
affrontare il giudizio di Linus, allora forse potrai usare "%px",
assicurandosi anche di averne il permesso.
Infine, sappi che un cambio in favore di "%p" con hash `non verrà
accettato
<https://lore.kernel.org/lkml/CA+55aFwieC1-nAs+NFq9RTwaR8ef9hWa4MjNBWL41F-8wM49eA@mail.gmail.com/>`_.
Vettori a dimensione variabile (VLA) Vettori a dimensione variabile (VLA)
------------------------------------ ------------------------------------
...@@ -127,3 +183,47 @@ Questo può portare a dei malfunzionamenti, potrebbe sovrascrivere ...@@ -127,3 +183,47 @@ Questo può portare a dei malfunzionamenti, potrebbe sovrascrivere
dati importanti alla fine dello stack (quando il kernel è compilato senza dati importanti alla fine dello stack (quando il kernel è compilato senza
`CONFIG_THREAD_INFO_IN_TASK=y`), o sovrascrivere un pezzo di memoria adiacente `CONFIG_THREAD_INFO_IN_TASK=y`), o sovrascrivere un pezzo di memoria adiacente
allo stack (quando il kernel è compilato senza `CONFIG_VMAP_STACK=y`). allo stack (quando il kernel è compilato senza `CONFIG_VMAP_STACK=y`).
Salto implicito nell'istruzione switch-case
-------------------------------------------
Il linguaggio C permette ai casi di un'istruzione `switch` di saltare al
prossimo caso quando l'istruzione "break" viene omessa alla fine del caso
corrente. Tuttavia questo rende il codice ambiguo perché non è sempre ovvio se
l'istruzione "break" viene omessa intenzionalmente o è un baco. Per esempio,
osservando il seguente pezzo di codice non è chiaro se lo stato
`STATE_ONE` è stato progettato apposta per eseguire anche `STATE_TWO`::
switch (value) {
case STATE_ONE:
do_something();
case STATE_TWO:
do_other();
break;
default:
WARN("unknown state");
}
Dato che c'è stata una lunga lista di problemi `dovuti alla mancanza dell'istruzione
"break" <https://cwe.mitre.org/data/definitions/484.html>`_, oggigiorno non
permettiamo più che vi sia un "salto implicito" (*fall-through*). Per
identificare un salto implicito intenzionale abbiamo adottato la pseudo
parola chiave 'fallthrough' che viene espansa nell'estensione di gcc
`__attribute__((fallthrough))` `Statement Attributes
<https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html>`_.
(Quando la sintassi C17/C18 `[[fallthrough]]` sarà più comunemente
supportata dai compilatori C, analizzatori statici, e dagli IDE,
allora potremo usare quella sintassi per la pseudo parola chiave)
Quando la sintassi [[fallthrough]] sarà più comunemente supportata dai
compilatori, analizzatori statici, e ambienti di sviluppo IDE,
allora potremo usarla anche noi.
Ne consegue che tutti i blocchi switch/case devono finire in uno dei seguenti
modi:
* ``break;``
* `fallthrough;``
* ``continue;``
* ``goto <label>;``
* ``return [expression];``
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment