new type to serialize pointers

[andrei-diaconu]

I use TPL to serialize structures between different processes. Both 32 and 64 bits are allowed. One of the structures contains a string (pointer) and a pointer to something else. That something else is irrelevant in other processes but has to remain in the structure definition. It is part of public API and cannot be changed.

Since that pointer was supposed to be NULL, I did a dirty trick: I used 's' for that field. Everything worked like a cham... until today, when it was not NULL.

I would like to have a 'p' that would just ignore and jump over a uintptr_t on serialization, and generates a NULL on deserialization.

Do you see any problems with this? Do you think this feature should be implemented? If this is straight forward to add, it would be great if you could help me with this. If you don't have the time, I think I will try to dig into the library and add the new type myself.

[troydhanson]

Ok, in a95c629 I added support for format character 'p'. It serializes a pointer-sized argument (without dereferencing it, of course). Do you really require it to be NULL on deserialization? Right now the implementation just restores whatever value the pointer had.

[andrei-diaconu]

Thank you very much for the quick response and fix. This fix works well if both the serializer and deserializer share the same architecture. If they have different sizes for pointers, the serialized data no longer matches.

Assuming I serialize on 64 bit, the data in the buffer will have 8 bytes for the pointer field. When I deserialize in 32 bit process, TPL expects only 4 bytes, and the remaining 4 will be considered part of the next field.

I proposed to deserialize to NULL because I imagined the TPL_TYPE_PTR type more like the TPL_TYPE_STR type then a integer type, except that instead of writing to the buffer the length and the content, there should be nothing written. Basically that would be advancing offset in the structure, but not also in the buffer while serialization or deserialization.

[troydhanson]

Ah yes thanks for clearing up my thinking. I did that commit in a hurry and it has all the issues you point out. I should revert it altogether and make it work as you describe. I'm going to leave this open as a reminder. I am not sure if I'll get to this right now so if take a stab at it please feel free to send a pull request (you can modify the 'p' format that's in my faulty version to make it work the desired way).

[tbeu]

Was reverted by c304850.