Padding in informatica - memoria, crittografia e database

Quando un programma deve allineare dati in memoria, completare un blocco crittografico o salvare valori a lunghezza fissa, aggiunge spesso byte, bit o spazi che non appartengono al contenuto originale. Questo meccanismo, chiamato padding in informatica, cambia significato a seconda del contesto. Qui lo analizzo con esempi di programmazione, protocolli, crittografia e database, includendo anche gli errori più comuni.

Che cos’è davvero il padding e cosa contiene

Con il termine padding indico l’inserimento di dati aggiuntivi per raggiungere una determinata dimensione o rispettare una regola di disposizione. Questi elementi possono essere byte a zero, spazi, bit o valori definiti da uno standard. Non hanno sempre un significato per l’utente, ma possono essere indispensabili per il sistema che legge il dato.

Un esempio semplice è una struttura composta da un carattere e da un intero. Se il carattere occupa 1 byte e l’intero richiede un indirizzo multiplo di 4, il compilatore può inserire 3 byte di riempimento tra i due campi. La struttura può quindi occupare 8 byte invece dei 5 ottenuti sommando soltanto le dimensioni dei valori.

Questo spazio aggiuntivo non è necessariamente uno spreco. L’allineamento può rendere più efficienti gli accessi alla memoria e, in alcuni ambienti, evita errori di lettura. Il compromesso è evidente quando una struttura viene ripetuta milioni di volte: pochi byte extra per elemento possono trasformarsi in decine o centinaia di megabyte.

Come funziona nella programmazione e nei formati binari

In C, C++ e in altri linguaggi vicini all’hardware, il padding viene spesso inserito automaticamente dal compilatore. La dimensione reale va quindi controllata con strumenti come sizeof, perché l’ordine dei campi, il compilatore, l’architettura e l’ABI possono modificarne il risultato.

struct Record {
    char stato;
    int id;
};

Su molte piattaforme l’intero viene allineato a un indirizzo multiplo di 4. Per questo non conviene dedurre il layout soltanto dal codice sorgente. Io verifico sempre dimensione totale e offset dei campi quando una struttura deve essere salvata su file o condivisa con un altro programma.

Il problema diventa ancora più importante nella serializzazione, cioè nella trasformazione di dati in una sequenza di byte. Un programma Python che usa il modulo struct, per esempio, può lavorare in modalità nativa oppure standard. La prima può inserire padding secondo la macchina in uso, mentre la seconda richiede di definire esplicitamente dimensioni e allineamento.

import struct

struct.calcsize("@ci")  # layout nativo
struct.calcsize("=ci")  # dimensioni standard, senza allineamento nativo

Quando i dati viaggiano tra sistemi diversi, preferisco un formato con endianness, dimensioni e padding dichiarati. Affidarsi al layout nativo può funzionare sul computer dello sviluppatore e rompersi su un dispositivo con architettura diversa. Anche l’uso di direttive come #pragma pack va valutato con cautela: riduce lo spazio, ma può produrre accessi non allineati e problemi di portabilità.

Perché il riempimento compare nei protocolli e nella crittografia

Nei protocolli di rete il padding può servire a raggiungere un allineamento obbligatorio, rispettare la dimensione minima di un campo o rendere meno evidente la lunghezza reale del messaggio. In questo caso i byte aggiunti devono seguire regole precise di codifica e rimozione, altrimenti il destinatario non riesce a interpretare il pacchetto.

La crittografia a blocchi offre l’esempio più noto. Se un algoritmo lavora su blocchi da 16 byte e il testo misura 14 byte, servono 2 byte aggiuntivi. In uno schema come PKCS#7, entrambi possono avere valore 0x02. Se il testo misura già 16 byte, viene comunque aggiunto un intero blocco di padding, così il destinatario sa distinguere un messaggio completo da uno già riempito.

Non tutti gli algoritmi hanno bisogno di questo meccanismo. Le modalità moderne basate su flussi o su AEAD, come quelle usate da molti sistemi autenticati, in genere non richiedono il riempimento a blocchi. Possono però usare padding a livello di protocollo per nascondere la lunghezza del traffico.

