MALLOC Wrappers Is Bad

I have found my old messages to wm-core@w.o mailing list. I have to admit that I still agree with most things I've said then. I still think that no library function should print something on the screen unless this is the main goal of the function. As the only exception to this rule I can accept some debugging output I can disable. I remember how much trouble was working with libxml2 which prints various warnings about malformed xml being parsed with no way to disable this. Exactly the same things I think about termination of applications within the library function. I prefer that these decisions should be left for application.

I thought about using Boehm garbage collector library. There's even some experimental code in WindowMaker to use it. It looks like a very appealing idea for a lisper like me. But garbage collectors are generally incompatible with tools like valgrind. And I want to use such tools, at least until I clean up the code. Also, using some garbage collecting library can possibly happen to be incompatible with some future changes like embedding extension language such as guile, which uses own garbage collector.

I decided to eliminate wmalloc, wmalloc0, wrealloc, and wfree functions. Checking return value everywhere malloc is used and reacting gracefully to that condition requires huge amount of work. It will take some time, and probably will be the cause of many other changes. I'll do it in a number of small steps.

Quest Description

WindowMaker is dead. Admit it. Website is half-alive, cvs is down, mailing lists are down, last release was more than two years ago. About three years ago, in previous stale period I have tried to start hacking it. The results were creation of new development team, creation of WM2 branch, and new release of main branch. Now the project staled again for a long time already.

I'm starting hacking it again. This time I work alone, privately, without any team. I am doing this for my own amusement and I fell free to change anything I want, even if what I change is a minor, unimportant, or low-priority improvement. I have source of the last release, and the cvs snapshot I was able to catch before servers went down. I don't care for «official releases», but at some point I'll make my git repository publicly available. I don't accept any patches. I don't want your code, please don't spoil my hacking fun. :) But I would be thankful for ideas and code reviews.

This blog is attempt to document the way I was thinking while changing code. Everyone can check what was changed, and how it was changed using version control tool. With some discipline from committer, it's even possible to see why something was changed. I thought that writing a blog can be a good way for describing decisions not directly affecting the code. And it can show what I was thinking about when decided to make some change.

Tags are filenames in repository. May be I will use some additional tags when appropriate. When my git repositary go public, I'll write commit ids to related postings.