What's this OLD C pointer-math / macro thing doing?

Question

I need help trying to understand what's happening in some old C code.

I'm utilizing an old btree/isam software product (from Softfocus) to write my data to the database. It essentially puts data into a mydb.dt file and the index data into mydb.nx (for example).

In my program, I have a struct with members corresponding to "fields" in the database. The struct is defined like so (I'm greatly simplifying with fictional data):

typedef struct {
    unsigned char name[50];    /*size is 50 bytes*/
    int active;                /*size is 4 bytes*/
    int yet_unused_bytes[46];  /*unused space (in fixed-length record)*/
} DB_PEOPLE;                   /*total struct size is 100 bytes*/

When I want to write to the record, I call the DB software's bt3Write routine like so (people_db_fd is my database-file's descriptor, and db_current_record_people is just a copy of my struct above, with data in it):

ret = bt3Write(people_db_fd, db_current_record_people);

That bt3Write routine is basically the following (I don't think it's important to know exactly what it's doing, but the key part is the trueBase bit). The fd is the database file, and data is the byte stream (the db_current_record_people struct that I'm handing to it above). I suppose recno is just some overhead for the nx file that I don't care about here, that lioWrite takes care of:

/*
 * all the keys are in; write the data record and store a copy
 */
if (lioWrite(fd -> fdData, recno, trueBase(data)) == UERROR)
    return (sfuint) isMuCallErr(BT3WRITE, 0);

In a header file, trueBase and BASEOFFSET are defined as the following macros:

/*
 *  macro for easing the buffer address calculations (who knows what
 *  may change down the road
 */
#define  BASEOFFSET             (sizeof(sflong))
#define  trueBase(address)      ((char *) address - BASEOFFSET)

Now, here's what I would like help with (I'm by no means a C expert... barely functional, really). I need to know what trueBase is doing (or your best guess). To my untrained eye, it seems like it's shifting the pointer to the data by the length of BASEOFFSET (which is 8 bytes on my system).

Extra bonus points for anyone who knows anything about this particular software product, too! It's pretty old, and I can't really find ANY documentation for it. It's commented fairly well - except for this bit.

Answer 1

Your analysis is correct. It looks as if they are storing some hidden header data in each allocation that they are doing. So they only give you a pointer to the "user" part. Only when you have to free the data, for example, you need to know the "real" starting point of the allocated space and that's what the macro is computing.

I don't apply for the extra point since I have no idea what that is.