Inspectfs relies on libudev for querying device information but I wrote some C++ wrapper classes because I want the project to contain as much C++ and as less C code as possible.
Soon you’ll be able to find the code and more on github, and if you want to join me, post a message here!

A classmate told me to use valgrind to test Skaar for memory leaks. Valgrind is a suite of tools for debugging and profiling programs, so that should work, and there I went:

valgrind --log-file=./valgrind.log --leak-check=full ./skaar

After shutting down, it turned out that Skaar had left something behind, and not that modest (43Kb) either. It’s actually not that simple to prevent memory leaks, I learned. The obvious cases seem to scream: free(3) or delete me, but the not so obvious cases keep their mouths perfectly shut..

Obvious case:
char* line = (char*)malloc(513);
memset(line, 0, 513);
strcpy(line, "PRIVMSG #mychannel :foo\r\n");
...
free(line);

Not so obvious case:
// in RFC1459.cpp
JoinMessage* joinmessage = new JoinMessage(this, line);
return (AbstractMessage*)joinmessage;

// somewhat later in Skaar.cpp
AbstractMessage* message = protocol->translateIncoming(rawmsg);
...
delete message;


I’m wondering if this is the right way to end the AbstractMessage*‘s life, by the way. Who’s responsibility is it to get rid of the message? I could go with this solution, that says: “Here is your object, have fun”. I could also create a function in the protocol that destroys the message, something like RFC1459::destroyMessage(AbstractMessage* message), that says “Here is your object, but you have to let me take care of it’s end. Actually, I have no clue which one is the best choice, if there is a best choice here..

But, back to business: all I have to do now is just test every possibility to see if there are any leaks. Or I could just watch it when I write code, which also sounds nice.
Another tool that I’ve come to value is gdb, The GNU Project Debugger. This tool allows you to see what happens ‘inside’ the program while it executes. And yes, I stole that line from gnu.org
To start using gdb is not very hard, just type gdb yourprogram, and that’s that. To actually start executing you program, type run once gdb has started.

After starting up the HULK for about a fortnight, we started to bring up ideas for projects (so if anyone has an idea…). Actually, while I’m writing this I realize that I haven’t told you anything yet about the HULK (hmm.. weird).
Well, HULK stands for Hogeschool Utrecht Linux Kennisgroep, and consists of a few classmates and yours truly, who try to give Linux a shot in our university, the Hogeschool of Utrecht. The website is in Dutch, so if you want to follow up on it, you have to be able to read it.

We thought about some really cool projects like building our own Ubuntu distribution, HUbuntu , setting up Linux on mobile devices, teaching Unix, and also some smaller projects like building a logbook to keep track of what we’re doing and to provide student services (SSH access, web servers, database servers, etc.). Apart from that, I’ve started learning c(++), and for practice I’m building an IRC client, called skaar.

Next week, together with Mattijs, I’m starting on the logbook which will be built in PHP, so that we can start logging quickly.

Keeping you posted!