> The problem you are wondering about is how to deal with changes in your own code. Actually, no. I'm wondering how do I write my code as to be forward compatible with future versions of Sqlite that may add new members to the structs without breaking my code written for the current versions. As I mentioned in my OP, C is not my forte and from what I saw so far, C has the convention of having a field in a struct to report the size of the structure or in Sqlite's case, the version supported. What I was uncertain is that the field doesn't exist on all structs (in this case, the `sqlite3_vtab`, `sqlite3_vtab_cursor`, and `sqlite3_index_info`). That seems to go against what I thought was the convention in handling versions of struct in C. The linked documentations indicates an expectation that the `sqlite3_vtab` and `sqlite3_vtab_cursor` will be likely subclassed (and we can see that in the sample), but those don't have a field that reports versions or size of the structure. How will I know that I won't be writing code that will break in a future version of Sqlite? It might be that I'm not fully understanding the conventions used here and I want to make explicit the implicit convention that may be used here. I believe that is the first time I saw a version field being used for more than one structs when in other uses, every struct always has a field to report the version.