Devi imparare ad utilizzare diff (esempio di secure code review)

Guarda su YouTube → 15:55 11 febbraio 2026

Descrizione

La utility diff, presente nei sistemi linux, è molto utile per analizzare le differenze tra i file. In questo video mostro una applicazione di diff in un contesto di Secure Code Review (SCR). Se sei interessato alla certificazione OSCP, ho un gruppo studio in cui ogni sabato facciamo lezione per preparaci all'esame: - https://www.patreon.com/hexdump/membership Se sei interessato al mio progetto di formazione informatica: - https://esadecimale.it

Commenti 24

I commenti vengono da YouTube e sono aggiornati periodicamente.

@flaviomili8288 11 febbraio 2026 2

Un tool carino è meld, così puoi leggere i diff e facilmente cambiare i file (più utile durante un merge)
4 risposte
1. @esadecimale Autore 11 febbraio 2026
  
  In emacs ci sta magit per interfacciarsi con git, carino meld
2. @DiTBho 11 febbraio 2026
  
  Ho scritto un tool simile a diff in C. Algoritmo di media complexity.
3. @DiTBho 11 febbraio 2026
  
  Per Windows e Linux c'e' "Beyond Compare", un tool commerciale professionale. Usatissimo in Avionica.
4. @MatteoVeroni 18 febbraio 2026
  
  Oppure un altra GUI oltre a meld e kdiff3
@RossiBianchi-b3s 11 febbraio 2026

Fare compare è il pane quotidiano di noi sviluppatori ma non scherziamo... se non per gioco, nessuno usa diff. Il minimo è avere un comparazione a 3 vie con lo stato corrente, il precedente e l'attuale.
4 risposte
1. @esadecimale Autore 11 febbraio 2026 1
  
  Non capisco il senso della tua osservazione. No. Il minimo non è quello, perché esistono casi di complessità ridotta in cui diff va benissimo. Sono tutti? Chiaramente no, ma questo non significa che un caso semplice diventa un gioco, se inteso con un tono dispregiativo, specialmente in un contesto didattico. E semanticamente parlando il minimo è letteralmente il diff. È il componente atomico. Piccolo esempio: il kernel Linux è sviluppando inviando git-patch via mail. E una git-patch è molto simile ad un diff (hanno scopi diversi, ma stessa sostanza)
2. @RossiBianchi-b3s 11 febbraio 2026
  
  @esadecimale Semplicemente distrae. Avere sotto gli occhi tutti i segni di maggiore/minore, le posizioni delle modifiche, ecc., non aiuta a cogliere il flusso del codice né il senso reale delle modifiche. È qualcosa che può andare bene come metadata per un tool di visualizzazione, ma non per un essere umano. Che sia uno strumento minimo ci sta, ma che sia realmente utilizzabile in ambito professionale direi di no. Poi ognuno è libero di “torturarsi” come preferisce, però quando ti trovi davanti a una commit con centinaia di file modificati inizi inevitabilmente a cercare qualcosa di più completo, che crei meno attrito nell’attività di confronto. Già il visualizzatore integrato nel tool di comparazione delle cartelle è di un livello infinitamente superiore. In ogni caso è solo una mia opinione, e mi dispiace se è stata percepita come offensiva. È semplicemente il commento di una persona che lavora con centinaia di altri sviluppatori, i quali non si sognerebbero mai di usare diff nel loro workflow quotidiano. Che poi possa avere un valore didattico, quello sì, può anche essere.
