Nei titoli e nei testi troverete qualche rimando cinematografico (eh si, sono un cinefilo). Se non vi interessano fate finta di non vederli, già che non sono fondamentali per la comprensione dei post...

Di questo blog mando avanti anche una versione in Spagnolo (e, normalmente, i post sono disponibili un po' in ritardo rispetto alla versione in Italiano...). Potete trovarlo su El arte de la programación en C. Buona lettura.

mercoledì 13 marzo 2019

1997: Fuga da Bitwise
Come funzionano le operazioni di Bitwise in C

(...una premessa: questo post è un remake di un mio vecchio post (anzi, di due). L'ho riadattato e "modernizzato" per pubblicarlo su quell'altro bel blog collettivo dove scrivo. Visto che le modifiche sono molte e (forse) interessanti, lo ripubblico anche qui. Questo potrebbe ripetersi in futuro...)
Bob Hauk: Mi ucciderai ora, Jena?
Jena (Snake) Plissken: Sono troppo stanco... Forse più tardi...
Nel capolavoro 1997: Fuga da New York il grande John Carpenter ci mostrava come scappare da una tristissima New York trasformata in prigione federale. Ecco, l’argomento di questo articolo è uno di quegli argomenti che inducono alla fuga molti valorosi Programmatori C/C++… “ehm… oggi non ho tempo, puoi occupartene tu delle operazioni di bitwise? Poi domani mi farai vedere…
...a me Bitwise non me l'ha mai detto nessuno...
Cominciamo con un piccolo gioco: alzi la mano chi ha scritto recentemente codice che usa le operazioni bit a bit. Oppure, alzi la mano, senza prima andare a rileggersi un manuale del C/C++, chi di voi sa usare e/o descrivere perfettamente le operazioni bit a bit. Uhm… vedo poche mani alzate. Il fatto è che le bitwise operations sono una di quelle parti del C/C++ un po’ misconosciute, di uso dubbio e infrequente, insomma una di quelle parti di cui, per mancanza di pratica ci si scorda.

E, oltretutto, devo dire che sulle operazioni di bitwise il fantastico K&R non è particolarmente chiaro e dettagliato, le tratta (come sono) come un argomento di nicchia, e non ti coinvolge con decine di divertenti esempi che ti aiutano a memorizzare definitivamente l’argomento, anzi, per quel che ricordo dell’ultima volta che lo lessi, sono un paio di pagine che scivolano via e che hai già dimenticato quando passi al prossimo capitolo. Beh anche la bibbia K&R (che io considero sacra) ha alcuni punti non proprio coinvolgenti.

Rinfreschiamo: gli operatori di bitwise (che operano sui singoli bit) sono:
"&"  AND
"|"  OR
"^"  XOR
"~"  NOT (complemento a 1)
"<<" SHIFT a sinistra
">>" SHIFT a destra  
     
N.B.:
- il NOT e' un operatore unario: opera su un solo argomento indicato sulla destra.
- gli shift sono operatori unari: operano su un solo argomento indicato sulla sinistra.
Adesso, senza dilungarci in noiosi sproloqui, passiamo a una piccola tabella e ad alcuni semplici esempi pratici. Ecco la tabella:
"&": il risultato è 1 se i due operandi valgono 1. Altrimenti 0.
"|": il risultato è 0 se i due operandi valgono 0. Altrimenti 1.
"^": il risultato è 1 se i due operandi sono diversi. Altrimenti 0.
"~": il risultato è 1 se l'operando vale 0. Altrimenti 0. 
"<< n": il risultato è l'operando con tutti i bit spostati a sinistra di n posizioni. 
">> n": il risultato è l'operando con tutti i bit spostati a destra di n posizioni.
Ed ecco i semplici esempi pratici:
AND
int a = 74;       // 0 1 0 0 1 0 1 0
int b = 174;      // 1 0 1 0 1 1 1 0
int c = a & b;    // 0 0 0 0 1 0 1 0 risultato c=10

OR
int a = 74;       // 0 1 0 0 1 0 1 0
int b = 174;      // 1 0 1 0 1 1 1 0
int c = a | b;    // 1 1 1 0 1 1 1 0 risultato c=238

XOR
int a = 74;       // 0 1 0 0 1 0 1 0
int b = 174;      // 1 0 1 0 1 1 1 0
int c = a & b;    // 1 1 1 0 0 1 0 0 risultato c=228

NOT
int a = 74;       // 0 1 0 0 1 0 1 0
int b = ~b;       // 1 0 1 1 0 1 0 1 risultato c=181

SHIFT a sinistra
int a = 74;       // 0 1 0 0 1 0 1 0
int b = a << 2;   // 0 0 1 0 1 0 0 0 risultato c=296

SHIFT a destra
int a = 74;       // 0 1 0 0 1 0 1 0
int b = a >> 2;   // 0 0 0 1 0 0 1 0 risultato c=18
Notare che nelle operazioni di shift i bit nuovi che entrano a destra (nello shift a sinistra) valgono 0, e i bit nuovi che entrano a sinistra (nello shift a destra) valgono 0.
Notare anche che lo shift a destra equivale a una divisione per multipli di 2 (>>1  è una divisione per 2,  >>2  è una divisione per 4, ecc.), mentre lo shift a sinistra equivale a una moltiplicazione per multipli di 2 (<<1  è una moltiplicazione per 2, <<2  è una moltiplicazione per 4, ecc.). Queste operazioni di moltiplicazione e divisione sono molto veloci, e si potrebbe essere tentati a usarle per velocizzare il codice: beh, prima di farlo rileggetevi (o leggetevi) questo.

E aggiungo un avvertimento: in base alla dimensione del tipo del operando e alla presenza o meno del bit di segno, le moltiplicazioni e divisioni con shift possono dare risultati inaspettati. Anzi, andiamoci subito alle dolenti note,  togliamoci il pensiero: vediamo un esempio:
#include <stdio.h>

void main()
{
    // 1) SHIFT a sinistra con unsigned int
    unsigned int a, b;
    a = 74;           // 0 0 1 0 0 1 0 1 0
    b = a << 2;       // 1 0 0 1 0 1 0 0 0 risultato b=296
    printf("var = %d; var << 2 = %d\n", a, b);

    // 2) SHIFT a sinistra con unsigned char
    unsigned char c, d;
    c = 74;           // 0 1 0 0 1 0 1 0
    d = c << 2;       // 0 0 1 0 1 0 0 0 risultato d=40
    printf("var = %d; var << 2 = %d\n", c, d);

    // 3) SHIFT a destra con signed char (o int)
    char e, f;
    e = -4;           // 1 1 1 1 1 1 0 0
    f = e >> 2;       // 1 1 1 1 1 1 1 1 risultato f=-1
    printf("var = %d: var >> 2 = %d\n", e, f);
    // N.B.: senza estensione di segno sarebbe:
    // e = -4;        // 1 1 1 1 1 1 0 0
    // f = e >> 2;    // 0 0 1 1 1 1 1 1 risultato f=63
}
Il caso 1 è, evidentemente il caso funzionante: un int è molto più grande degli 8 bit usati per rappresentare il numero di partenza (74), per cui lo shift non perde nessun 1 sulla sinistra (è questo il possibile problema) e il risultato è corretto (74×4=296). Se usiamo però (caso 2) un char (8 bit) durante lo shift perdiamo un 1 e il risultato va in overflow (74×4=40 ??). Quindi attenzione!

Il caso 3, poi, è ancora più subdolo: facendo operazioni con segno (nei casi 1 e 2 ho usato variabili unsigned proprio in preparazione al punto 3) e usando valori negativi, possono succedere cose strane: per la rappresentazione stessa dei numeri negativi in binario (complemento a 2) il bit più a sinistra (MSB) è il bit di segno, e, in questo caso l’operazione di shift è machine-dependent: in base al tipo di CPU possiamo disporre o no dell’estensione di segno (di default, ad esempio, su macchine Intel), per cui lo shift dell’esempio può dare il risultato aspettato (-4/4=-1) o un risultato completamente diverso (-4/4=63 ??). Di nuovo: attenzione!

E adesso è il momento di mostrare alcuni esempi pratici di uso di quanto esposto, che altrimenti, sarebbe know-how  fine a se stesso: vediamo come leggere lo stato dei singoli bit di una word usando una maschera:
#include <stdio.h>

void main()
{
    // uso di una maschera per leggere i bit di una word
    unsigned char mask = 1;     // 0 0 0 0 0 0 0 1
    unsigned char word = 74;    // 0 1 0 0 1 0 1 0

    // loop di lettura
    int i;
    for (i = 0; i < 8; i++)
        printf("il bit %d della word è %s\n", i, (word & mask<<i) ? "ON" : "OFF");
}
semplice no? E la stessa operazione si può fare con una macro:
#include <stdio.h>

#define INPUT(w, i)    (w & 0x01<<i)

void main()
{
    // uso di una macro per leggere i bit di una word
    unsigned char i_word = 74;    // 0 1 0 0 1 0 1 0

    // loop di lettura
    int i;
    for (i = 0; i < 8; i++)
        printf("il bit %d della word è %s\n", i, INPUT(i_word, i) ? "ON" : "OFF");
}
E poi, visto che lo stile è sempre molto importante, vediamo un modo con una una buona estetica per leggere degli input di un dispositivo, per esempio i fine corsa di un sistema elettromeccanico che dobbiamo controllare col nostro amato C:
#include <stdio.h>

#define INPUT_FC1    (in_word & 0x01<<0)
#define INPUT_FC2    (in_word & 0x01<<1)

void main()
{
    // uso di una define per ogni bit da leggere di una word
    unsigned char in_word = 74;    // 0 1 0 0 1 0 1 0

    // lettura
    printf("il bit FC1 della word è %s\n", INPUT_FC1 ? "ON" : "OFF");
    printf("il bit FC2 della word è %s\n", INPUT_FC2 ? "ON" : "OFF");
}
Ecco, l’esempio appena mostrato indica una maniera, semplice ed elegante, per descrivere degli input (usando dei mnemonici auto-esplicativi) che può risultare utile per scrivere del Software di controllo di dispositivi Hardware, facile da leggere e da manutenere.

Facile da leggere e da manutenere: questa l’ho già sentita… ah si: è come dovrebbe essere tutto il S/W che scrive un Analista Programmatore (…ma questa è un’altra storia…).

Ciao e al prossimo post!

domenica 17 febbraio 2019

Variabili Globali? No, grazie!
come NON usare le variabili globali nel C

(...una premessa: questo post è un remake di un mio vecchio post. L'ho riadattato e "modernizzato" per pubblicarlo su quell'altro bel blog collettivo dove scrivo. Visto che le modifiche sono molte e (forse) interessanti, lo ripubblico anche qui. Questo potrebbe ripetersi in futuro...)
"L'unica sua dote era una specie di futile entusiasmo. In pratica sembrava che usasse l'archetto come una sega, straziando le corde al punto da condurre l'ascoltatore verso pericolosi stati di follia. Non aveva cognizione della natura dello strumento: provava a soffiarci dentro." (Mr. A.Torgman) [maestro di violoncello di Virgil Starkwell, intervistato].
In Prendi i soldi e scappa il maestro di violoncello di Virgil Starkwell ci descriveva come si sentivano gli sfortunati ascoltatori di Virgil (Woody Allen) durante le sue esibizioni. Ecco, io ho esattamente le stesse sensazioni quando leggo del codice che usa uno dei capisaldi della non-programmazione: le variabili globali. Intendiamoci: le variabili globali (come anche il goto, per esempio) fanno parte del linguaggio, quindi esistono: a volte è possibile e/o necessario usarle. Però, esattamente come il goto, è quasi sempre possibile farne a meno, con grandi benefici di stile (leggibilità e manutenibilità, soprattutto), e funzionalità (meno bugs): chiamalo poco.
...la variabile globale: lo strumento sbagliato nel posto sbagliato...
I punti critici sono moltissimi, ma, visto che non voglio scrivere né un poema, né un libro sull’argomento, ne ho isolati alcuni. Vediamo:

1) le variabili globali non sono thread-safe

