hamsterdb: what’s the status?
I’m terribly late with the next release, which I already boiled down to the win32-port, without the port to Darwin/bigendian-architectures. I have two excuses for being late: my daily work currently demands a lot of time, and the second reason is one of the most stupid bugs I’ve ever had (and in this case I can’t blame anyone but myself). Here’s what happened:
Whenever I declare a structure, which is stored in the file, I have to pack it. It looks like this (simplified):
#include "packstart.h"
struct packed { ... } ;
#include "packstop.h"
All the packing-logic (in this case, printing #pragma pack) is in the header-files. The first few lines of packstart.h and packstop.h are macros to prevent the compiler from parsing the file twice:
#ifndef HAM_PACKSTART_H__ # define HAM_PACKSTART_H__ #endif
When including packstart.h twice, it was only parsed for the first time. And therefore the very same structure sometimes was compiled with, sometimes without packing. This resulted in segmentation faults, but also in strange situations where the debugger showed values which were different from those used by the compiler.
When I finally saw that, after one week of debugging, I had to bite in my keyboard, or I’d have started screaming…
I really hope that this is the last bug on win32. I will finish the code and then start testing, which will take some more days. I also have decided to use Visual C++ 5.0 as my development environment, and not Visual Studio 6, as I originally planned. I still prefer vi, but Visual C++ 5.0 (Visual Studio 2005) is available as a free edition and it looks nicer and seems to be more convenient then Visual Studio 2003.