The summary version (from Walter Bright's article) is:
> C can still be fixed. All it needs is a little new syntax:
> void foo(char a[..])
> meaning an array is passed as a so-called "fat pointer", i.e. a pair consisting of a pointer to the start of the array, and a size_t of the array dimension.
The paper mentions fat pointers in passing, not putting the term in quotes, not defining it, and not giving a citation -- which makes it clear that the term was already well established at the time.
Fat pointers were part of Pascal (and derivatives), although I'm sure the concept has existed in one form or another going back to the beginning.
edit: Pascal pointers were just a location and size, however, not a slice-type fat pointer; however, I have always heard of any pointer containing more information than a memory address referred to as a fat pointer (except tagged pointers). YMMV.
I don't think Pascal pointers had to be implemented as location+size, since most operations that required checking the size were undefined or implementation-defined anyway. Some implementations might have used them to provide runtime checks, but it was certainly not the case in Turbo Pascal, for example.
Sure, I never said that Walter Bright created the concept. What I’m saying is that the link from Cello that I posted on HN is actually using that definition from Walter Bright’s article.
They're clearly using a different definition. In Cello, you are not passing a fat pointer ("a pair consisting of a pointer to the start of the array, and a size_t"), but a totally standard pointer that points to the second member of a packed struct containing a size_t and an array.
The difference is massive. Bright's idea would allow me to use existing interfaces with fixed structure: as long as I know the declared length of an array, I could pass a fat pointer to a function that accepts one. 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.
One could justify the name of fat pointer, the other is really just arrays with headers.
> 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".
The summary version (from Walter Bright's article) is:
> C can still be fixed. All it needs is a little new syntax:
> void foo(char a[..])
> meaning an array is passed as a so-called "fat pointer", i.e. a pair consisting of a pointer to the start of the array, and a size_t of the array dimension.