Nella programmazione multithreading l'uso delle globali può generare problemi di malfunzionamento subdoli e difficili da trovare. Il caso classico sono le istruzioni di lettura/scrittura di una globale fuori da una zona critica, ossia (per esempio) senza la protezione di un mutex: in un grande progetto è sufficiente una (una sola!) dimenticanza, di questo tipo per creare tanti di quei mal di testa che ti passerà la voglia di usare le globali per il resto della tua vita di programmatore. Provare per credere. A questo punto uno potrebbe obbiettare: "ma io scrivo programmi normali, non multithreading". Va bene: premettendo (e chiarendo nel prossimo paragrafo) che un programma "normale" può essere considerato un programma multi-thread con un solo thread, ringrazio per l'obiezione, che mi serve giusto di spunto per illustrare il punto 2:

2) le variabili globali violano il principio di manutenzione/riutilizzazione del Software

Quando si scrive del codice professionalmente bisogna sempre pensare al lavoro in team, e quindi alle operazioni di manutenzione che potrebbero essere svolte da altri (e, a volte) dopo molto tempo: evidentemente un codice, vasto e pieno di globali, è difficile da manutenere come un codice No Comment (ricordate ?), perché la storia di una globale è poco comprensibile, potrebbe essere toccata in molti posti diversi da molte funzioni diverse, e, se per capire un pezzetto di codice bisogna aprire alcune decine di file... avete vinto un altro bel mal di testa! E non ne parliamo di riutilizzare del codice pieno di globali per un altro progetto: se non l'avete mai fatto provate almeno a immaginarvi la difficoltà. E non solo: torniamo al punto 1 (thread-safe): chi mi dice che del codice "normale" non lo debba riutilizzare (un giorno) in un progetto multithread ? Se il codice è thread-safe si può fare agevolmente, ma se ci sono delle globali di mezzo... beh, buon lavoro (e buona fortuna).

