[arghwhat]

The stack is fully automatic arbitrary memory and has nothing to do with registers. You can allocate as much as you want (including e.g. bytearrays), until you run into the allocated stack limit. That limit can be arbitrary, and some languages even dynamically scale the stack.

That you also have access to manual memory on the heap doesn’t matter. You can also do manual memory management in Rust if you want, as one has to do at times.

[Ygg2]

Ok. Then manual memory applies to just heap memory management.

It's not rocket science. If you are calling malloc/free to maintain your memory you're doing manual memory management.

> You can also do manual memory management in Rust

You can do Garbage Collection in C, it doesn't make it Garbage Collected language.

You're confusing default memory management with what's possible.

By your logic, Arena allocators can be used in many different languages, including GC ones like Java. So that means GC languages like Java are manually memory managed. Which is defeats the definition of it.

[arghwhat]

> It's not rocket science. If you are calling malloc/free to maintain your memory you're doing manual memory management.

Sure, and when I do the same in Rust I'm also doing manual memory management. So by your definition, both Rust and C are manual memory languages.

> You're confusing default memory management with what's possible.

Ah, so we care about the default, which I pressume is what the language semantics themselves provide, rather than focusing on what the standard libraries can provide you?

In that case C is an automatic memory language, because the language semantics only provide you stack memory. malloc/free are just random functions in the standard library after all, just like Rust's `Box::new` and `std::alloc`.

See, the point is that you're opting into manual memory management in C from an automatic model. We are so used to the stack that we forget that it's the OG fully automatic zero-cost memory management system, and in case of C++, can be used to implement fully automatic heap memory as well - in which case you never need to call malloc/free/new/delete.

(And no, it doesn't count that your smart pointer calls new/delete, because then you also need to count Box::new calling std::alloc)

> By your logic, Arena allocators can be used in many different languages, including GC ones like Java.

Uh, even in bog standard Java without any shenanigans you are using an "arena allocator". A GC doesn't change how allocators work, it just responsible for calling free.

(Caveat about moving vs. non-moving garbage collectors and ones that have multiple arenas, but that's not relevant here and an entire topic of its own.)

[Ygg2]

> Sure, and when I do the same in Rust I'm also doing manual memory management. So by your definition, both Rust and C are manual memory languages.

You're being very thick on purpose. In Rust you need to reach for foreign functions to implement malloc/free.

> So by your definition, both Rust and C are manual memory languages.

No. By my definition what is the default semantics determines if it's manual or automatic. It's CS 101.

But if you want to play these semantics games, you just admitted C is GC language and thus unsuitable for kernel development.

> Uh, even in bog standard Java without any shenanigans you are using an "arena allocator".

No, no you aren't. At least not explicitly. I assume you mean GC, if it has or doesn't have arenas is implementation detail.

It also hinges on Wikipedia being correct that Arena IS manual memory management, which is unsubstantiated at best.

[arghwhat]

> You're being very thick on purpose. In Rust you need to reach for foreign functions to implement malloc/free.

I think you're mistakenly thinking of calling out to the (rust-lang maintained) libc crate's malloc/free functions. That's not the case - the standard library provides `std::alloc`, which is the allocator also backing Box and Vec.

> No. By my definition what is the default semantics determines if it's manual or automatic. It's CS 101.

Your definition of default semantics - "in C it's not what the language does but what happens when you call random library functions, while in Rust it's the opposite" - makes no sense at all.

C isn't considered a manual language because of default semantics, but because people have chosen to mainly rely on such paradigm.

> No, no you aren't. At least not explicitly. I assume you mean GC, if it has or doesn't have arenas is implementation detail.

Yes, whether any allocator has an arena is an implementation detail.

Whether you call `malloc` or `new`, or you have Go or Java do a heap allocation for you (which, to nitpick, is not actually the job of the garbage collector), the use of an arena is an implementation detail. In case of GC, the availability of optimizations also depend heavily on whether it's a moving GC.

[Ygg2]

> That's not the case - the standard library provides `std::alloc`, which is the allocator also backing Box and Vec.

Again, emphasis on the word, default. How are you using Box and Vec. Are you by default encouraged to drop them manually via Allocator?

No, you aren't. You're heavily discouraged via usage of `unsafe`, you are discouraged because the compiler does automatic `alloc`/`drop`.

You have to go out of your way to do manual memory management.

> Your definition of default semantics

I showed you what happens when you apply the non-default semantics of a language to C. You end up with nonsensical statements like C is a GC language. Just because a style is possible in language X doesn't mean language X is of that style.

> C isn't considered a manual language because of default semantics, but because people have chosen to mainly rely on such paradigm.

And why is that? Because the default affordance of the language makes it so that way of usage is the most natural to most users. You could put everything in the stack, but that would be extremely torturous for most users, so they use malloc/free.

You give people a knife, of course they will grab it by the handle.