Why using X is (such?) a bad habit

Posted on 3 May 2007 by Barratis.
Categories: .Dev.

As some of you may know, I am a C-Unix (among others subjects) teacher assistant at my current school (EPITECH). When students come to defend their project, one of the reason of loosing point is to not check the return value of system call inside their code (-2 points each time one syscall’s return value is not checked).

As a result, some students has come of what they think to be a great idea (or I’ve been told so): the X functions. I’m going to pick the worst case of utilisation of this: xmalloc.

void	*xmalloc(size_t size)
{
  void	*buff;

  buff = malloc(size);
  if (buff == NULL)
    {
//EDIT: this is bad
//      fprintf(stderr, "not enough memory\\n");
//EDIT: kind of better
        write(1, "not enough memory\\n", 18);
      exit(1);
    }
  return (buff);
}

Well, in this implementation I’ve been kind enough to print an error message before exiting, some students doesn’t bored to do this much.

So, what is the problem of using this alternative to malloc? It’s pretty obvious if you’re asking me. I’m going to give a couple of examples:

First:

Let’s imagine that an application like Firefox rely on this kind of function (and I hope it doesn’t). Would you be glad if, you’ve been using your browser since several hours, having open several tabs and upon trying to open a new one boum ! “not enough memory” and Firefox exit. All your search lost… forever.

My point is that an application should never exit like that if she can still continue to work or manager its currents state. For example you should still be able to read your current tabs. But what if another error occurs ? Well one of the option is to allocate ressources to display error message at the beginning of the application to minize the case where you will not even be able to warn the user about the occurring problem.

But let switch to my second point:

This one is surely more cynicale. Take the case of an Operating system. Imagine that it can not found enough resources to start a task and just shutdown. Will that make you happy? I guess I don’t need to said anymore to prove this case ;).

So, please:

  • Check you syscall’s return values
  • Don’t quit upon failure if you can still manage to go on with your current state
  • Warn the user about the problem and give him the choise about what to do (going on or quit, etc).

I’ve got something more to tell about this xmalloc things, but I’ll keep it for another time. I’ve got to keep an eye on my students tonight :).

Weather…

Posted on 17 March 2007 by Barratis.
Categories: My Life, The Universe, and the rest...

Hi,

Now that I’ve started to work as grown up do (5 days a week 9 to 9), I understand a bit better their frustration about the weather. You see, all this week, we have been gratified by a blue and shinny sky in Paris. So I decided that it was time to start doing some roller-skating again and planned to do it on Saturday as my way to whsmith to buy a few English books to read.

Unfortunately, when I went out today it was windy and cold, all that was missing was the snow. Well, if it was snowing a few days before spring, it will be a bit hum… weird anyway :). Fortunately for me, it didn’t rain at all.

On my way to the Rivoli road, I came across a woman or a man wearing a shinny yellow dress (couldn’t see if it was a woman because of it) and an Egyptian mask. This person where on a little stool, and was as fixed as the queen’s guards. I took a little picture with my cellphone before leaving 1 euro behind. I regret I still haven’t bought a slim camera to catch moment like that, the quality of my cellphone is really poor (but the cellphone is kinda old too :)).

Well, I stop there. My life isn’t that interesting though ;). I’ll come again later, when is the question.

Ja !

Happy New Year !

Posted on 1 January 2007 by Barratis.
Categories: My Life, The Universe, and the rest...

And so here we are ! Goodbye 2006, Welcome 2007. The year has run very fast from my point of view, perhaps a little too fast :). Anyway, I hope this new year will bring to all of you what you’re are looking for and that mankind will acheive better things than before. May it be a year of happiness.

Below this post, you will find the lyrics of a song from the Blackmore’s night which I really appreciate (both lyrics and music) and which fit my thoughts for this new year.


Where has the time gone...it seems to fly so fast
One moment you're having fun, the next its come to pass
Days turn into yesteryear, old friends find their own way
Until the moment you leave...I wish that you would stay...

So here's to you, all our friends, surely we will meet again
Don't stay away too long this time
We'll raise a glass, maybe two
And we'll be thinkng of you
Until our paths cross again...maybe next time...

Let's laugh at the memories, and talk all afternoon
Let's remember the moments that leave us all too soon
We'll smile at the pictures still lingering in our minds
When you're reminiscing, then all you need is time...

Tracing faded photographs, a scrapbooks lonely charm
Pressed flowers and dreams we had, our fingerprint on time
The 1st moment we ever met, when your eyes met mine...
I remember the summers of Dandelion Wine

Makefile

Posted on 18 December 2006 by Barratis.
Categories: .Dev, Be Cool Be Geek, My Life, The Universe, and the rest...

Hi,

Sorry, I can of forgot to write about this as I did promise ^^”. So here I am to catch up with it.

So why Makefile ? In fact it’s quite simple. For those of you who know me a little or who are following this blog (fools :p), it’s not a mystery that I am a teacher assistant at my school. Thus, I am lead up to correct the first years projects. The problem is, that the grading is quite strict. If they don’t provide a correct Makefile they’re going to have a 0 mark no matter how much theirs project are.

And usually, Makefile are not correct. By correct I doesn’t mean that it doesn’t compile and produce the expected binary, but that whenever you type “make”, the program will be relinked even if no changes have been made to the source code! Rha, this really pissed me off (perhaps because I used to compile software on old computer a while ago and I know how frustrating it is to have to compile again for silly missing semicolon).

Of course, we are still looking at theirs projects to point out errors to them so they don’t loose their time, but still. It’s a shame that they keep making the same error after have been explained why theirs Makefile wasn’t correct. So, I took some of my time to make a little lesson about how should a Makefile be strucutred (at least at school).

Since it is aimed to the first year students, I made the lesson in french, so I’ll just give the URL here sorry :). But anyway, it is not very interested I didn’t covered a lot of the possibility of make, the online gnu manual do this job just well :). Ok, enough talk here is the link. And don’t forget, it’s not a reference and it is in french!

Cya, kisses and merry christmas

Sigc++-2.0

Posted on 26 November 2006 by Barratis.
Categories: .Dev, Toy'd.

Hello,

It took me some time, but as promise here comes my little speech on sigc++2.0 :). A few post ago, I mentionned how sigc++ made me loose a little time in my dev. Now it’s time to explain why, so people going through the same error will loose a litte more time.

We were one more time trying to find the perfect design for our Window Manager API. Rno, who is a fan of .NET, proposed to make the addition of handler on event in the same way as the MS framework : by using the += operator.

So I took a few minutes to dive into the sigc++’s headers to find the template relevant for our case, and I found it. We had to use this one :


template <class T_return, class T_obj, class T_arg1,class T_arg2,class T_arg3,class T_arg4>
class bound_mem_functor4 : public mem_functor4<t_return , T_obj, T_arg1,T_arg2,T_arg3,T_arg4>

And of course the signal to be used along this functor is the following one :


template <class T_return, class T_arg1,class T_arg2,class T_arg3,class T_arg4, class T_accumulator=nil>
class signal4 : public signal_base

Until there no problem. I made two typedef for saving the trouble that always come when you’re using template (that is the ugly template<params …>) :


typedef sigc::signal4<return , arg1, arg2, arg3, arg4> SignalEvent;
typedef sigc::bound_mem_functor4<return , classtype, arg1, arg2, arg3, arg4> SignalEventFunctor;

And finally I made the operator so we can use them à la .NET :


inline SignalEvent& operator+=(SignalEvent& sig, SignalEventFunctor func)
{
sig.connect(func);
return (sig);
}

Well, this was quite easy, the problem didn’t come from there. But wait, I’m coming to it ! It’s not a += operator for nothing, we made possible to stack more than one handler on a perticular event so they’ll be called one after the other by sigc++. But, here it comes, we also wanted to be able to stop sigc++ to call the rest of the handlers if one return false (or true I don’t remember :p).

Looking into the tutorial-style documentation of sigc++ I found something about Marshallers which let us do exactly what we wanted. At least it should have let us. It wasn’t possible to compile. So I went looking on google for a solution. And there after a little search in the vast knowlege base of internet I found in the changelog of sigc++ that Marshallers has been removed from sigc++ when they switch to the 2.0 to be replaced by Accumulators ! Damned it ! I should I’ve been more carefull and notice that the last parameter of the signal4 template was class T_accumulator=nil.

So I googled again to find something about accumulator to finally found how to use them. An accumulator is simply a class which defined at least two public component:

  • A template () operator:
  • a typedef of the return type of the above operator

Here is the Accumulator I made to achieve my needs:

class   CSignalEventManager
{
public:
    typedef bool    result_type;

public:
    template<typename IteratorT>
    result_type operator()(IteratorT First, IteratorT Last)
    {
        result_type bRet = true;

        while (First != Last)
        {
            if (!(bRet = *First))
                break;
            ++First;
        }
                return (bRet);
    }
};

Now that I’m thinking about it, the two parameters should have been references to avoid unneeded copy ;). Well anyway it’s working. I still wonder why the sigc++ documentation hasn’t been updated. I found several reports of this problem on their list though.

Well, perhaps this post will help someone with the same problem, anyway until the sigc++ documentation is updated it will be a reminder for me :p.