3. @esadecimale Autore 11 febbraio 2026 2
  
  @RossiBianchi-b3s No ma guarda sull'aspetto di visualizzazione sono d'accordissimo con te. Però il formato base è quello, il diff. Poi sopra ovviamente bisogna avere un bel tool di visualizzazione, quello sì. Il fatto è che il diff rimane il diff, a livello del dato. A livello di visualizzazione ci puoi (e devi, d'accordo con te) fare mille visualizzazioni sopra per renderlo più digeribile ad occhio umano. No problem, solo che non voglio passi l'idea che diff sia un tool banale, perché non lo è. Questa seconda osservazione che hai fatto ha più senso e sono d'accordo anche io su ciò che dici.
4. @DiTBho 12 febbraio 2026
  
  @RossiBianchi-b3s"diff -u" aiuta meglio
@samuelepadoan4993 11 febbraio 2026 1

1:47 ehmm non ho capito, è magia oscura di emacs ? Comunque come al solito interessante.
1 risposta
1. @esadecimale Autore 11 febbraio 2026
  
  Si ahahah, ho utilizzato dired per rinominare velocemente il nome delle cartelle 😂 Sui diff file invece le funzionalità di Emacs si trovano anche in tanti altri tool, che oramai sono un formato storico
@WantOxide 12 febbraio 2026

già perchè è su linux si sa già che sarà merda
11 risposte
1. @esadecimale Autore 12 febbraio 2026
  
  Mi scusi ma lei usa Windows quindi?
2. @Andrea-ff5yq 12 febbraio 2026
  
  Ma se non sai programmare perché devi parlare per forza? Ad oggi molti dev stanno passando a linux anche perché ci sono tool come questi che migliorano la qualità della programmazione
3. @DiTBho 12 febbraio 2026
  
  @Andrea-ff5yqoddio "ni". Microsoft e Metrowork hanno collaborato sviluppando sistemi di sviluppo che per molti aspetti sono meglio di qualsiasi ambiente/tool GNU/BSD/OpenSource mai scritto. Sono sistemi di sviluppo commerciali, pensati per sistemi embedded come "Sony Playstation", "Nintendo N64" (con collaborazione SGI, sviluppo tools per workstation SGI/Indy sotto irix 5, ma anche IDP Windows!), "Nintendo GB e GBA", ... e la stessa linea Microsoft Xbox. In pratica se hai un IDP "all in one" che soddisfa l'intero "ecosistema" di sviluppo (e quindi non senti Mai la necessita' di uscire dall IDP per cercare/usare un tool esterni) allora il sistema operativo diventa trasversale, e non fa differenza alcuna usare Windows, MacOS, Linux, freeBSD, Irix, AIX, ... si e' visto proprio con Nintendo N64 che aveva IDP multi piattaforma. Chiaro, poi c'e' il discorso economico, e qui ... bisogna capire qual'e' il miglior rapporto produttivita'/Costo (e licenze)
4. @DiTBho 12 febbraio 2026
  
  @esadecimaleuso Window XP per due IDP: 1) AnalogDevices per dsp TigerShark e Blackfin bf5xx, per GNU/Linux non c'e' supporto per gli ICE di fascia alta, e il compilatore integrato nell IDP ha otimizzazione migliore di gcc 2) Cygnus per Motorola cpu32, 683xx usati in automotive Ford Racing (legacy), per lo stesso motivo.
5. @DiTBho 12 febbraio 2026
  
  Per tutto il resto Gentoo GNU/Linux
6. @guidodiscacciati 13 febbraio 2026
  
  Già che commenta in modo dispregiativo senza dare una qualsivoglia argomentazione alla propria tesi si sà già che è un frustrato che ha bisogno di sentirsi grande... Hai ragione tu tranquillo neh 👌😂
7. @guidodiscacciati 13 febbraio 2026
  
  @DiTBhoè un contesto specifico che richiede per forza di cose di usare quell'ambiente, ci sta. Dubito che però usi ancora XP su un computer di uso normale quotidiano a casa, sarebbe anche decisamente un azzardo a livello di sicurezza, posso tranquillamente credere che usi Windows o Mac invece di Linux per carità. Io mi trovo benissimo con Linux ma è soggettivo
8. @DiTBho 13 febbraio 2026 1
  
  @guidodiscacciatiXp su VM, oppure Xp su laptop dedicato, su subnet chiusa. In Avionica lo facciamo.
9. @DiTBho 13 febbraio 2026
  
  @guidodiscacciatiperche' xp? Perche' quel sw non gira sulle versioni successive. Ci sono problemi con i drv. Oltre alle licenze, che sono legate.
10. @DiTBho 13 febbraio 2026
  
  Cmq il Punto e': non e' Windows non sia usato per sviluppo. Dipende dal sw di sviluppo. E alcuni per Windows (se sono "IDP all in on" && "full ecosystem support") sono molto validi e produttivi, tanto che non ti interessa minimamente su che OS girano. Anche lato interfaccia, tipicamente sono combo CLI & GUI. Un esempio e' Xilinx Vivado, o Windriver VxWorks Studio.
11. @guidodiscacciati 13 febbraio 2026
  
  @DiTBhoonestissimo direi, ( tra l'altro scemo io che non avevo pensato alla VM effettivamente) comunque come dicevo appunto il tuo è un caso molto specifico che per compatibilità e licenze del sw che devi utilizzare ti porta a usare quello specifico so, pure a me è capitato di creare vm per portare a termine specifici progetti che non potevo concludere rimanendo su Linux (la VM usata semplicemente per compilare dato che il programma serviva a qualcuno che lo avrebbe usato su Windows e la cosa più comoda e veloce era compilarlo direttamente da lì per fare un esempio)