> The Cello approach would require me to modify the interface to accommodate the new size header that is packed with the array. ABI break, not compatible with existing C code and libraries.
Isn't the entire point of the article that this is not the case?
My understanding is that a Cello array is laid out like this:
<metadata header>.<actual payload data in standard C format>
^
|
this pointer is what you pass to existing C code
The existing C code gets a pointer to data exactly as it expects. It does not get a pointer to the metadata. It could access it by subtracting an offset from the pointer it's given, but it will not do that since it does not expect anything meaningful to be there. "This pointer is fully compatible with normal pointers".
No. The problem is that you have to have that metadata there, where ever it is that you want to point. What if it's not there? Oh yeah, doesn't work. It's just a normal pointer, pointing to an array and header.
If I pick up some library (or system call interface..), and it uses this structure
struct foo {
struct bar a;
char b[64];
};
The metadata field that cello wants is not there. I cannot use cello's "fat pointers" because they are not fat pointers at all. I would have to modify the struct to have array-with-length-header (which is what cello calls a fat pointer.. talk about confusing pointers and arrays!) , which might be impossible if it's someone else's binary interface that I am using.
If I had actual fat pointers, then the size would be simply passed together with the pointer and I wouldn't have to have modify structures to accommodate an extra field. Of course, I can't pass these pointers to functions that expect normal pointers, but it wouldn't make sense to do that anyway, and if implemented right, doing that would require me to misdeclare a function. You would pass normal pointers to old C code that expects and deals with normal pointers.
You can pass Cello pointers to old C code that expects and deals with normal pointers.
It's true that the internal array inside a struct cannot magically become a Cello fat pointer. So yes, you cannot pass a pointer to that array into a Cello function that expects a fat pointer, but that's the opposite of "pass normal pointers to old C code".
Isn't the entire point of the article that this is not the case?
My understanding is that a Cello array is laid out like this:
The existing C code gets a pointer to data exactly as it expects. It does not get a pointer to the metadata. It could access it by subtracting an offset from the pointer it's given, but it will not do that since it does not expect anything meaningful to be there. "This pointer is fully compatible with normal pointers".