La rimozione del padding non è un dettaglio trascurabile. Errori nella verifica o messaggi di errore troppo precisi possono creare vulnerabilità note come padding oracle. Per questo non implementerei mai da solo la parte crittografica in produzione: sceglierei una libreria aggiornata e lascerei a quella la gestione del formato, dell’autenticazione e degli errori.

Cosa cambia nei database tra CHAR e VARCHAR

Nei database il concetto appare soprattutto quando si confrontano colonne a lunghezza fissa e variabile. CHAR(n) è pensato per valori che hanno una dimensione stabile, mentre VARCHAR(n) può contenere valori più brevi senza completarli necessariamente fino a n. La differenza incide su spazio occupato, confronti, indici e comportamento delle applicazioni.

Immaginiamo una colonna CHAR(8) con il valore IT42. Il database può conservarlo come valore completato da spazi, mentre una colonna VARCHAR(8) conserva una rappresentazione variabile. Il comportamento esatto dei confronti e delle funzioni di lunghezza dipende dal prodotto: in SQL Server, per esempio, LEN() non considera gli spazi finali, mentre DATALENGTH() conta i byte memorizzati.

CREATE TABLE codici (
    codice_fisso CHAR(8),
    codice_variabile VARCHAR(8)
);

In SQL Server esiste anche l’impostazione ANSI_PADDING, che influenza il trattamento degli spazi finali e degli zeri nelle colonne di alcuni tipi. La mia scelta pratica è lasciare ANSI_PADDING ON e decidere il tipo di dato in base alla natura del valore, non al desiderio generico di risparmiare spazio.

Come controllare il padding senza introdurre errori

Quando un dato appare più lungo del previsto, non parto dall’ipotesi che il programma abbia aggiunto caratteri casuali. Controllo prima il livello coinvolto, perché il riempimento può essere inserito dal compilatore, dal formato di serializzazione, dal protocollo, dal driver o dal database.

1. Misura la dimensione reale con sizeof, una funzione di calcolo del layout o un dump esadecimale.
2. Controlla gli offset dei campi e l’ordine dei valori nella struttura.
3. Verifica lo standard del formato, compresi endianness, lunghezza e byte di riempimento.
4. Confronta i dati prima e dopo la serializzazione, senza limitarti alla loro rappresentazione testuale.
5. Nel database usa funzioni coerenti per distinguere caratteri, byte e spazi finali.
6. Testa valori al limite, come stringhe vuote, blocchi già completi e strutture con campi opzionali.

Un errore frequente consiste nel rimuovere tutti gli zeri o gli spazi finali appena compaiono. È una scelta pericolosa: quei byte possono essere padding, ma possono anche appartenere a un numero, a una stringa a lunghezza fissa o a una firma digitale. Prima di modificarli bisogna sapere chi li ha aggiunti e quale regola li descrive.

Allo stesso modo, comprimere una struttura con il packing non significa automaticamente migliorarla. Se il dato deve soltanto restare in memoria, l’allineamento naturale è spesso la soluzione più robusta. Se invece deve attraversare una rete o essere scritto su disco, conviene definire un formato esterno esplicito, indipendente dal layout interno del programma.

La regola pratica per distinguere spazio e informazione

Il padding non è un concetto unico, ma una famiglia di tecniche che aggiunge spazio per risolvere un vincolo tecnico. In memoria serve soprattutto all’allineamento, nei protocolli garantisce compatibilità o riservatezza della lunghezza, nella crittografia completa i blocchi e nei database riflette la differenza tra valori fissi e variabili.

La domanda più utile non è soltanto “quanti byte sono stati aggiunti?”, ma “quale componente li interpreta?”. Se la risposta è chiara, diventa molto più semplice scegliere il tipo di dato, diagnosticare un errore di serializzazione e capire quando quel riempimento può essere eliminato senza danneggiare il contenuto.