3) le variabili globali aumentano la difficoltà del debug e moltiplicano la probabilità di errori di programmazione

Per quanto riguarda il debug vi rimando al punto 2: se il valore di una variabile è difficile da seguire a livello di manutenzione lo sarà anche a livello di debug. E ci saranno anche più malfunzionamenti da debuggare (fantastico!), perché, oltre a tutti i possibili errori di codificazione ci aggiungiamo anche quelli di scope: provate questo codice:
int my_var = 0;   // globale!

// funzione che incrementa la globale
void incrementaMyVar()
{
    my_var += 5;
}

// funzione main
int main(int argc, char **argv)
{
    // faccio mille cose...
    // ...

    // incremento my_var
    incrementaMyVar();

    // faccio altre mille cose...
    // ...

    // definisco una "nuova" variabile my var e la uso
    int my_var = 2;     // ah, ah, ah: ridefinizione!
    // ...

    // faccio ancora mille cose...
    // ...

    // incremento e test my_var (oops! quale my_var?)
    incrementaMyVar();
    if (my_var == 2)
        formatMyHardDisk(); // uh, uh, uh: era quella sbagliata!
    // ...

    return 0;
}
Quello mostrato sopra era un problema di scope con ridefinizione locale (accidentale) di una globale. Il codice che segue è ancora più semplice, mostra una svista su un dettaglio importante:
int my_var = 0;    // globale!

// funzione lunghissima che fa un sacco di cose
void faccioMilleCose()
{
    // faccio mille cose...
    // ...

    // incremento my_var (sepolto tra mille istruzioni!)
    my_var += 5;

    // faccio altre mille cose...
    // ...
}

