Hi again,

I have just had a look at @freemangordon's implementation of libcal, and it's a bit weird.

First of all: cal_read_block() and cal_write_block() do *internally* cal_init_ and cal_finish_ (which do the actual set-up and free()ing of the buffers).

So from the point of view of a user application you do not need to call cal_init() or cal_finish(), as they are nops.

The first thing your program does is to read the r&d_mode block. After the call to call_read_block the only thing that is valid is tmp_ptr and len, i.e. cal_s has been freed.

So towards the end of the program, when you actually call cal_write_block (if the mode string is different), cal_s is undefined, but it's OK because it will be cal_init_()'ed again.

If I read correctly, when you want to clear r&d_mode (*rd_mode_string == '\0')) you use sizeof(rd_mode_string) as the length. However the length should be zero. sizeof() gives the actual size of rd_mode_string, which is the same as sizeof(char *) which is namely 4 (for a 32-bit computer). You actually want a zero in there.

Basically you want to drop the "if(*rd_mode_string == '\0') and just use the normal path, where you use strlen(rd_mode_string) (which will be zero when rd_mode_string is empty anyway), however you need to get rid of the "+1" (why is it there anyway?, that's going to cause random segmentation faults).

But cal_write_block_() has a problem when len = 0, because it does malloc(len), which when len is zero may return NULL or a pointer. If NULL however, the function exits with an error (CAL_ERROR). This is something for @freemangordon to fix, unless it is required that when writing len > 0, meaning there should be another function to erase a CAL block.

I've printed cal.c and will read it when I'm on the train. Maybe I spot something.