Bug nel JavaScript di Firefox: dati sensibili a rischio

"Every fool can write code that a machine can understand, only good programmers can write code that a human can understand"

Marin Fowler in "Refactoring: Improving the Design of Existing Code".

Per quel che ho capito da un vecchio (non troppo) articolo di Pc Professionale, il problema principale di Win 9x era la gestione "ibrida" dei processi per ottenere il multitasking, al fine di mantenere compatibilità con il dos: per quelli a 32 bit si realizzava un multitasking prelativo, efficiente, per quelli a 16 bit, compresi alcuni moduli del s.o. stesso, si effettuava un multitasking "cooperativo" (un po' come per il dos, che non era stato pensato per il multitasking), affidando ai processi stessi il compito di rilasciare le risorse a favore degli altri quando lo ritenessero opportuno, oppure (credo) approfittando di un i/o burst per fare uno swapping dei processi, senza un meccanismo di prelazione. Ne conseguiva che, se un processo (a 16 bit) andava in crash, trascinava con sé nel baratro tutti quelli (naturalmente solo quelli a 16 bit) che condividevano/contendevano le stesse risorse, compresi i moduli del kernel a 16 bit, da cui il problema della schermata blu. Con le varie versioni di NT questo problema è stato risolto "cacciando" fuori dal kernel tutto ciò che non è essenziale e i moduli necessari alla compatibilità con il dos e gli applicativi a 16 bit. Con xp di schermate blu ne ho viste ben poche, delle quali una per un paio di ca@@ate fatte da me e le altre per un banco di memoria che stava morendo e, diavolo a farlo apposta, mi dava problemi sempre con lo stesso driver e poche altre cose (dannata polvere ).




Mi è capitato di averci ancora a che fare due o tre anni fa, grazie a un mio amico (e coinquilino) al quale era stato praticamente regalato un piccolo cimelio, un portatile (o forse sarebbe meglio dire "trasportabile", data l'epoca della sua nascita) 286 con 2 mega (se non ricordo male) di ram. E' stato divertente smanettarci un po' e lanciarsi banane da un tetto all'altro... Peccato che di li a poco sia defunto il monitor




Per questo sono convinto che non farebbe male partire con un po' di programmazione strutturata, meglio se in Pascal, per la sua forte tipizzazione. Credo che basti qualche algoritmo di gestione delle liste con inserimenti e (soprattutto) cancellazioni per inquadrare il problema ed estendere poi il concetto senza troppi problemi agli oggetti.

A proposito di oggetti, la versione in Pascal non l'ho mai approfondita, ma non ho dubbi che sia fatta bene. Per quel che ne so, è un peccato che non abbia avuto altrettanto successo l'erede forse più diretto del Pascal standard, il Modula 2 (non vorrei dire castronerie, ma potrebbe essere stato opera di Wirth), che ne correggeva i difetti (tipo il mancato controllo sui bound di un intervallo) e introduceva la programmazione a oggetti. Probabilmente fu colpa del nome poco incisivo, chissa, lo avessero chiamato Perfect Pascal, Pascal Plus o Pascal 2...



Be', forse lo sono un po' anch'io

Perfettamente d'accordo, ed in fondo è proprio li che volevo andare a parare. Il livello di astrazione di cui stiamo parlando sostanzialmente demanda ciò che astrae al livello sottostante (framework/VM) e di conseguenza i linguaggi corrispondenti a tale livello non possono essere usati per sviluppare il software che deve girare ai livelli inferiori, mentre sono ottimi per tutto il resto. In ogni caso, insieme al controllo viene demandata anche la risoluzione di (alcuni di) quei problemi che potrebbero produrre dei bug, per cui potrebbe avere senso fare comunque (magari in circostanze particolari/opportune) un testing a 360 gradi con un occhio di riguardo al comportamento dello strato sottostante, magari per comunicare tempestivamente al team che sviluppa il framework un eventuale bug (esempio banale: l'utilizzo del valore "lenght" associato a ciascun array in un ciclo, insieme a un sistema opportuno di eccezioni per la verifica del rispetto dei confini, dovrebbe scongiurare il pericolo di un buffer overflow/underflow, però un piccolo test, di tanto in tanto, per verificare cosa succede a cavallo del valore limite, credo che male non faccia). Dico questo perchè, a mio modo di vedere, questo demandare il controllo a un livello sottostante da un lato localizza molte problematiche, rendendone probabilmente più facile la risoluzione da parte del team che si dedica allo sviluppo del framework (una volta e per tutte) - e semplificando la vita agli altri sviluppatori - dall'altro un eventuale bug finirebbe per colpire inesorabilmente tutti gli altri, senza possibilità di scampo, quindi ritengo che un minimo di collaborazione in questo senso potrebbe essere auspicabile. IMHO, ovviamente

Piu' che non far male, quel test dovrebbe essere obbligatorio. E i test quando e' possibile vanno scritti prima di scrivere il codice relativo.

OK, grazie.

Per questo preferisco Pascal e derivati al C...

Sono d'accordo (ed è, poi, ciò che ha detto fek...)

.NET?

Infatti è perché non ci sei abituato.

Le poche volte in cui mi cimento ancora con le classi in Delphi (Pascal), scrivo subito assieme costruttore/i e distruttore/i, codice che alloca e libera la memoria, codice che crea istanze di oggetti e che li distrugge, infarcendo il tutto con blocchi try/(except|finally).

E' anche una questione di mentalità, che si acquisce col tempo lavorando con un linguaggio, e imparando a usarlo e sfruttarne le caratteristiche per scrivere codice "migliore".

Come per altri linguaggi, ormai i compilatori Pascal-like sono dotati di framework con una miriade di classi, che permettono di gestire anche liste di oggetti.

Però non è così comodo come con Python, ad esempio, dove liste, "dizionari", tuple e insiemi si possono utilizzare molto velocemente, con poco codice, e soprattutto in maniera molto leggibile e "intuitiva"...

Se l'overloading degli operatori fosse supportato come si deve, non sarebbe certo difficile scrivere qualche modulo e classi per implementare questi utili strumenti in maniera similare, ma attualmente non è così...

Beh, insomma... Il problema principale è che esistono tante, forse troppe estensioni del Pascal in questo senso.
L'estensione a oggetti del Pascal realizzata dall'ISO è molto elegante, come pure quella realizzata da Borland (ne ha fatte due: la prima è rimasta per compatibilità col passato, anche se ha delle interessanti caratteristiche).

Lo è, come lo sono il Modula, il Modula-3 e l'Oberon.

Questo è un controllo che, invece, era "di default" nelle specifiche del Pascal, come pure il controllo degli indici degli array. Purtroppo si tratta di controlli molto pesanti computazionalmente, per cui le implementazioni che sono arrivate fino a noi ne hanno fatto a meno, relegando a direttive di compilazione l'uso o meno di queste caratteristiche.

Se non erro è stata introdotta col Modula-3 (o forse con Oberon): Modula-2 ha introdotto, invece, il concetto di tipo "opaco" (simile al tipo "generic" di Ada). Se ricordo bene, comunque: è passato parecchio tempo da quando ho studiato questi linguaggi...

No, ti posso garantire che Modula-2 ha avuto un discreto successo fra i "pascaliani" e nella comunità scientifica, come pure Oberon. Purtroppo non hanno avuto il successo che meritavano...

Domanda a bruciapelo: chi ha progettato il Pascal della Borland?

Cesare, ti prego.

Hai perfettamente ragione. Infatti non volevo mica fornire la ricetta per evitare i memory leak e i double delete: si cerca soltanto di limitarli con qualche attenzione...

Quindi cosa hai fatto?

Non me lo ricordo di preciso, purtroppo.
Un vago ricordo che affiora in questo momento mi suona come "Anderson", o giù di lì.
Non voglio andare su www.borland.com perché sarebbe sleale...

P.S. Per caso è la stessa persona che adesso lavora lavora per conto di MS, e che ha progettato .NET?
Circolano queste voci: magari ne sai qualcosa di più...