// funzione main
int main(int argc, char **argv)
{
    // faccio un po' di cose...
    // ...

    // chiamo faccioMilleCose()
    faccioMilleCose();  // oops! ho incrementato my_var senza accorgermene

    // faccio altre cose...
    // ...

    // test my_var
    if (my_var == 5)
        formatMyHardDisk(); // uh, uh, uh: ho sbagliato qualcosa?
    // ...

    return 0;
}
Bella storia, eh ?

4) le variabili globali violano il principio di incapsulamento delle variabili

Beh, questo non c’è nemmeno bisogno di spiegarlo, una globale è tutto meno che incapsulata… oops, ma questo è OOP, quindi esula un po’ l’argomento del post… ah, no: questo articolo vale sia per C che per C++ (ed anche altri linguaggi, direi…). Beh, visto che siamo in argomento OOP, e quindi C++, cito volentieri il grande M.Cline che nelle su C++FAQ dice (traduco, eh):
I nomi delle variabili globali dovrebbero iniziare con //. 
Ecco il modo ideale per dichiarare una variabile globale:  

// int xyz; <-la cosa che rende ideale questa globale è l'iniziale // 

Ecco il modo ideale per utilizzare una variabile globale:

void mycode() 
{ 
    ... 
    // fai_qualcosa_con(xyz); <-idem come sopra 
    ... 
} 

Ok, questo è un gioco. Una specie. La verità è che ci sono casi in cui le 
variabili globali sono meno peggio delle alternative - quando le globali 
sono il minore dei mali. Ma loro sono sempre malvagie. Quindi lavatevi le 
mani dopo averle usate. Due volte.
(Marshall Cline C++FAQ sezione 27.15)

Sante parole.

E, per restare in tema C++, aggiungo un piccolo appunto: una Duna, anche se ci attacchi un logo Ferrari resta, ahimè, una Duna (e non me ne vogliano i lettori che usano la Duna, eh!). Allo stesso modo se, per darti delle arie, chiami Singleton una Variabile Globale Sofisticata il risultato non cambia, puoi sofisticarla quanto vuoi (inizializzazione “lazy”, inizializzazione “eager”, inizializzazione “oggi-sono-indeciso-e-faccio-un-mix-di-lazy-e-eager”, ecc., ecc.) ma, sotto sotto, è sempre una schifezza di Variabile Globale (anche se un pelino più accettabile, devo ammetterlo).

(…e qua bisogna giocare d’anticipo:  so che la affermazione qui sopra avrà fatto saltare sulla sedia tutti gli adepti della religione di Design Patterns, si, quelli che la sera recitano le orazioni davanti alla foto della Gang of Four che tengono sul comodino. Ecco, ho il massimo rispetto per loro, per la Gang of Four e per il libro che ha, sicuramente, un grande valore tecnico (e chi sono io per negarlo?) ma non è da prendere tutto come oro colato…  E vi assicuro che molta gente ha scritto del buon Software anche prima dell’uscita di quel libro (ma come avranno fatto?). Ecco, quel libro è l’equivalente informatico de La corazzata Potëmkin del Cinema, bello fin che vuoi (è un capolavoro) ma ti induce facilmente valutazioni come quella che fece Fantozzi. Anzi, posso affermare che, ultimamente, considero che il vero grande valore aggiunto che ci fornisce il libro Design Patterns è quello dissuasivo: supponiamo che avete (o avrete) un/a figlio/a che vuole dedicarsi all’Informatica, ma voi pensate che studiando Giurisprudenza o Economia possa avere un futuro più luminoso. Ecco, fategli trovare (casualmente) una copia di Design Patterns sul letto dicendo “…Ho ritrovato in cantina questo mio vecchio libro… dagli una occhiata, perché presto sarà il tuo pane quotidiano”. È probabile che la mattina successiva, verso le 6 (meglio non aspettare) verrete svegliati da vostro figlio/a chiedendovi “Come hai detto che ci si iscrive a Giurisprudenza?”…) 

CONCLUSIONE

Che possiamo dire in conclusione? Sicuramente che, se pensate che tutto quanto detto qui sopra sia solo farina del mio sacco, potete provate a interrogare il nostro amico Google, chiedendo, ad esempio: “global variables are evil?“, e vedrete che valanga di risultati vi verrà fuori. Se vi può interessare una delle pagine più ben fatte la trovate qui.
 
A questo punto penso che quanto detto sia sufficiente. Evidentemente io sono un po’ prevenuto perché ho lavorato a lungo su software multithreading (e ho ancora un po’ di mal di testa…), però vi chiedo di fidarvi e di propagare il messaggio il più possibile. Si, lo so, dire a un programmatore inesperto (o a un programmatore stanco) “non usare le variabili globali!” è come dire a un bambino “non mangiare troppe caramelle!“: beh, anche se a malincuore, bisogna farlo: la salute prima di tutto.

Ciao e al prossimo post!

domenica 20 gennaio 2019

Io e l'Integer Packing
come funziona il pack e unpack di interi in C

