Ethan BlackMay 20
What if #C had a function like alloclen which returned the length of a memory allocation? That could simplify some parameter-passing!
#CLanguage
Show threadpixx

@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...

May 20 at 11:57pmWeb
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)