Uno degli aspetti importanti, cui bisogna prestare attenzione lavorando con differenti tipi di processori, è rappresentato dal tipo di endian adottato da quel particolare processore. L’endian di un processore specifica la modalità in cui vengono memorizzati e gestiti i singoli byte, nel caso di dati di tipo multibyte; essa può essere di due tipi:

• big-endian: il byte più significativo viene memorizzato prima;
• little-endian: il byte meno significativo viene memorizzato prima.

Ad esempio, il valore 54321 (ossia, 0xD431 in esadecimale) verrebbe memorizzato come D4-31 nel caso big-endian e come 31-D4 nel caso little-endian. Appare pertanto evidente come la gestione dell’endian sia cruciale da un duplice punto di vista: da un lato, per garantire la portabilità del proprio codice da un tipo di processore a un altro; dall’altro per evitare che dati multibyte salvati come big-endian vengano poi riletti come little endian (e viceversa), portando a errori nei valori dei dati.

Un recente articolo scritto da Carl Ek, software architect presso Code Integrity Solutions, presenta una dettagliata analisi dei problemi che possono emergere in seguito a un’errata (o semplicemente superficiale) gestione dell’endian, prendendo come riferimento il linguaggio C, date le ampie possibilità che offre per lavorare a livello di bit e byte.

L’autore offre dapprima un insieme di best practices da seguire, tutte derivate fondamentalmente da un’unica regola generale: evitare per quanto possibile di processare i byte basandosi su ipotesi sull’ordine in cui questi verranno memorizzati. Nel caso in cui un approccio del genere non fosse possibile, allora il programma deve gestire opportunamente entrambi i tipi di endian — secondo la cosiddetta strategia di Endian Protocol — utilizzando fondamentalmente uno dei vari metodi di swap dei dati.

Oltre alle best practices indicate dall’autore, è possibile definire vari altri tipi di regole (ad esempio quelle del MISRA (Motor Industry Software Reliability Association)), ma soprattutto utilizzare strumenti di analisi statica del codice, in particolare quelli per i quali è possibile personalizzare i criteri di analisi. L’uso congiunto di queste regole permette di adottare criteri semplici per risolvere errori di programmazione e di ottenere pertanto un codice di elevato livello qualitativo sin dagli inizi del suo sviluppo.