Annie: Oh, vai dallo psichiatra?
Alvy: S-sì. Da quindici anni soli...
Annie: Quindici anni?!
Alvy: Sì... gli concedo un altro anno... poi vado a Lourdes.
Nel capolavoro Io e Annie il Maestro Woody Allen ci proponeva, attraverso una personalissima "commedia romantica nevrotica", l'analisi della relazione tra i protagonisti Alvy Singer e Annie Hall in tutte le sue fasi (l'inizio/la relazione/la fine), mettendo in mostra fatti e misfatti in cui tutti ci possiamo riconoscere. Allo stesso modo (ma non con la classe del Maestro, purtroppo) cercherò con questo articolo di ricreare e (spero) risolvere una situazione che tutti i programmatori che si sporcano le mani con la programmazione low-level hanno dovuto affrontare (...ebbene si, cari programmatori high-level: sotto le vostre splendide applicazioni gira sempre del Software low-level, quasi sempre scritto in C, non dimenticatevelo...).
...Alvy: il pack/unpack di interi... Annie: argomento interessantissimo (yawn)...
Supponiamo (ma proprio supponiamo) che abbiamo due interi da 16 bit che vogliamo, magicamente, trasformare in un unico intero da 32 bit. Oppure vogliamo fare l'operazione inversa (spezzare un int a 32 bit in due int a 16 bit). Oppure abbiamo quattro interi da 16 bit e vogliamo... blah, blah, bla. I casi appena descritti non sono fantascienza, anzi sono casi abbastanza normali: ad esempio chi maneggia giornalmente i registri di periferiche Modbus sicuramente si è trovato a dover fare operazioni di questo tipo. Ecco, chi usa queste operazioni frequentemente può anche saltare il resto dell'articolo (e magari usare il tempo risparmiato per guardarsi un buon film e alimentare così la propria mente).

Ma, visto che mi è capitato di vedere facce terrorizzate di fronte a problemoni come questo (specialmente tra i colleghi non avvezzi alla programmazione low-level), cercherò di proporre alcune soluzioni, dopodiché si noterà che il tutto è di una semplicità disarmante. Si può, ovviamente, risolvere in 33 (o 33000) modi diversi, io ho pensato di mostrare i 3 modi che mi sembrano più semplici, lineari ed efficienti. Gli esempi che seguono sono di pack e unpack di interi a 32 bit (2 registri da 16bit in un intero da 32 bit e viceversa), ma adattare gli esempi ai 64 bit (4 registri da 16bit in un intero da 64 bit e viceversa) è veramente un gioco da ragazzi, e quindi non ve lo mostro nemmeno. Vai col codice dell'esempio 1!:

1) pack32 e unpack32 con bitwise

// pack32bitwise - copia un array di 2 uint16_t dentro una variabile uint32_t
uint32_t pack32bitwise(
    const uint16_t *src)    // array sorgente per il pack
{
    // ottiene il valore destinazione dal valore sorgente
    return ((uint32_t)src[1]) << 16 | src[0];
}

// unpack32bitwise - copia una variabile uint32_t in un array di 2 uint16_t
uint16_t *unpack32bitwise(
    uint16_t       *dest,   // array destinazione
    const uint32_t src)     // valore sorgente per l'unpack
{
    // ottiene il valore destinazione dal valore sorgente
    dest[1] = (uint16_t)((src & 0xFFFF0000) >> 16);
    dest[0] = (uint16_t)( src & 0x0000FFFF);

    return dest;
}
Questo è il modo più semplice e (probabilmente) più efficiente per fare il pack/unpack (io di solito uso questo). Si effettuano delle semplici operazioni di bitwise, che spostano o copiano i valori di entrata sull'uscita. Ovviamente la funzione pack() si aspetta un array come argomento e restituisce il valore intero corrispondente. Specularmente la funzione unpack() si aspetta un argomento con un valore e un argomento destinazione che sarà un array. Le operazioni di bitwise sono semplicissime: usando lo shift a 16 (visto che usiamo interi a 16 bit) possiamo copiare/spostare/mascherare opportunamente per ottenere il risultato voluto. Ed ora siamo pronti per l'esempio 2. vai col codice!:

2) pack e unpack con union

// pack32union - copia un array di 2 uint16_t dentro una variabile uint32_t
uint32_t pack32union(
    const uint16_t *src)    // array sorgente per il pack
{
    union {
        uint16_t src[2];
        uint32_t dest;
    } u;

    // ottiene il valore destinazione dal valore sorgente
    u.src[0] = src[0];
    u.src[1] = src[1];

    return u.dest;
}

// unpack32union - copia una variabile uint32_t in un array di 2 uint16_t
uint16_t *unpack32union(
    uint16_t       *dest,   // array destinazione
    const uint32_t src)     // valore sorgente per l'unpack
{
    union {
        uint16_t dest[2];
        uint32_t src;
    } u;

    // ottiene il valore destinazione dal valore sorgente
    u.src = src;
    dest[0] = u.dest[0];
    dest[1] = u.dest[1];

    return dest;
}
Questa maniera per eseguire il pack/unpack è quasi un trucco: si sfrutta una particolarità del linguaggio (il funzionamento delle union) in maniera impropria (non è che le union servono esattamente a quello)... ma visto che funziona perché non farlo? Quindi basta creare una union della forma opportuna e, assegnato a un membro della union il valore in ingresso, troveremo nell'altro membro della union il valore "rimappato" di uscita, esattamente quello che ci serve, no? Per chi in questo momento ha un vuoto di memoria su come funzionano le union basta ricordarsi di questo: la dimensione di una union è quella di un membro solo (quello che occupa più memoria) e, nel nostro caso, visto che i due membri occupano lo stesso spazio ma sono di tipo diverso ci viene offerto un immediato recasting implicito. Semplicissimo! Ed ora passiamo all'ultimo esempio. vai col codice!:

