Hacker News Reader

Comment by wheelerof4te | Hacker News Reader

C has automatic memory management for the static memory and memory allocated on the stack.

It's possible to program in C without manual memory management.

It is "automatic" in the sense that the compiler generates the necessary prologues and epilogues in functions to set-up and restore the stack, to allocate local variables at certain frame offsets or in registers, and to free the programmer from dealing with that stuff. What is purely a widely used convention in assembly programming becomes a language feature.

"Static memory" is just a named reference to a memory location in the program data section.

I have never used them, but I think C has garbage collection libraries: https://stackoverflow.com/a/28779266.

This is how LP made systemd vulnerable by allowing external input to smash the stack because of profligate use of alloca as a poor man's GC.

Hey, our grandparents wrote FORTRAN 66 code without any dynamic memory management (not even the stack) and landed on the Moon.

Not for programs where the amount of items you must store is only known at run time.

C99 has VLAs and there is always man 3 alloca

Deprecated in C11 as it was acknowledged how bad idea they were in first place.

C99 is a much newer standard though. 1911 C was very primitive, pre-ansi C, basically an assembler for Babbage machines.

Looking forward to the Analytical Engine compiler backend punch cards.

VLAs have been deprecated, alloca was never part of a C standard AFAIK.

I was not suggesting that any of both is a good idea - but they are tools 'for programs where the amount of items you must store is only known at run time.' (Assuming that not having to free is considered "automatic memory management").

Deprecated? I thought they were only made optional?

Which allows any compiler that never implemented C99 to be certified as compliant on later standards (C11, C17, C23), thus yielding the same outcome in practice.

The status of VLAs is officially the exact same as the status of 'uint32_t' and the like, so I think it's fair to say there's a significant difference between something being optional (a la uint32_t) and something being deprecated (a la gets).

But I agree, in practice, the change to VLAs feels more deprecation-like, because they got demoted to optional because everyone more or less recognised that they're a bad idea, I don't imagine GCC will remove it any time soon but I wouldn't be surprised if it got options to disable them and if those options eventually became enabled by default.

Correct, they are optional, not deprecated. That was sloppy on my side.

If you use alloca that's not "automatic memory management" is it?

Interesting. If I think 'automatic memory management' in C I think about not having to free.

Of course you are right that it's not the same as using e.g. a Python List.

Why would alloca be more manual than allocating a sufficiently large statically sized array, or allocating variable stack memory with VLAs?

Well, for starters, because you expicitly call to allocate. A static array is implicitly allocated by saying you want an array.

Furthermore, neither does any memory management, the memory is retained till the end of the program. "Simple memory acquisition" perhaps, "memory management" not, except if we accept it as a degenerate case, where things aren't even freed except when the program ends.

You may be thinking of malloc. Memory allocated by alloca is allocated on the stack, so it lives until the end of the stack frame.

And the difference between 'char buf[size]' and 'char *buf = alloca(size)' isn't significant enough to put the two in separate paradigms IMO, just slightly different ways of writing the same thing.

>You may be thinking of malloc. Memory allocated by alloca is allocated on the stack, so it lives until the end of the stack frame.

I see, but you still have to ask nicely for it explicitly.

Can you respond to the second part of my comment? 'char buf[size]' seems just as explicit as 'char *buf = alloca(size)' yet you're comfortable claiming that one constitutes automatic memory management and the other manual memory management? How is it not just two slightly different syntaxes for the same thing? I'm really struggling to understand how there's such a big fundamental difference.

>How is it not just two slightly different syntaxes for the same thing?

Well, anything that ends up allocating some memory for you and giving you back handler would be also "slightly different syntax for the same thing".

I'd say that the first case abstracts away the allocation though, while the second makes it explicit. It's just too small an example to be that big of a difference.

Another thing that comes to mind, is that you can just write:

char buf[4] = "foo";

to initialize the string, whereas with alloca you'd need something like:

char* buf = alloca(4); strcpy(buf, "foo");

Isn't the latter quite more manual?

So you think two different syntaxes for allocating N bytes of automatically managed (i.e stack) memory are in fundamentally different classes of memory management because one is slightly more explicit than the other (because a pointer is returned or something I guess?). I don't agree, but at this point, it's semantics.

In the literature though, you may find that "manual" memory management usually refers to memory management where the programmer has to call a 'free'-style function manually, while automatic memory management usually refers to anything where the programmer doesn't have to call 'free' (be it thanks to lifetimes or GC or automatic refcounting or whatever).

There's still significant drawbacks, mostly that the data only lives during the lifetime of the scope.

These are usually discouraged. If there's small upper bound on the size you'll need, type array[MAX_SIZE] is more efficient and harder to mess up [0]. If there isn't, you should use the heap.

[0] For more details, see e.g. https://nullprogram.com/blog/2019/10/27/

VLAs dont seem to be all that hot. https://news.ycombinator.com/item?id=18323938 The Linux Kernel Is Now VLA (Variable-Length Array) Free (phoronix.com)

fork(), malloc(), exit() when done.

How is that "automatic memory management"?

It is a brute force arena allocator. No free needed. But mostly a joke.

It's a completely valid memory management strategy for "one-shot" command line tools though.

It is. Unfortunately when I tried to use it in a particular product, I got so much negative feedback from our Coverity and other static analysis tools that I have given in and added calls to free everywhere.

It's more than that. It's a "valid" strategy even for long lived servers. Fork, do the thing which requires heap memory in the child, then exit the child (but the parent keeps running).

With smart missiles, you don't even need that exit().

Who needs exit() when you have kill().

> Not for programs where the amount of items you must store is only known at run time.

Usually it's not necessary to load everything into memory. It's usually more efficient to process data similar to map-reduce, and just use stdio and stdout

FWIW, AIX has a utility that ypou can use to increase stack on a executable:

ldedit

I do not know if Linux or the BSDs have the same, or if it is even needed on those systems.

The default stack limit in Linux is 8MiB, which is kind of huge as far as stacks go.

Yes, 8MiB per CPU process, if I'm not mistaken.

Reply on news.ycombinator.com