News for hackers. Stuff that matters.
Re:The C juggernaut illustrated (2012) by wheelerof4te on Saturday February 04, 2023 @06:19PM (#34659497)
Isn't malloc one of prime reasons that makes C "less likeable"?

I would imagine banning the use of malloc would make C easier, not harder to code in.

Re:The C juggernaut illustrated (2012) by tmtvl on Saturday February 04, 2023 @06:32PM (#34659609)
Ban malloc, use stack only? Using C like Forth is definitely a thing someone could do.
Re:The C juggernaut illustrated (2012) by convolvatron on Saturday February 04, 2023 @06:25PM (#34659547)
what would you replace it with? stack allocation almost everywhere and acyclic reference counting when you absolutely have to?
Re:The C juggernaut illustrated (2012) by steveklabnik on Saturday February 04, 2023 @06:47PM (#34659753)
I write Rust code without malloc equivalents.

You stack allocate, you statically allocate. Anything growable either doesn’t grow, or preallocates (on the stack or statically) an upper limit and “grows” within that.

Re:The C juggernaut illustrated (2012) by galangalalgol on Saturday February 04, 2023 @09:23PM (#34661014)
Often for dsp type stuff you'd blow out the stack for the size of a time series or image buffer. I typically preallocate when the size is known and reuse. Is yhere a good way to do that statically.
Re:The C juggernaut illustrated (2012) by steveklabnik on Saturday February 04, 2023 @09:28PM (#34661047)
In Rust? Simplest thing is to declare an array as a static. Mutable statics do require unsafe, because it's inherently not threadsafe, but if you wanted to stay away from that directly, just depends on what kinds of tradeoffs you're interested in making.
Re:The C juggernaut illustrated (2012) by galangalalgol on Saturday February 04, 2023 @09:37PM (#34661120)
I didn't realize who I was replying to! But yes in rust. I have messed with mutable statics with a mutex and maybeuinit mostly for exporting stuff as a cdylib that has mutable state, and found I lose some of what I love about rust. So I heap allocate once and do borrows for each stage in my pipeline (SDR stuff). Sometimes a stage copies to cuda device mem, or back, or doesn't and just carries a device pointer through behind an abstraction. Is there a good reason to avoid preallocation on the heap?
Re:The C juggernaut illustrated (2012) by steveklabnik on Saturday February 04, 2023 @10:02PM (#34661313)
I thought we were talking about a situation with no heap! If you have that luxury, heck yeah just call malloc.
Re:The C juggernaut illustrated (2012) by SAI_Peregrinus on Sunday February 05, 2023 @05:10PM (#34670134)
That's not always viable. Allowing heap allocation only at init is pretty common in embedded. Read config to get sizes, allocate at startup, never call free().
Re:The C juggernaut illustrated (2012) by steveklabnik on Sunday February 05, 2023 @09:58PM (#34672735)
I don't understand what you mean by "That's not always viable." You can either call malloc, or you can't. If you can only call it at startup, only call it at startup. Every project has different requirements, and Rust will let you satisfy any of them.
Re:The C juggernaut illustrated (2012) by wheelerof4te on Sunday February 05, 2023 @04:14AM (#34663255)
I believe first Warcraft game used the same technique in C, IIRC.

Seems to have worked. But it would be a mess to use only stack and static memory for today's large applications.

Re:The C juggernaut illustrated (2012) by steveklabnik on Sunday February 05, 2023 @09:15AM (#34665036)
Absolutely, it’s a pain in the butt. But sometimes it’s what you have to do.
Re:The C juggernaut illustrated (2012) by AnimalMuppet on Saturday February 04, 2023 @10:17PM (#34661426)
Static buffers, which means they're created at program load time. IIRC, MISRA also allows malloc, but only at startup.

And then you re-use your existing buffers.

Re:The C juggernaut illustrated (2012) by galangalalgol on Saturday February 04, 2023 @11:27PM (#34661857)
To be fair, that is how I code anything I want to be performant regardless of language.