3) pack e unpack con memcpy()

// pack32memcpy - copia un array di 2 uint16_t dentro una variabile uint32_t
uint32_t pack32memcpy(
    const uint16_t *src)    // array sorgente per il pack
{
    // copia il valore sorgente nella destinazione
    uint32_t dest;
    memcpy(&dest, src, sizeof(dest));

    return dest;
}

// unpack32memcpy - copia una variabile uint32_t in un array di 2 uint16_t
uint16_t *unpack32memcpy(
    uint16_t       *dest,   // array destinazione
    const uint32_t src)     // valore sorgente per l'unpack
{
    // copia il valore sorgente nella destinazione
    uint32_t mysrc = src;
    memcpy(dest, &mysrc, sizeof(mysrc));

    return dest;
}
Visto che le operazioni di pack/unpack sono, bene o male, operazioni di copia/spostamento di memoria, non poteva mancare un esempio con la memcpy(), che è l'oggetto privilegiato e preferito quando si parla di operazioni di questo tipo. Mi risulta che questo metodo è molto usato, e l'ho usato anch'io ma, ultimamente, uso più spesso il metodo 1 (anche perché col metodo 1 è facilissimo, nel caso risulti necessario, invertire l'ordine dei registri. Non è usuale ma a volte capita). Il codice è così semplice che non c'è quasi nulla da spiegare: sfruttando il fatto che la memcpy() usa argomenti di tipo void* è perfettamente usabile per una operazione come la nostra, che consiste, a tutti gli effetti, nella copia di un blocco di memoria di un tipo in uno di un tipo diverso. A questo punto cosa ci manca? ma un bell'esempio d'uso, chiaro! Eccolo:
#include <stdio.h>
#include <stdint.h>
#include <string.h>

// prototipi locali
uint32_t pack32bitwise(const uint16_t *src);
uint16_t *unpack32bitwise(uint16_t *dest, const uint32_t src);
uint32_t pack32union(const uint16_t *src);
uint16_t *unpack32union(uint16_t *dest, const uint32_t src);
uint32_t pack32memcpy(const uint16_t *src);
uint16_t *unpack32memcpy(uint16_t *dest, const uint32_t src);

// funzione main
int main(int argc, char *argv[])
{
    // set variabili per test pack32()
    uint16_t src1[2];
    uint32_t dest1;
    src1[0] = 10;
    src1[1] = 20;

    // test pack32()
    dest1 = pack32bitwise(src1);;
    printf("con bitwise: src1={%d,%d} dest1=%d\n", src1[0], src1[1], dest1);
    dest1 = pack32union(src1);;
    printf("con union:   src1={%d,%d} dest1=%d\n", src1[0], src1[1], dest1);
    dest1 = pack32memcpy(src1);;
    printf("con memcpy:  src1={%d,%d} dest1=%d\n", src1[0], src1[1], dest1);

    // set variabili per test unpack32()
    uint32_t src2 = 1310730;
    uint16_t dest2[2];

    // test unpack32()
    unpack32bitwise(dest2, src2);
    printf("con bitwise; src=%d dest={%d,%d}\n", src2, dest2[0], dest2[1]);
    unpack32union(dest2, src2);
    printf("con union:   src=%d dest={%d,%d}\n", src2, dest2[0], dest2[1]);
    unpack32memcpy(dest2, src2);
    printf("con memcpy:  src=%d dest={%d,%d}\n", src2, dest2[0], dest2[1]);

    return 0;
}
Ecco, con questo piccolo main() di esempio potrete verificare che le varie versioni di pack e unpack offrono sempre gli stessi risultati (e ci mancherebbe solo che non fosse così!). E con questo ho detto tutto, e vi lascio, come compiti delle vacanze (vacanze? quali vacanze?) la trasformazione di tutti gli esempi a 32 bit in esempi a 64 bit: come ho già detto più sopra, è un gioco da ragazzi!

Ciao e al prossimo post!

domenica 16 dicembre 2018

I Misteri delle Funzioni del C
come funzionano alcune funzioni speciali in C - pt.2

Sig.ra Talmann: Il tuo discorso, Louis, sta diventando meteorologico.
È giunto il momento di tornare su I misteri del giardino di Compton House, anzi meglio, sulla seconda parte de I Misteri delle Funzioni del C (...e una ripassatina alla prima parte non ci starebbe male, prima di proseguire...). E giuro che cercherò di non cadere in discorsi meteorologici e incomprensibili come Louis Talmann.

