Bug

La diffusione dell'uso del termine bug, che in inglese indica genericamente un piccolo insetto, è legato a un curioso aneddoto risalente ai tempi pionieristici dell'informatica: il 9 settembre 1947 la tenente Grace Hopper e il suo gruppo stavano cercando la causa del malfunzionamento di un computer Mark II quando, con stupore, si accorsero che una falena si era incastrata tra i circuiti. Dopo aver rimosso l'insetto (alle ore 15:45), operazione che avrebbe ripristinato il regolare funzionamento dell'elaboratore, la Hopper incollò la falena rimossa sul registro del computer e annotò: «1545. Relay #70 Panel F (moth) in relay. First actual case of bug being found». Questo registro è conservato presso lo Smithsonian National Museum of American History.^[4]

In realtà il termine bug nel senso di problema tecnico è stato usato almeno dal 1870: è citato in questo senso in una lettera di Thomas Edison del 1878, probabilmente questo uso del termine è di origine scozzese.

Durante lo sviluppo e l'esecuzione di un codice sorgente possono verificarsi i cosiddetti "errori di programmazione" che si possono distinguere essenzialmente in tre principali categorie: errori di sintassi, errori in esecuzione o di runtime, ed errori nella logica del programma.

• Gli errori di sintassi sono gli errori che si commettono nella fase di scrittura del programma nel linguaggio scelto, fase successiva alla progettazione dell'algoritmo. Sono in genere errori di ortografia nella scrittura del codice o nell'uso delle istruzioni. Gli errori di sintassi impediscono la compilazione del programma da parte del compilatore, che quindi tipicamente segnala la presenza dell'errore. Questo tipo di errore è spesso segnalato al programmatore direttamente dall'editor dell'ambiente integrato di sviluppo (IDE) utilizzato, risultando dunque di facile individuazione e soluzione.
• Gli errori di runtime sono errori che possono verificarsi nella fase in cui il programma viene eseguito (in inglese run), anche se l'algoritmo è corretto e il codice viene compilato correttamente. Spesso sono relativi all'utilizzo della memoria da parte del programma stesso, che tenta ad esempio di scrivere o leggere dati in una locazione di memoria alla quale non ha accesso. Questi errori si verificano principalmente nell'indicizzazione di array e nell'utilizzo dei puntatori. Un altro esempio si ha quando il programma tenta di eseguire operazioni non lecite (ad esempio, in alcuni linguaggi, una divisione per zero). Le eccezioni e i costrutti per la loro gestione sono uno dei principali strumenti che i linguaggi di programmazione mettono a disposizione per trattare gli errori di run-time.
• Gli errori di logica (o semantica) sono gli errori che si commettono nella fase di progettazione o più spesso di implementazione dell'algoritmo: possono essere causati da una mancata comprensione del problema da calcolare o dei vincoli che i dati in input devono rispettare, da errori nella valutazione del test dell'algoritmo o ancora, semplicemente, da un errato uso del linguaggio che però non dà luogo a errori di sintassi. Questi errori conducono tipicamente alla progettazione di un algoritmo che non fornisce l'output richiesto nell'ambito di una o più istanze del problema da risolvere, oppure a un programma che non esegue le operazioni volute. Sono difficili da individuare e spesso si deve ricorrere al debugging tramite un debugger, un programma che normalmente si trova anche integrato nell'IDE.

Quanto indicato riferendosi al compilatore vale naturalmente anche per programmi interpretati, come per esempio Python, PHP, JavaScript, Matlab, per citare alcuni tra i più popolari. In questi casi, data la possibilità di eseguire i comandi in modo interattivo, può essere più semplice rilevare gli errori anche senza l'uso di un debugger, che è comunque ugualmente disponibile in molti casi.

Molto raramente può accadere che un compilatore difettoso produca un errore anche se il codice sorgente è corretto.

