Cello High Level C: A Fat Pointer Library

It's all fun and games until you say

    ++p

and pass that to a function that is silently expecting a length and other stuff in front of it. Calling these things "pointers" is a bit of a promotion from what they really are. Naming them "char*" or whatever is pretty dangerous if you ever do pointer movement.

Seriously, if you want descriptors and typed blobs, just make up a struct for what you want and pass it around. Say what you mean. Lying like this is going to hurt you.

There is all kinds of standards-abhorrent stuff and bad practices in here.

Examples from the link:

    struct Header* head = calloc(1, sizeof(struct Header) + data_size);
    head->type = type;

Head is not checked for null. This will segfault when heap allocations fail. [Preemptive reply to folks used to high-level languages and the Linux overcommit behavior: yes, heap allocations do fail, and yes, it is possible to handle such a failure well.]

    typedef void* var;

    // ...
    return ((var)head) + sizeof(struct Header);

It's illegal to do pointer arithmetic on void pointers. You need to cast to another type first.

    #define alloc_stack(T) header_init( \
      (char[sizeof(struct Header) + sizeof(struct T)]){0}, T)

That's going to crash when you try to access the T on many non-x86 architectures. On x86 you will have subtle problems like atomic ops failing to work.

I have seen cello come up on HN before. Seems like a cute hobby project based on some kind of flawed ideas of what "C" is. If people interested in learning C are reading, I suggest learning C "for realsies" and avoiding this thing.

A pointer you get from calloc() is guaranteed to be properly aligned to not cause SIGBUS on RISCs and some such. You cannot just add random sizeof(Header) to it and call it a general purpose allocation. struct Header needs to be a bit more elaborate than what they have. In fact, it shouldn't be a struct, but a union -

  union Header 
  {
      var type;
      max_align_t foo;
  };

whereby you get max_align_t from your standard libraries or do something like this -

  typedef union max_align
  {
    int i;
    long l;
    double d;
    void * p;
    ...
  } max_align_t;

These aren't fat pointers. A fat pointer is, well, fat: it's twice the size of a normal pointer, because it has both a memory address and a length. But Cello's 'fat pointers' are just regular pointers that happen to point to memory preceded by a length. Cello's 'fat pointers' don't solve the array slice problem.

Don't get me started...

It is called a struct. It holds arbitrary collection of any type of data safely while enabling the lazy programmer to pass only one parameter around. It is also safe (as must as it can be in C) unlike pointers that hide data behind their back and are just asking for trouble.

I will ignore all the problems and point out the worst offender, stack allocation example. That is not how you allocate arbitrary data on the stack, automatic char array is not malloc. In fact, in C you can't do it without using special platform specific functions. Anything else will cause undefined behavior.

If I understand this correctly, this are not fat pointers as used in e.g. Rust, where instead of a pointer you'd be passing in an argument a struct with two pointers, one to the object and the other to the implementation of the interface/typeclass.

Instead, they're more akin to vtables in C++, i.e. placing a pointer to the interface at the beginning of the object, before the data.

I need to read the source (or generated code) to fully understand how they implemented support for multiple interfaces/typeclasses.

Anybody who wrote a medium-sized project in C is aware of such a trick. And also of the load of problems that comes with it! (They are not really pointers anymore.) Please stop trying to make C look like javascript, just create a new language from scratch, the pile of syntax tricks you're playing with is bound to collapse.

A subset of this kind of tricks are usually embedded in the source code of any project of decent size or larger. But that sort of implementation usually comes with big disclaimers that spell out the hacky parts in very loud terms. I'm kind of wary of a library trying to glue new behaviour onto C on a general level. There are inevitably too many corner-cases which break the newly built abstraction. Those corner-cases can be explained away for one specific codebase that already comes with its own set of practices, rules of thumb, and coding patterns that the programmers are already forced to learn. But a library as general as this is easily used liberally, even casually, and without a complete map of the shortcomings and broken corners I can see lots of potential hair-pulling coming right up when things are no longer what they seem they should be.

Neat punning on C pointers with minimal increase in memory-footprint.

Some people have suggested putting array sizes in structs. But that will increase the level of indirection and hurt performance. Also it will require rewriting most applications.

With Cello's approach you just have to avoid pointer arithmetic. Everything should work.

This is the same as Pascal strings, popular among Windows programmers in the form of the BSTR type. BSTR also uses the same trick of putting the length before the string data so that the BSTR pointer can be treated as a char pointer.

I like the idea of breathing more life into C. Look at what's happened to C++. These days, when I need the efficiency, I prefer coding in C to C++. But I'm not sure Cello is the right way to make C better. If you're starting a new project, what's wrong with a struct that has an array and length of the array? Cello seems to break the simplicity of C and its memory model.

For alloc it says

    head->type = type;

Where does type come from?

What's the ELI5 here?