...misteri? Quali misteri?...
(...una doverosa premessa: sicuramente per qualcuno, o per molti, i misteri trattati nella prima parte e, probabilmente, anche questi della seconda non sono affatto misteri. Ma voglio ribadire quanto già detto nella prima parte: girando su vari siti di programmazione (tipo l'ottimo stackoverflow, per intenderci), si nota che anche programmatori "scafati" hanno, a volte, dubbi su concetti di base (e chi non ne ha mai avuti scagli la prima pietra!) e poi, più in generale, la lettura di "un altra campana tecnica" può risultare sempre interessante, dando per scontato che la "curiosità tecnologica" è una dote che dovrebbe (anzi, deve!) essere sempre presente negli appassionati di programmazione. Che poi, se uno questa curiosità non ce l'ha... va beh, meglio fermarsi qui, No Comment...) 

Veniamo al dunque: dopo aver visto i primi tre misteri e cioè 1.Il mistero delle funzioni con un parametro array, 2.Il mistero delle funzioni che restituiscono una stringa letterale e 3.Il mistero delle funzioni che restituiscono un char pointer direi che il quarto mistero è quasi scontato, ed è:

4) Il mistero delle funzioni che restituiscono un void pointer
Nella libc ci sono un bel po' di funzioni che restituiscono un void* (per gli amici "void star"), come ad esempio quelle delle famiglia mem (memcpy(), memccpy(), ecc.). Come sono fatte? Ci sono alternative valide alla struttura "classica"? Vediamo un semplice esempio con una implementazione minimale della memcpy(), senza controlli, senza ottimizzazioni, senza tutto, ma per un esempio è più che sufficiente. Vediamo il codice, che anche in questo caso include un piccolo e semplice main() di test:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// prototipi locali
void *myMemcpy(void *dest, const void *src, size_t len);
void *myMemcpyMalloc(void *dest, const void *src, size_t len);

// funzione main
int main(int argc, char *argv[])
{
    // eseguo myMemcpy() e mostro il risultato
    char *src1 = "pluto";
    char dest1[32];
    myMemcpy(dest1, src1, strlen(src1) + 1);
    dest1[strlen(src1)] = 0;    // ricordarsi del terminatore se copiamo una stringa
    printf("myMemcpy(): dest = %s\n", dest1);

    // eseguo myMemcpyMalloc() e mostro il risultato
    char *src2 = "minnie";
    char *dest2 = myMemcpyMalloc(dest2, src2, strlen(src2) + 1);
    dest2[strlen(src2)] = 0;    // ricordarsi del terminatore se copiamo una stringa
    printf("myMemcpyMalloc(): dest = %s\n", dest2);
    free(dest2);                // ricordarsi di questa free()

    return 0;
}

// myMemcpy - versione semplificata della memcpy() della libc
void *myMemcpy(void *dest, const void *src, size_t len)
{
    // salvo localmente dest e src ed eseguo un recast a char*
    char *my_dest = (char *)dest;
    const char *my_src  = (const char *)src;

    // copio la copia locale di src sulla copia locale di dest (copio solo <len> caratteri)
    while (len--)
        *my_dest++ = *my_src++;

    // ritorno il dest salvato
    return dest;
}

// myMemcpyMalloc - versione con malloc interna di myMemcpy()
void *myMemcpyMalloc(void *dest, const void *src, size_t len)
{
    // alloco dest (N.B.: la free() la deve fare il chiamante della myMemcpyMalloc())
    dest = malloc(len);

    // salvo localmente dest e src ed eseguo un recast a char*
    char *my_dest = (char *)dest;
    const char *my_src  = (const char *)src;

    // copio la copia locale di src sulla copia locale di dest (copio solo <len> caratteri)
    while (len--)
        *my_dest++ = *my_src++;

    // ritorno il dest salvato
    return dest;
}
Anche in questo caso il meccanismo è semplice e quasi identico a quello della strncpy() mostrato nella parte 1 dell'articolo. Senza entrare di nuovo nei dettagli (per non ripeterci, e poi il codice è ben commentato), notiamo che la unica differenza vera è che la copia viene eseguita usando copie locali di src e dest "ricastate" a char: perché? La riposta è semplice: questo tipo di funzioni accettano parametri generici (grazie all'uso di void*), quindi si possono passare pointer a strutture, array, ecc. Ma poi, internamente, la copia si fa byte-a-byte, per cui si riconduce tutto al (magico) tipo char*. E, ovviamente, si ritorna sempre l'argomento dest originale, per i motivi già descritti sopra. E anche in questo caso ho pensato di aggiungere una memcpy() poco canonica, con allocazione interna, per la quale valgono tutte le considerazione fatte per la myStrncpyMalloc() già descritta.

Notare che, per coerenza con gli esempi della prima parte del post (e anche per mostrare con semplicità un risultato pratico) ho usato le due myMemcpy() per copiare una stringa (non è un uso classico, ma chi lo vieta?). Ovviamente ho provveduto, a livello main(), ad aggiungere un string terminator, visto che la myMemcpy() a differenza della myStrncpy() già vista, non può (anzi, non deve) pensare a eventuali terminatori di stringa già che è una funzione generica di copia di memoria.

E adesso possiamo cambiare un po' argomento (basta con 'ste funzioni di copia!) e possiamo passare, per esempio a:

5) il mistero delle funzioni con vettori di pointer
Come possiamo generare e maneggiare un vettore di pointer (o meglio: pointer-to-pointers, per gli amici star-star) usando funzioni? Vediamo un esempio semplice semplice, con il solito main() per mostrare i risultati:
#include <stdio.h>
#include <stdlib.h>

#define N_ELEMS 3   // numero di elementi da allocare nel vettore

// una semplice struttura di dati
typedef struct {
    int  id;
    char name[32];
} s_data;

// prototipi locali
s_data **allocVect(s_data **dest, size_t n_elems);
void   freeVect(s_data **dest, size_t n_elems);

// funzione main
int main(int argc, char *argv[])
{
    // alloco il vettore per il test
    s_data **datalist = allocVect(datalist, N_ELEMS);

    // scorro il vettore e mostro il contenuto
    for (int i = 0; i < N_ELEMS; i++)
        printf("allocVect(): datalist[%d]: id=%d name=%s\n",
               i, datalist[i]->id, datalist[i]->name);

    // libero il vettore
    freeVect(datalist, N_ELEMS);

    return 0;
}

// allocVect - alloca un vettore di pointer
s_data **allocVect(s_data **dest, size_t n_elems)
{
    // alloco il pointer-to-pointers
    dest = malloc(n_elems * sizeof(s_data));

    // alloco i pointer
    for (int i = 0; i < n_elems; i++) {
        dest[i] = malloc(sizeof(s_data));

        // questa parte è solo un esempio per mettere dei dati da mostrare nel main()
        dest[i]->id = i;
        snprintf(dest[i]->name, sizeof(dest[i]->name), "name_%d", i);
    }

    // ritorna il pointer-to-pointers
    return dest;
}

// freeVect - libera un vettore di pointer
void freeVect(s_data **dest, size_t n_elems)
{
    // scorro il vettore e libero ogni pointer
    for (int i = 0; i < n_elems; i++)
        free(dest[i]);

    // libera il pointer-to-pointers
    free(dest);
}
Avete visto? Ho scritto due semplicissime funzioni per allocare e liberare un vettore di puntatori (star-star), e la chiave del funzionamento (ben commentata, direi) è la seguente: quando abbiamo un vettore di pointer bisogna creare prima il pointer-to-pointers base (con malloc()) e poi bisogna creare i singoli puntatori del vettore (sempre con malloc()). E quando si libera il vettore bisogna, ovviamente, seguire l'ordine inverso (prima i puntatori singoli e poi il pointer-to-pointers principale). nell'esempio appena mostrato ho aggiunto nel loop di creazione una inserzione di dati, per avere qualcosa da mostrare nel main(): compilatelo, vi assicuro che funziona...

Notare che in questo caso il meccanismo di passaggio e uso degli argomenti è quello visto negli esempi "non canonici" visti nei precedenti misteri: si passa un argomento spurio (un dest non allocato) e lo si restituisce allocato al chiamante. Semplice, no?

E dopo questo esempio credo che siamo pronti per l'ultimo mistero di questa seconda e (per il momento) ultima parte dell'articolo:

6) il mistero delle funzioni per maneggiare linked-list
Le linked-list sono uno dei grandi misteri del C, eppure sono utilissime, e sono anche molto semplici da usare! Vediamo un esempio veramente elementare:
#include <stdio.h>
#include <stdlib.h>

#define N_NODES 3   // numero di nodi nella linked list

// nodo di una linked list singola con campo dati
typedef struct snode {
    int data;
    struct snode *next;
} node_t;

// prototipi locali
void addNode(node_t **head, int data);

// funzione main
int main(int argc, char *argv[])
{
    // init lista vuota e inserisce con addNode() N_NODES nodi con data = indice loop
    node_t *head = NULL;
    for (int i = 1; i <= N_NODES; i++)
        addNode(&head, i);

    // scorre la lista e stampa i valori (compresi gli indirizzi)
    node_t *my_head = head;
    printf("my_head=%p\n", my_head);
    while (my_head) {
        printf("data=%d (my_head=%p next=%p)\n", my_head->data, my_head, my_head->next);
        my_head = my_head->next ;
    }

    return 0;
}

// addNode - alloca in testa a una lista un node con dati e puntatore al prossimo elemento
void addNode(node_t **head, int data)
{
    // alloca un nuovo node
    node_t *node = malloc(sizeof(node_t));
    node->data = data;
    node->next = *head;

    // assegna head lista al nuovo node
    *head = node;
}
Cosa dire? più elementare di così! Eppure funziona... Come si evince dagli abbondanti commenti per fare una linked-list basta creare un punto di inizio (un "head") e aggiungere nodi con una semplicissima funzione che ho chiamato (in modo veramente originale) addNode(). Il segreto sta nella struttura del "nodo", che deve sempre contenere un puntatore al nodo successivo (ma va? Sarà mica per questo che si chiamano linked-list?). Ovviamente l'esempio fornito è abbastanza limitato, e mancano le funzioni per cancellare nodi, per appendere (invece di aggiungere) nodi, oppure per gestire la lista in modo doppio (double-linked-list), ecc., ecc. Ma sulla (solida) base fornita è possibile costruire, in modo relativamente semplice, tutte le estensioni che vogliamo.

Una ultima cosa: notare che il main() mostra, a titolo di esempio, il campo data dei nodi aggiunti insieme agli indirizzi del nodo corrente e del prossimo, e questo ci aiuta a vedere in pratica come funziona il meccanismo.

Beh, direi che con i tre misteri di oggi abbiamo svelato ulteriori dettagli arcani delle funzioni C. Ne rimangono ancora molti, ma per il momento ci prenderemo una pausa, perché sento già friggere molti neuroni e non vorrei creare danni irreversibili...

Ciao e al prossimo post!