Month: March 2010

Harmful + Evil = RAII for C

Some days ago I read an article about goto heresy that triggered me to write about my personal experience with the infamous goto instruction in C. The only reason I found for employing goto in C was error handling. Valentino provided me with a good idea on which I elaborate a bit. Thanks to this idea you can achieve a passable approximation of RAII in C.

It is not free (beer sense) as it is in C++ or other languages that support automatic object destruction, but if you stick to a set of IMHO acceptable conventions you should be happy with it. Shouldn’t these conventions fit for you, you may easily bend the solution to satisfy your taste.

Before delving into the technical description of the idea I am going to list the conventions that are requested for the idea to work.

First-class names have to be defined with the typedef instruction. E.g.

typedef struct
{
    int x;
}
Foo;

Then each class needs a constructor named like the class name with a trailing “_ctor”. In the same way, the destructor has a trailing “_dtor”. The first argument of the constructor is a pointer to the object to construct. Moreover, the constructor returns true if the operation has been successful or false in case of construction failure. It is up to the constructor to clean up in case of failure and not to leak any resources.

In the same way, the destructor has a single argument – the pointer to the object to destruct. By the way, by constructing I mean to receive a chunk of raw memory and turn it into a well-formed, invariant-ready, usable, and valid object. It has nothing to do with memory allocation – memory is provided by the code that calls the constructor. The destructor does the opposite – takes a valid object and by freeing the associated resources makes it a useless bunch of raw bytes, ready to be recycled by someone else. Now the idea is simple (as most of them after you know) – you need a way to keep track of what you construct so that when an error occurs you can go back and call destructors for each object already built. Since you don’t know how many objects are going to be constructed the data structure that fits best is the linked list. And, if you are clever enough you may avoid the dynamic allocation at all by employing cleverly crafted node names. When an object is successfully built a node of the list is created. Inside the node, the pointer to the built object is stored along with the pointer to the destructor. You know which is the destructor because you have the object type. When a constructor fails the execution jumps (via a goto) to the error handling trap. The trap simply sweeps the linked list and processes each node by calling the destructor on the object. Thanks to the C preprocessor the implementation is not so convoluted.

#define RAII_INIT   typedef void DtorFn( void* );  
                    struct DtorNode                
                    {                              
                        DtorFn* dtor;              
                        void* object;              
                        struct DtorNode* next;      
                    }                              
                    * dtorHead__ = NULL

#define RAII_CTOR( x__, T__, ... )      
    RAII_CTOR_WITH_LINE( __LINE__, x__, T__, __VA_ARGS__ )


