Ethan Black
What if #C had a function like alloclen which returned the length of a memory allocation? That could simplify some parameter-passing!
#CLanguage
May 20 at 10:22pmWeb
Show threadJosué Boisvert May 20
@golemwire I'm curious, in what context would you not have access to the requested memory size?
Show threadEthan BlackMay 21
No existing context I know of, right now.

It makes sense to me that the data structuring used by a memory allocator would hold allocation length information, so it would be nice to be able to read it.

The current solution that's idiomatic in C works, but when you need to refer to the memory allocation you often need two separate variables, one for the pointer to the data, and the other for the length. This impacts parameter passing, references from other structs, etc.

It would be neat if the memory allocation length were exposed, and we could just pass around one value, the pointer. I would imagine it would reduce cognitive load on the programmer (and by extension, hopefully reduce bugs).

CC: @[email protected]
Show threadJosué Boisvert May 21
@golemwire @pixx I understand what you mean, but I feel like that only push the issue onto the language, which would have to hold a table with pointers and their allocated lengths rather than having the developer rolling their own solution adapted to their needs
Although I see where you come from, the length still need to be stored somewhere
Show threadEthan BlackMay 21
Yeah, I don't think C really needs it; it's more of a reflection.

CC: @[email protected]
Show threadpixxMay 21

@golemwire @greenmoonmoon

By the way, if you're programming on plan9 you've been able to do this for decades:

extern ulong poolmsize(Pool*, void*);

you can just run `poolmsize(mainmem, alloc)` to get the size of an allocation that was malloced (since malloc gores through the mainmem pool)

Show threadpixxMay 20

@golemwire

What about stack allocations though?

e.g.

char foo[10];
bar(&foo, 10)

? You'd still have footguns now because you have inconsistent behavior for stack/heap, or you only support one, or...

Show threadEthan BlackMay 21
Well, a free(p_param) in this void bar(char *p_param) wouldn't work in either case, as bar would need to know that the p_param pointer points to malloc'd data, right? alloclen would only work with pointers which came from malloc, same as with free and realloc and such.

But many functions do need to know the length of an array but never need to deallocate it. So that's a valid objection.
Show threadpixxMay 21

@golemwire

No no, it's not about deallocations or frees at all

If I have a function that takes `(void *foo, usize foolen)`, it can take in storage from anywhere: stack, heap, mmap, it doesn't matter.

If you change it to just (void *foo) and assume you can use alloclen(foo), then the pattern in my original post becomes invalid

The following is valid C using a real API on plan 9 that will not do the right thing:

#include <pool.h>

void bar(char *foo);

char foo[10];
bar(&foo);

void
bar(char *foo)
{
int len = poolmsize(mainmem, foo);
// if foo is on the heap, len is the CAPACITY of the allocation
// given foo = malloc(15), len is guaranteed to be AT LEAST 15
// It may well be 16 or 30 or 100
// If foo is NOT on the heap,
// the result will be either nonsense or a segfault
// The only possible implementations are
// a) Assume on the heap, and give possibly invalid results, or
// b) Check if on the heap, and either crash or return -1 or etc
// There is no world in which this does the right thing for the stack unless stack allocation lengths are stored somewhere by the compiler etc
}

Show threadEthan BlackMay 21
OK, I think you're right.

C is a lower-level language (I know I've heard it's technically considered a high-level language, but you know what I mean), and I'm acting like it is higher-level than it is. Maybe this would work for a higher-level language, where it could be appropriate for the language to e.g. store a length value at the beginning of the stack array.

But then, what about pointing to a sub-array?

At this point, what I'm suggesting is probably just a bad idea.

Best I can think of is to do what higher-level languages do and have an array type which stores a pointer and length (or pointer, length, and capacity like Go). But at that point, just use one of those languages and leave C in its role, which it's good at....
Show threadpixxMay 21

@golemwire I mean, no, I actually agree that C could benefit a lot from slices in the language. It's a super simple thing, could be added to the compiler easily, and it would allow for exactly this, because it's just sugar for the direct passing anyways!

void bar(char *foo, int foolen);
void bar2(char[:] foo);

...

char foo[10];
bar(&foo, 10);
bar(foo+4, 6);
bar2(foo[4:]);

It's still explicit human tracking, not language/runtime, it's just a nicer way of passing this info around

Show threadpixxMay 21

@golemwire

(And once you HAVE a slice, it does provide a bit of extra safety: you can't subslice beyond the limits, etc)