Attached: battering-ram-memmory.jpg (425x351, 100K)
It's possible to write a C program without memory allocation?
John Lopez
Other urls found in this thread:
man7.org
twitter.com
William Watson
no
Justin Russell
what do you mean by "memory allocation"?
Luis Moore
Depends on how the program is designed. The OS allocates a stack for each thread, you could (ab)use it to allocate memory as needed without ever using malloc, or even implement malloc around stack memory, but it's a very fast lane to segfault city.
I wrote a small server this way once, all global state was allocated on the main thread's stack, worker threads had their own state in each stack. It was barely larger than an instance of sh (as in ash, not the fat pig that is bash).
Jonathan Perez
A better question would be why you would want to do that, other than being too afraid of leaking some.
Colton Phillips
idiot
Bentley Bennett
it's impossible to write a program in any language without allocating at least some memory
Jace Morales
It’s possible to write a C program without malloc.
Adrian Brown
maybe an embedded software?
Brayden Rogers
You'd be limited to a stack size of under 2MB for every stack frame, that's pretty worthless.
Ayden Adams
>tfw entire operating systems and productivity suites used to fit in 1MB
Nolan Johnson
Not a clear question.
A program must be loaded into memory to run. But it doesn't allocate additional memory unless done explicitly, either by declaring an array (in which case it's done before hand) or allocated dynamically (done when/if needed).
So by writing a program that doesn't use any additional memory, the compiler decides if and when to use the stack. During function calls, if they can't be inlined, return pointers are saved to the stack. Also certain registers are saved to the stack during C calls.
The only way to make sure the program doesn't allocate additional memory is to write it in asm without C calls.
James Jenkins
>tfw entire operating systems and productivity suites used to fit in 1MB
Just what the fuck happened
Cameron Morales
Nothing. Start writing everything assembly again. Problem solved.
Ryan Mitchell
This is what makes C great, why wouldnt you want to?
Brody Reyes
right or just use C because muh architecture compatibility
Caleb Powell
As hardware got cheaper, software managers came to the conclusion that was also cheaper sacrifice computational resources using high level programming languages in order to save time and money they would use for programmers. As hardware gets faster and cheaper, businesses tends to add more and more layers of abstraction.
Ryan Walker
Depends on how strict/autistic you're about your question. You can write C code without using malloc and similars, but there will be dynamic allocations when the os starts your application.
Chase Allen
Just write all your programs in llvm.
Justin James
Ryan Ramirez
Sounds nightmarish desu, but also interesting.
Robert Turner
Early Mac programs were Pascal, C, and C++.
>using high level programming languages in order to save time and money
Do they save any time and money? And do they need to be so bloated? I'm not impressed on either point.
Dylan Morris
There's a NASA document somewhere that has guidelines for deep space probe software.
I seem to recall that one rule was no dynamic memory allocation. Now I don't know what the compilers do under the hood...if everything is on the stack or not...but basically no alloc/malloc/etc.
Jace Adams
how'd it perform?
Dominic Gomez
Assuming you mean without dynamic allocation, e.g. malloc / calloc, then yeah, it's quite easy.
Just use the stack (local variables) for the most part, and for large chunks of memory, use global array variables / static local array variables and then you aren't limited by the size of the stack.
You can have one big char mem_block[MEMORY_SIZE]; as a global variable and split it up as you need it and implement your own malloc / free equivalents using similar algorithms to those used by C libraries. While it is technically undefined behaviour to cast random pointers within this memory block to any type you want like you would with malloc, you should be fine in practice if you align them adequately. Or alternatively, you could use separate arrays for different types just to be strictly standards conforming.
If the only functions you have which require big blocks of memory don't get called recursively / in different threads / with a lot of shared state, then you should be able to just use fixed arrays as you need them as static local variables and not bother with a makeshift malloc at all.
Mason Harris
Of course you can. What do you think a kernel is?
Zachary Harris
>Sounds nightmarish
As long as you know the limits and can constrain the program appropriately it's doable. Especially if you explicitly set the size of thread stacks when creating them, then you're only bound by system limitations.
>how'd it perform?
Like any other C program minus the overhead of malloc, pretty nippy. It was more of an experiment really, the scope of the project started growing beyond what I was comfortable keeping in stacks and ultimately I just rewrote the whole thing.
I also wrote a process supervisor for cloud containers in this same fashion, but it turned out to be only marginally lighter than just using s6 with alpine as base, so I dropped it.
Ian Torres
nice!