#define RAII_CTOR_WITH_LINE( L__, x__, T__, ... )  
    struct DtorNode dtor_##T__##_##L__;            
    if( T__##_ctor( x__, __VA_ARGS__ ) )            
    {                                              
        dtor_##T__##_##L__.dtor = (DtorFn*)T__##_dtor;      
        dtor_##T__##_##L__.object = x__;            
        dtor_##T__##_##L__.next = dtorHead__;      
        dtorHead__ = &dtor_##T__##_##L__;          
    }                                              
    else                                            
    {                                              
        goto failureTrap__;                        
    }

#define RAII_TRAP                                  
    failureTrap__:                                  
        while( dtorHead__ != NULL )                
        {                                          
            dtorHead__->dtor( dtorHead__->object );
            dtorHead__ = dtorHead__->next;          
        }

RAII_INIT the mechanism by defining the type of the linked list node and the pointer to the head of the list. Note that a single link list is enough since I want to have FIFO behavior (the first constructed object is the last to be destroyed). Also, the name of the type will be local to the function where this macro will be instantiated, therefore there won’t be a collision in the global namespace.

RAII_CTOR macro is used to invoke an object constructor. The real work is done by the RAII_CTOR_WITH_LINE, which accepts the same arguments as RAII_CTOR plus the line where the macro is expanded. The line is needed to create unique node identifiers within the same function.

RAII_CTOR needs the name of the object type in order to be able to build the name of the constructor and the name of the destructor. From this information, the macro is able to call the constructor and add a node to the destruction list if successful or jump to the destructor trap if the constructor fails.

RAII_TRAP is the trap, to be located at the end of the function. It intercepts a constructor failure and performs the required destruction by scanning the list.

In order to use the macros you lay out the function according to the following canvas:

bool f( /* whatever */ )
{
    RAII_INIT;
    // some code
    RAII_CTOR( ... );  // one or more ctor(s)
    return true;    // everything was fine

    RAII_TRAP;      // code below is executed only in case of error.
    return false;
}

As you see the trap performs the destruction, but leaves you the space to add your own code (in the example the “return false;” statement).

So far so good, but you may argue that memory allocation and file open/close already have their conventions set in the standard library that doesn’t fit my macro requirements.

Don’t worry, it is quite straightforward to hammer malloc/free and fopen/fclose in the _ctor/_dtor schema. It is as simple as:

#define malloc_ctor(X__,Y__) (((X__) = malloc( Y__ )) != NULL)
#define malloc_dtor free

#define fopen_ctor(X__,NAME__,MODE__)   (((X__) = fopen( NAME__, MODE__ ))!= NULL )
#define fopen_dtor fclose

Here is an example of how the code that employs my RAII macros could look:

bool
f( void )
{
    RAII_INIT;

    Foo foo;
    FILE* file;
    void* memory;

    RAII_CTOR( memory, malloc, 100 );
    RAII_CTOR( file, fopen, "zippo", "w" );
    RAII_CTOR( &foo, Foo, 0 );

    return true;

    RAII_TRAP;
    return false;
}

This code has some great advantages over the solutions I presented in my old post. First, it has no explicit goto (the goto is hidden, as much as it is in any other structured statement). Then you don’t have to care about the construction order and explicitly write the destructor calls.

Though there are some drawbacks. First, the linked list has an overhead that I don’t think the optimizer will be able to avoid. The space overhead is 1 function pointer and 2 data pointers (plus alignment padding) for each constructed object. This space is taken from the stack, but it is completely released when the function returns.

The code requires a C99 compliant, or, at least a compiler that allows you to declare variables anywhere in the code (and not just at the block beginning). I think that the function pointer and argument pointer juggling are a bit on (or maybe beyond) the edge of the standard compliance. I tested the code on a PC, but maybe it fails on more exotic architectures.

So, what do you think?

Considering Goto Harmful, but…

Since I started programming in C until a few months ago I religiously practiced the rule “Don’t use goto” (totaling for about 23 years of abstinence). I remember I was puzzled at first – coming from BASIC programming, I hardly believed you could get along without the infamous instruction. To change my habits I took this as a challenge, and in a short time I was able to get rid of the evil statement.
In practice I was helped by a bunch of C statement that are basically disguised goto instructions: break, continue and return.
Break and continue allows you to jump out of a loop or at the next iteration; while return is a jump out of the current function.
Single exit point (i.e. just one return per function) is often preached as a Right Thing, but when programming in C, single exit fights madly with error management, forcing you either to deeply nest conditionals or to add boolean variables with the sole purpose of skipping code in case of error.
Amiga was the first computer I programmed in C, it was an advanced machine for those time, but experimental in many ways. For example Amiga operating system provided you with full multitasking capabilities, but the hardware lacked of an MMU therefore no protected memory was in place. This forced the programmer to be very careful about error conditions – one unhandled error and the entire system could be nuked by a single failing program.
That’s probably why I have been always attentive to error handling and graceful exit.
It was back then that I start using the idiom:

bool ok1;
bool ok2;
bool ok3;

ok1 = f1();
ok2 = f2();
ok3 = f3();

if( ok1 && ok2 && ok3 )
{
    // f1(), f2() and f3() returned ok.
}

if( ok1 ) free1();
if( ok2 ) free2();
if( ok3 ) free3();

This helps to avoid some nesting, but fails in tracking which function succeeded and which didn’t. That could be fine in some situation, but not in others. For example if you have to free some resources allocated in f2(), you have to know if f2() succeeded or not.
Conversely, the idiom below:

bool ok1;
bool ok2;
bool ok3;

ok1 = f1();
ok2 = f2();
ok3 = f3();

if( ok1 && ok2 && ok3 )
{
    // f1(), f2() and f3() returned ok.
}

if( ok1 ) free1();
if( ok2 ) free2();
if( ok3 ) free3();

Performs proper cleanup, but fails to capture that f2() has to be executed if, and only if, f1() succeeded.
Then I went the C++ way for several years and gained a markedly object oriented approach.
Using C++ you don’t have to worry much about these details if you happen to use the RAII idiom. That is, automatic object (i.e. local instances) gets automatically destroyed when the scope is left regardless of the reason that causes the execution to leave the scope.
In other words, if a function fails, be it with an exception or by reporting a specific error and triggering a return, objects that were built are destroyed, leaving the system in a good, non-leaking state.
Fast forward some years I am back to C programming with a heavy legacy of object oriented approach. This means that I try to design modules in an Object Oriented way – modules define classes, each class has one constructor that prepare the instance for usage. Each class also has one destructor (that may be empty, but this is an implementation detail, so if it changes in the future you don’t have to change the calling code).
This is the setting were the C error management issue arose again. I want to mimic a C++-like behavior so that when in the constructor there are 3 “sub-objects” to construct I want that proper clean up (i.e. destructor calls) are invoked in case of error.
If you follow a strictly structured approach (without exception support), you get a very convoluted code:

if( f1_ctor() )
{
    if( f2_ctor() )
    {
        if( f3_ctor() )
        {
            // succesfull
            return true;
        }
        else
        {
            f2_dtor();
            f1_dtor();
        }
    }
    else
    {
        f1_dtor();
    }
}
return false;

The lack of “fall through” semantic forces you to duplicate code and therefore makes the coding and the maintenance more error prone. In fact, suppose you have to add a third call f0_ctor() that must be called before f1_ctor(). Then you have to change nearly everything, indentation included.
Time to reconsider my mind framework. I would need something that selects a portion of “destructor” sequence. Something like a switch with fall through:

progress = 1;
if( f1_ctor() )
{
    progress = 2;
    if( f2_ctor() )
    {
        progress = 3;
        if( f3_ctor() )
        {
            progress = 0
        }
    }
}
switch( progress )
{
    case 0:
        return true;
    case 3:
        f2_dtor();
        // fall through
    case 2:
        f1_dtor();
        // fall through
    case 1:
        return false;
}

This can do, it is somewhat error prone when writing and/or changing the code. If you duplicate one of the progress codes you get a wrong cleanup that can go undetected.
Moreover it doesn’t seem to add much to the goto-based error management:

if( !f1_ctor() )
{
    goto error1;
}
if( !f2_ctor() )
{
    goto error2;
}
if( !f3_ctor() )
{
    goto error3;
}
return true;

error3:
    f2_dtor();
error2:
    f1_dtor();
error1:
    return false;

This notation is more terse (thus more readable) and appears to be more robust than the previous ones.
So why should I refrain from the goto statement in this case? There isn’t any good motivation.
I don’t want to provide any sort of “free for all” authorization in the wild usage of goto instruction. On the contrary my claim is that first you have to become of age without using goto (i.e. write programs for at least 18 years), practice Object Oriented Programming, carefully deal with error handling, then if you find yourself in a language lacking of a suitable error management, you may use goto… only if everything else is worse.

The Plan and Caprica

Battlestar Galactica is one of my favourite sci-fi shows, I watched the entire series and enjoyed it a lot. So I was eagerly waiting for the side story “The Plan”, with Ed Olmos’ words resounding in my mind – “then you’ll have to watch again the series”. If you imagine that my expectations were high, you are underestimating them.The Plan, basically is the Cylon backstage, what you don’t see directly in the show, but you put together from evidences, tips and untold parts of the story.
Caprica, instead is the pilot episode the prequel series, set some 50 years before the beginning of BSG and, my thumb estimation, 20 years before the first Cylon wars. The goal of the show is to tell the … well the prequel, why things got so screwed up with robots and what is all that fuss with the single god vs. the BSG-universe pantheon.
I liked Caprica, although I won’t buy the show – it is not enough “space-opera” for my taste. I found characters believable and promising. “The Plan” left me quite disappointed with the bitter feelings I wasted my money. That’s mainly because “The Plan” doesn’t add anything to the story, don’t expect twists or mighty revelations… the backstage is very similar to what you can imagine. Or, put in another way the story is what BSG show is telling, you may consider “The Plan” a sort of deleted scene collection, glued together to make a plot.
Now, the anti-spoil warning, if you want to watch the shows, go and watch them, then return here to read below. If you swap the order you are going to ruin an amount of entertainment.
The Plan, the story is strictly tied to the first season of BSG, starting with the moments before the Cylon attacks up to when two preacher Cylons (can’t remind Cylon model numbers… apart from six, can’t see why O:-)) are discovered and thrown through the airlock.
The story browse the motivation of cylons in the attack and the evolution of the feelings of human form Cylons toward humans. Apparently there is just one evil toaster (one of the Preachers) that is able to fast talk the others convincing they are doing the right thing in wiping out the entire human race.
“The Plan” provides some behind the scenes explanation to some mysteries. You’ll know who let the paper with the cue of 12 cylon models in Cmd. Adama quarters, as well as where the Six who accused Baltar disappeared. Other misteries are left unanswered (how did Baltar survived the nuclear blast? Just by taking cover behind Caprica Six?!)
“Caprica” is a different show, it is about virtual realities, teen agers, families. At least, this is what I can say after having watched the pilot. There is this robot industry tycon whose daughter dies in a terrorist attack. He suffer immensely from the loss, so when he finds that a virtual reality contains a nearly perfect copy of his daughter, he decides to transfer that identity in a robot (guess what kind of robot).
On the other hand another father lost his daughter in the same accident, and suffers the loss in much the same way, but, after having experienced the virtual reality, decides to let go her daughter giving up the idea to have a surrogate experience. This man last name is… Adama and his little son name is William.
The plot also involves the unique god, in the sense that the girls and the boy who caused the bomb attack were believers of the unique god.
So why if I liked the pilot I won’t go watching the entire series? Because I feel this kind of sci-fi, too little “sci”. This is something more about family drama, mysteries (strange things turns out to happen in the virtual reality), quest for power… something that doesn’t really need the distant future or space opera setting. At least the show is not enough motivating for me to afford the expenses, of course your mileage may vary.

Ritorno a scuola

Fa un certo effetto entrare a scuola in orario di lezione, ma sicuramente io e Ale eravamo troppo concentrati su quello che sarebbe successo e comunque non facciamo a tempo a spiegare alla bidella (ops, al personale non docente) perchè siamo lì che Juan ci corre incontro, ci prende uno per mano e ci porta nella sua classe.Già, perchè siamo qui, davanti a 19 paia d’occhietti furbetti e curiosi? Per fortuna abbiamo studiato: siamo qui per parlare dell’adozione, per rispondere a qualche domanda e fugare qualche dubbio su questa nostra famiglia “innaturale”.
Comincia Ale: secondo voi, cosa serve a un bambino per crescere bene? Cioè non per diventare grande e basta, per quello è sufficiente mangiare. Per diventare un adulto che sa prendersi cura di sè, aiutare gli altri e stare bene nel cuore?
Veniamo investiti da una mitragliata di cose necessarie, viste dai bambini stessi: giocare, essere amati, stare con gli amici, essere curati, … per le coccole serve un piccolo suggerimento, accolto con un corale: Sììì!
Bene, tutte queste cose arrivano normalmente dai genitori. Ma fare il genitore non è facile e se non le ha ricevute da piccolo, può capitare che non riesca a darle a sua volta. Rendendo suo figlio molto infelice ed esponendolo ad ogni rischio. Ed è per questo che quel grande non può più continuare ad essere mamma o papà. Ma dal momento che ogni bambino ha diritto a un papà e una mamma si cercano due genitori per lui e se non si trovano vicino, si cercano più lontano… in tutto il mondo se serve.
E questo è un po’ quello che è successo a Juan.
Juan, nostro figlio, lui che in questo momento non trova pace, nervosissimo si siede, poi si alza, fa un giro per la classe, prende un libro, cerca di leggerlo senza guardarci, poi sta un po’ con noi, poi ritorna in fondo all’aula…
Poi tocca me a parlare dei genitori pronti ad accogliere dei figli non nati dalla loro pancia, del loro faticoso cammino per conquistare il “bollino blu” e dell’attesa. Racconto anche dell’abbinamento – di quel momento da sovraccarico emotivo in cui ti descrivono tuo figlio (o i tuoi figli, come nel nostro caso) e alla fine ti fanno vedere la sua foto.
Juan porta in giro per la classe la prima foto che abbiamo di lui e della sorella, la tiene orgoglioso sul petto, tutti i suoi compagni devono vederla.
Infine parlo della Colombia, di questo paese esotico, verde, senza le stagioni, dove c’è sempre lo stesso clima tutto l’anno, caldo a Medellin e fresco a Bogotà, dove si trovano frutti sgargianti e sconosciuti, dove la gente è tranquilla, sorridente e bendisposta.
Juan porta le foto e aiuta i suoi compagni a sfogliarle, ma sempre senza parlare, e i bambini ricominciano con le domande. Alcune pertinenti (dov’erano Juan e Mariana prima che arrivaste a prenderli?), altre un po’ meno (come sono le macchine da corsa in Colombia?).
Qualche domanda la rimbalziamo a Juan senza troppo successo – è un momento troppo forte per lui.
Alla fine è passata un’ora. Le maestre ci dicono che i bambini sono stati molto coinvolti e che difficilmente riescono ad ottenere simili livelli di attenzione. Juan è contento, probabilmente è stata dura, ma forse questa ulteriore prova che di queste cose si può parlare, che noi siamo i genitori per lui, che non c’è nulla di brutto o sbagliato nel colore o nel paese da cui arriva, forse lo aiuterà a stare un po’ meglio.

Ogni scherzo vale

È l’alba a Castellanza, ogni giorno la gazzella si alza, il leone si alza, sì insomma, su veloci che dobbiamo uscire. Non perdete tempo… e tu cosa fai la foto all’alba?!
Chiacchere! Chiacchere e distintivo.
Un bel costume da bussola per la sfilata dei carri.
Una piccola principessa (anzi Cenerentola principessa per la precisione).
Sarà Carnevale, suon buon le chiacchere ok, ma la pizza… It’s Pizza Time!
Pronto?

Saving my precious pixels

I grew up in the computer world when hi-res meant 256 by 192 pixels. I think this is the main reason for my cult of screen space. I try always to use small fonts and arrange windows to avoid any waste.Windows (without MS prefix) are powerful way to present your application, but they come with a cost of wasted pixels around the border (and for the caption bar). Now Windows 7 (this this with the MS prefix) adds some more decorations with the only purpose of sacrificing some more pixels to the altar of uselessness.
Not happy with this move, the engineers from Redmond decided to hide deep in the configuration menus the option to get those space back.
If you want save those pixel, then you have to follow this procedure –

  • click on an empty area of the desktop,
  • select Customize (“Personalizza” in italian),
  • click on Window colors (“Colore finestre”),
  • then click on Advanced Settings (“Impostazioni avanzate per l’aspetto…”). At this point, if you are an old Windows aficionado, you are looking at a familiar sight.
  • Click on the Element (“Elemento”) drop down list and seek for Border Filling (“Riempimento bordo”);
  • on the Size (“Dimensioni”) spin field set the value 0 (or the value that best suites your taste).

Et voila. Your pixels are back, ready for some useful task.
(English terms in the UI I listed above are inferred from the Italian version of Windows 7).