proj-oot-ootFatPointersNotes1

---

ATsch on April 14, 2020 [–]

typedef struct {uint8_t *data; size_t len;} ByteBuf?; is the first line of code I write in a C project.

...

Thing is, you rarely want to share just a buffer anyway. You probably have additional state, locks, etc. So what I do is embed my ByteBuf? directly into another structure, which then owns it completely:

    typedef struct {
        ...
        ByteBuf mybuffer;
        ...
    } SomeThing;

enriquto on April 14, 2020 [–]

That's a really bizarre layout for your struct. Why don't you put the length first?

...

ATsch on April 14, 2020 [–]

I'm not sure if it matters. It might be better for some technical reason, such as speeding up double dereferences, because you don't need to add anything to get to the pointer. But to be honest I just copied it out of existing code.

saagarjha on April 14, 2020 [–]

Most platforms have instructions for dereferencing with a displacement.

---

apotheon on April 16, 2020 [–]

> Conversely if you don't want any of this what's wrong with:

As I suggested, adding a(n optional) constraint such that "buf" can be limited by "len" in such a struct is a possible approach to offering safer arrays. Such a change seems like it kinda requires a change to the language.

loeg on April 14, 2020 [–]

Fat pointers in C would involve an ABI break for existing code, in that uintptr_t and uintmax_t would probably need to double in size.

rkangel on April 14, 2020 [–]

It would presumably involve a new type that didn't exist in the current ABI. Those pointers would stay the same, and the new (twice as big) pointers would be used for the array feature.

professoretc on April 14, 2020 [–]

The point of uintptr_t is that it's an integer type to which any pointer type can be cast. If you introduce a new class of pointers which are not compatible with uintptr_t, then suddenly you have pointers which are not pointers.

_kst_ on April 14, 2020 [–]

No, uintptr_t is an integer type to which any object pointer type can be converted without loss of information. (Strictly speaking, the guarantee is for conversion to and from void*.) And if an implementation doesn't have a sufficiently wide integer type, it won't define uintptr_t. (Likewise for intptr_t the signed equivalent.)

There's no guarantee that a function pointer type can be converted to uintptr_t without loss of information.

C currently has two kinds of pointer types: object pointer types and function pointer types. "Fat pointers" could be a third. And since a fat pointer would internally be similar to a structure, converting it to or from an integer doesn't make a whole lot of sense. (If you want to examine the representation, you can use memcpy to copy it to an array of unsigned char.)

saagarjha on April 15, 2020 [–]

Note that POSIX requires that object pointers and function pointers are the same for dlsym.

loeg on April 15, 2020 [–]

Surely you're not arguing that a bounded array is in fact a function rather than an object? The distinction between function and object pointers exists for Harvard architecture computers, which sort of exist (old Atmel AVR before they adopted ARM), but are not dominant.

kazinator on April 14, 2020 [–]

You would be shocked by this language called C++ which is highly compatible with C and has "pointer to member" types that don't fit into a uintptr_t.

(Spoiler: no, there is no uintptr2_t).

loeg on April 14, 2020 [–]

Ditto uintmax_t. We do not want a uintmax2_t.

---

FpUser? on April 14, 2020 [–]

In Delphi/FreePascal? there are dynamic arrays (strings included) that are in fact fat pointers that hide inside more info than just length. All opaque types and work just fine with automatic lifecycle control and COW and whatnot.

---

Gibbon1 on April 15, 2020 [–]

If C had real array types the compiler could do real optimizations instead of petty useless ones based on UB.

saagarjha on April 15, 2020 [–]

Fair, hence the push in many language for range-based for loops that can optimize much better.

---

https://www.digitalmars.com/articles/C-biggest-mistake.html

---