• Errore concettuale - pseudobug: il codice è scritto correttamente ma il programma era destinato a fare qualcosa di diverso, per esempio: in C e C++ un punto e virgola isolato indica l'istruzione vuota, per cui un ciclo scritto come for (i = 0; i<10; i++); faiqualcosa(); eseguirà dieci volte l'istruzione nulla e chiamerà una sola volta la funzione "faiqualcosa()".
• Loop e ricorsione infiniti in cui la condizione necessaria all'arresto non si verifica mai, per esempio: in C o C++ x = 0; while(x>=0) { faiqualcosa(); x++; } non si può arrestare perché l'espressione logica risulta vera per qualunque valore di x.
• Uso di una variabile non inizializzata.
• Uso di una variabile di tipo non appropriato o dimensionata in modo non corretto, per esempio: usare una variabile di tipo intero a 8 bit con segno (spesso chiamato int8) per memorizzare valori positivi tra 0 e 255.
• Perdita di risorse, in un sistema in cui la memoria è esaurita per l'assegnazione ripetuta di nuove unità e la non liberazione di altre unità.
• Buffer overflow, in cui un programma continua a scrivere dati anche dopo aver riempito l'area di memoria prevista.
• Perdita a causa degli arrotondamenti, per esempio, nel tipo di conversione di un numero. Un caso tipico si verifica nelle espressioni che coinvolgono operandi di tipo diverso, per esempio: con l'usuale ordine di valutazione e secondo comuni regole di conversione implicita dei tipi, se i è una variabile intera minore di N calcolare la percentuale con l'espressione i/N*100 darà zero, a differenza di i*100/N.

Meno comunemente, il termine bug può indicare un difetto di progettazione in un componente hardware, che ne causa un comportamento imprevisto o comunque diverso da quello specificato dal produttore. Ad esempio un noto bug in un componente hardware è quello che nel 1994 afflisse l'allora neonato microprocessore Pentium, che in determinate situazioni restituiva risultati errati anche in semplici calcoli aritmetici. I primi Pentium infatti avevano problemi nella FPU (Floating Point Unit, Unità a virgola mobile o coprocessore matematico), a causa della quale restituivano valori errati in alcune operazioni decimali. In un primo tempo venne pubblicato un programma che escludeva questa unità; in seguito tutti i microprocessori vennero sostituiti.

Un bug può avere una grande varietà di effetti. Alcuni incidono poco sulla funzionalità del programma e quindi possono rimanere sconosciuti per lungo tempo. Al contrario, se il baco è abbastanza grave, può causare il crash o un blocco del programma che porta ad una negazione del servizio richiesto. Altri, qualificati come bachi della sicurezza, potrebbero consentire a un utente malintenzionato di aggirare i controlli di accesso, al fine di ottenere privilegi non autorizzati.

Gli effetti dei bachi possono giungere ad essere estremamente gravi: negli anni ottanta, in Canada e negli Stati Uniti d'America, alcuni bachi presenti nel software di controllo di un macchinario per la radioterapia, il Therac-25, portarono gli apparecchi prima ad erogare una quantità eccessiva di radiazioni senza sistemi di protezione attivi e poi ad attivarsi quando non richiesto, rendendosi direttamente responsabili del decesso di alcuni pazienti. Da allora tali eventi vengono spesso utilizzati come esempi per mostrare e far comprendere quali pericoli possa causare una cattiva programmazione, soprattutto nei software con finalità pratiche.^[6]

Nel 2002 il National Institute of Standards and Technology ha calcolato che i bug e gli errori software hanno causato una perdita di 59 miliardi di dollari negli USA, l'equivalente dello 0,6% del PIL.^[7]

Durante la progettazione del software, l'immissione dei dati o la traduzione (compilazione, interpretazione od assemblazione) del codice sorgente, possono pervenire degli errori (per lo più derivanti da fattori umani come sviste o inaccortezze) nell'eseguibile ottenuto, i quali vanno a costituire i bug.

L'errore che causa un bug è difficilmente un errore di sintassi, perché il compilatore avvertirebbe immediatamente il programmatore arrestando il processo di compilazione; per questo sono molto più "insidiosi" gli errori logici nella stesura dell'algoritmo.

L'industria del software è continuamente impegnata nella ricerca sul prevenire l'introduzione di bachi durante la scrittura del programma, per facilitare la scrittura e diminuire i tempi di sviluppo. Gli approcci e i metodi più comuni sono:

• Stile di programmazione Se si incontra un'incoerenza dei dati in un programma durante la sua l'esecuzione, esso è in grado di fermarsi immediatamente, in modo che il baco sia localizzato. In alternativa il programma può semplicemente informare l'utente, attendere la correzione e continuare l'esecuzione.
• Metodologie di sviluppo Esistono diversi sistemi per la gestione delle attività di programmazione per far sì che il numero di bachi prodotti sia minor possibile. Quest'attività rientra nella disciplina di ingegneria del software e il suo scopo è eliminare il bug già in fase di progettazione del software.
• Ausilio del linguaggio di programmazione I linguaggi di programmazione spesso includono funzionalità che aiutano i programmatori ad evitare errori. Ad esempio se un programmatore utilizza una variabile di un tipo errato, il codice non riesce a compilare anche se è sintatticamente corretto.
• Analisi del codice Esistono strumenti per l'analisi del codice per aiutare gli sviluppatori a controllare il testo del programma, come ad esempio il compilatore che è in grado di individuare potenziali problemi.

  Lo stesso argomento in dettaglio: Debugging.

Tipicamente il primo passo nell'individuazione di un bug è trovare un modo per riprodurlo facilmente. Una volta che l'errore viene riprodotto, il programmatore può usare un debugger per seguire l'esecuzione nella regione difettosa e trovare il punto in cui il programma dà problemi. A volte un baco non riguarda una singola istruzione, ma rappresenta un errore concettuale da parte del programmatore. Una volta individuato l'errore si procede appunto alla correzione o eliminazione.

In inglese informatico, ormai diffuso anche in altre lingue, il fix è il correttivo cioè la riparazione di un bug. Fix è un termine generico che corrisponde a soluzioni definitive diverse, a seconda dei casi. Una soluzione temporanea che non corregge il bug ma ne contiene l'effetto è il workaround.

È comune pubblicare un programma con bachi conosciuti che non sono considerati gravi; successivamente il baco potrebbe essere corretto con una nuova versione o attraverso una patch.

Diversi produttori (ad esempio Microsoft), sui loro bollettini, usano l'espressione inglese addesses an issue (lett. "affrontata una questione", tradotta nella versione italiana con risolto un problema) per indicare un concetto un po' più ampio di un bug o per non ricorrere ad un termine specialistico nei confronti dell'utente-consumatore. Google usa un'espressione ibrida (fix for issue), altri produttori quella resolved an issue, con il consueto significato.

Mentre il bug è un errore di scrittura del codice del programma un glitch è un errore prevalentemente di tipo visivo o di maggior entità.

• G. Michael Schneider, Judith L. Gersting, Informatica, Apogeo, 2007.

• Anti-pattern
• Bug tracking system
• Debugger
• Debugging
• Hexedit
• Grace Murray Hopper
• Heisenbug
• Difetto
• Programmazione (informatica)
• Eccezione (informatica)

•   Wikiquote contiene citazioni sul bug
•   Wikizionario contiene il lemma di dizionario «bug»
•   Wikimedia Commons contiene immagini o altri file sul bug

• baco, su Treccani.it – Enciclopedie on line, Istituto dell'Enciclopedia Italiana.  
• baco², su Vocabolario Treccani, Istituto dell'Enciclopedia Italiana.  
• bug, su sapere.it, De Agostini.  
• (EN) Denis Howe, bug, in Free On-line Dictionary of Computing. Disponibile con licenza GFDL
• (EN) Thomas Huckle (TU München), Collection of Software Bugs, su www5.in.tum.de.
• (EN) Nancy Leveson (University of Washington) e Clark S. Turner (University of California a Irvine), An Investigation of the Therac-25 Accidents, su courses.cs.vt.edu (archiviato dall'url originale il 27 dicembre 2016).
• (EN) Nachum Dershowitz, Software Horror Stories, su cs.tau.ac.il.
• Simon G. Tatham, Come segnalare bug efficacemente, su chiark.greenend.org.uk, 1999.
• (EN) Rates of Design Failure, su rustyspigot.com. URL consultato il 21 gennaio 2010 (archiviato dall'url originale il 24 aprile 2010).
• (EN) Mitch Allen, Bug Tracking Basics: A beginner's guide to reporting and tracking defects, su stickyminds.com.
• (EN) History's Worst Software Bugs, su wired.com, 2005.
• (EN) BugSpy - Open source bug search engine, su bugspy.net. URL consultato il 30 ottobre 2019 (archiviato dall'url originale il 27 marzo 2010).
• (EN) The Cooperative Bug Isolation Project (progetto che traccia i bug di popolari software open source), su cs.wisc.edu.

  Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica