Sunday as first weekday, how can glibc be wrong?

It all happened after Sabayon bug 2699, and I am still laughing so hard.
Everybody in Italy knows at least two things: who is Silvio Berlusconi and what is the first weekday. I cannot guarantee on the rest, though.
But of course, glibc asserts that the second pillar of the Italian knowledge is just… wrong. For it and Ulrich Drepper the first weekday is Sunday and no matter what the fuck you think, say, write: as long as you don’t have the proof of it being Monday, you will live with the bug.

It seems that drepper has more power than our Prime Minister and his escorts all together when it’s about picking the first weekday! woot!

Agile programming and code abstraction level

During my insignificant life, up to now, I’ve seen many times people writing bad, or really bad, or really really bad code with the excuse of a tight timing or a dead-or-alive deadline to deal with.
It’s the principle that is wrong. If you are one of those, let me tell you why you are a failure yourself. You’re doing it wrong and you probably did since the beginning of your <latest coding adventure>.

At some point in the process, you started trading fast, easy designing and coding in change of less hassles (typical words: “who cares”, “we’re going to use <put-your-favourite-SQL-engine-here or other query language> anyway”, “this code has to do this-and-that, period”, “i’m not planning other features”). The funny part is that you did that with the Devil: you just sold (a part of) your soul to him (see “Bedazzled”, 2000, it’s a funny movie). And we all know that the Devil someday will knock back at your door.

This is not good for your health either. And it’s what the so called “Agile programming”  tries to avoid you. Agile programming, besides its scientific definition and explanation has the “side-effect” of “forcing” (see the quoting) you to write good code, with a good level of abstraction. Given that it warmly welcomes people wanting to throw code away for a rewrite (refactoring), keeping your architecture fresh over time.

Thanks to my dedication in trying to keep the whole Entropy (the package manager I wrote for Sabayon) architecture as much clean as possible (it’s still a “one-man-army” project), today I can happily break the underlying SQLite3 db schema without worrying of possible higher level consequences and, more important than anything else: keeping the holy backward compatibility. Also thanks to Agile programming (which is something nobody can realize by watching a plain git log).

Underestimation of Software Security

It’s like a virus, it’s everywhere. Whoever I talk with, doesn’t give a shit about software security. I’m not talking about some cryptic concepts or whatever, just, the basics, like pitfalls of strncpy(), just to name one.

Moreover, every single lecture I attended until now has never ever mentioned anything about this very, expensive and important field of Computer Science. Just one exception (worth mentioning): Lorenzo Dematté (kudos to him and his lectures, really appreciated) during his Computer Architecture course, explaining why buffer overflow are very cheap and devastating.

Hey, teachers!? Care to tell your students anything about software security and why developers should freaking care? (I’m pointing the fingers to the latest bunch of security exploits discovered in the Linux kernel, driving distro maintainers *cough* nuts).

Just my today’s rant!

An iterator that never ends

Most of the time I feel like dealing with a never ending iterator while fixing bugs. Once you fix one bug, another immediately pops up somewhere else. Or while you fix a bug, you find other two in a row. 90% of the time, it is because somebody else decided to break his API or just because in hurry, thus not seeing the whole picture in that exact moment. A new super-fast rewritten routine could impact the reliability of the whole code and cause damage. Even if a stupid file path mistake could generate tremendous effects. It is here, that corner-cases support is dropped.

What do I mean? That probably somewhere in your application you’re using a library in a legal-but-not-very-common way. …and upstream doesn’t know about it!
So, the efficiency drops a LOT! I can estimate that 60% of my time as free software developer is spent at fixing what other people broke. And other people spend time at fixing what I break, too, of course. So what could be a viable “solution” in order to mitigate the problem? Beside saying “there’s nothing against laziness, nothing against people forgetting to let other people know about important changes in their software” not much. Perhaps some kind of Twitter/Identi.ca interface? The Publisher/Subscriber pattern might work well. Maybe this is going to happen someday in future, who knows…

The worst code snippet I’ve ever seen

People working with me, know how much I do truly stress in regards to code quality.
Ok, it’s not the worst, I don’t even remember what the worst was, but I recall a lot of time-variant bugs caused by issues like the one in the snippet below. Problems like this can really upset you, but let’s start from the beginning, here’s the snippet (sorry for the pic, but wordpress is a pita — also see my devil mouse pointer in action).

Oh Good Lord! I spent 10 minutes wondering from where I should start discussing this code. I decided to start from the most visible issues. This code almost breaks any coder rule and looks like shit. I won’t tell you from where I took it, but trust me, it’s code that has been used for some time somewhere.

First of all: the scope of the code (“hey, it’s alpha software! we know it”) DOES NOT justify you at all! This code is clearly shit, warm and soft cow dung I’d say!

Issue 1: catching a base exception class just because you don’t know what your code could do means that you don’t know what you are doing. To write reliable code, you need to make your code crash! Or force it to work outside your mindset-boundaries. If things can go wrong, they will go wrong. Costs of maintaining such code will grow with the time and with the amount of functions using your library. What happens if at some point, results stops to be a list of lists (or tuples) [(1,2,3), (4,5,6)]? You will never know that, because the IndexError exception is going to be caught by the generic “except:” statement you wrote.

There are only two exceptions to this rule:

1. If you want to catch any exception, then execute some logging function and eventually raise (throw) the exception that you are handling. In case you cannot use the “finally” statement.
2. If the library you’re using sucks. It happens with some standard Python modules, like xml.doc.minidom. I had to use that utterly broken way of coding too, but under very controlled circumstances.

Issue 2: the code between try/except statements is too long. You may think I’m still talking about “Issue 1″ but I’m not. In general, you should not try to handle a lot of code inside it. For the reason that code mutates over time, requirements change, architecture changes and you could end up stuffing more code inside it and cannot afford to try to reduce the exposure to a particular exception, that should always handle a very specific case. Besides, using a lot of code inside try/finally while making sure to free resources in any case (file objects/descriptors and other critical things like file or thread locks) often due to security requirements is generally accepted (ehehe, at least by me).

Issue 3/4/5/infinite: it’s clear that the guy has no Python knowledge nor he/she spent time reading some Python books or the library documentation in regards to dictionaries. The second for statement could be one-lined by writing: ready = items.values() — or, with Python 3.x: ready = list(items.values()).

Playing with list indexes off lists not directly generated from the very same code snippet is just looking for troubles. An IndexError can accidentally happen and in the case above, nobody will notice it.

There are many other mistakes in that code, and I am frankly bored of talking about it. I spent one year trying to educate people I was working with about such errors, It’s just like somebody doesn’t know how C strlen() or strncpy() works in certain, corner-case circumstances (like omitting the final 0×00 [blame WordPress] if the buffer is not big enough, etc).

Hoping to have educated at least today.

Beware of “functions are first class citizens” mantra.

Ohohohoh, sorry I keep laughing and can’t stop. Tonite I want to make fun of “functional programming” people. Let me state that clearly: they live in another world. Helloooo?! It’s 2010, the second half. Please don’t advocate anything for that. You would just waste your time. Beside I do know something about functional programming and its philosophy, I truly hate it! It’s just pointless and a straight way to spaghetti code (another funny topic I’ll start blogging about soon).

A few months ago I had to study a programming language that is a failure itself (besides it’s the best of them, probably the most modern one): OCaml. There is some coolness in it, but it’s still a functional programming language, so it really sucks nowadays, and don’t tell me the fairytale about automatic unit testing and crap like that, it’s just bullshit (sorry for being so rude).

So, why am I talking about all this? Simple, when I code using Python or C/C++, I take advantage of the fact that I can pass pointers to functions across functions themselves (as arguments). Well, every time I do that, I end up with an odd feeling: is my code readable? Is my code getting closer to spaghetti style? Unfortunately yes. Being able to pass functions across stack frames is cool and very handy at a first sight, but you’re going to pay the consequences in the long run, because your code will become harder to read and to maintain.

So please, use the mantra in subject with caution, in an event-driven model, passing callbacks over is good and generally accepted, any other use of it, in non-functional programming, is just very bad.

My today’s coding quality pill ends here. More will come about that. As you may have seen, I don’t want (for now) to get too much technical, I leave the exercise to you.