Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Love C, hate C: Web framework memory problems

alew.is

Post reply on HN
Print view View original

121–130 of 218 posts

Re: Love C, hate C: Web framework memory problems

#121

Post by jenadine »

jstimpfle wrote: post #75
bluetomcat wrote: post #51

Earlier quoted context omitted.

Because in C, every allocation incurs a responsibility to track its lifetime and to know who will eventually free it. Copying and moving buffers is also prone to overflows, off-by-one errors, etc. The generic memory allocator is a smart but unpredictable complex beast that lives in your address space and can mess your CPU cache, can introduce undesired memory fragmentation, etc. In Java, you don't care because the GC…

No. Look up Arenas. In general group allocations to avoid making a mess.

I don't see how arenas solve the problems.

Re: Love C, hate C: Web framework memory problems

#122

Post by lelanthran »

uecker wrote: post #20
jacquesm wrote: post #12

Earlier quoted context omitted.

I've been doing this the better part of a lifetime and I still need to be careful so don't feel bad about it. Just like rust has an 'unsafe' keyword I realize all of my code is potentially unsafe. Guarding against UB, use-after-free, array overruns and so on is a lot of extra work and you only need to slip up once to have a bug, and if you're unlucky something exploitable. You get better at this over the years. But i…

I strategy that helps me is just not use open-coded pointer arithmetic or string manipulation but encapsulate those behind safe bounds-checked interfaces. Then essentially only life-time issues remain and for those I usually do have a simple policy and clearly document any exception. I also use signed integers and the sanitizer in trapping mode, which turns any such issue I may have missed into a run-time trap.

> I strategy that helps me [...]

In another comment recently I opined that C projects, initiated in 2025, are likely to be much more secure than the same project written in Python/PHP (etc).

This is because the only people choosing C in 2025 are those who have been using it already for decades, have internalised the handful of footguns via actual experience and have a set of strategies for minimising those footguns, all shaped with decades of experience working around that tiny handful of footguns.[1]

Sadly, this project has rendered my opinion wrong - it's a project initiated in 2025, in C, that was obviously done by an LLM, and thus is filled with footguns and over-engineering.

============

[1] I also have a set of strategies for dealing with the footguns; I would gues if we sat down together and compared notes our strategies would have more in common than they would differ.

Re: Love C, hate C: Web framework memory problems

#123

Post by card_zero »

obviouslynotme wrote: post #97
lelanthran wrote: post #54

Earlier quoted context omitted.

> Good C code will try to avoid allocations as much as possible in the first place. I've upvoted you, but I'm not so sure I agree though. Sure, each allocation imposes a new obligation to track that allocation, but on the downside, passing around already-allocated blocks imposes a new burden for each call to ensure that the callees have the correct permissions (modify it, reallocate it, free it, etc). If you're doing…

The most important pattern to learn in C is to allocate a giant arena upfront and reuse it over and over in a loop. Ideally, there is only one allocation and deallocation in the entire program. As with all things multi-threaded, this becomes trickier. Luckily, web servers are embarrassingly parallel, so you can just have an arena for each worker thread. Unluckily, web servers do a large amount of string processing, s…

> there is only one allocation and deallocation in the entire program.

> Short-run programs are even easier. You just never deallocate and then exit(0).

What's special about "short-run"? If you deallocate only once, presumably just before you exit, then why do it at all?

Re: Love C, hate C: Web framework memory problems

#124

Post by card_zero »

lifthrasiir wrote: post #110
galangalalgol wrote: post #104

Earlier quoted context omitted.

Most games have to do this for performance reasons at some point and there are plenty of variants to choose from. Rust has libraries for some of them, but in c rolling it yourself is the idiom. One I used in c++ and worked well as a retrofit was to overload new to grab the smallest chunk that would fit the allocation from banks of them. Profiling under load let the sizes of the banks be tuned for efficiency. Nothing…

Most pre-2010 games had to. As a prior gamedev after that period I can confidently say that it is a relic of the past in most cases now. (Not like that I don't care, but I don't have to be that strict about allocations.)

Because why?

Re: Love C, hate C: Web framework memory problems

#125

Post by free_bip »

card_zero wrote: post #123
obviouslynotme wrote: post #97

Earlier quoted context omitted.

The most important pattern to learn in C is to allocate a giant arena upfront and reuse it over and over in a loop. Ideally, there is only one allocation and deallocation in the entire program. As with all things multi-threaded, this becomes trickier. Luckily, web servers are embarrassingly parallel, so you can just have an arena for each worker thread. Unluckily, web servers do a large amount of string processing, s…

> there is only one allocation and deallocation in the entire program. > Short-run programs are even easier. You just never deallocate and then exit(0). What's special about "short-run"? If you deallocate only once, presumably just before you exit, then why do it at all?

Just because there's only one deallocation doesn't mean it's run only once. It would likely be run once every time the thread it belongs to is deallocated, like when it's finished processing a request.

Re: Love C, hate C: Web framework memory problems

#126

Post by frumplestlatz »

nurettin wrote: post #56
jacquesm wrote: post #45

Earlier quoted context omitted.

There are minimum standards for deployment to the open web. I think - and you're of course entirely free to have a different opinion - that those are not met with this code.

Yes, I have lots of opinions! I guess the question at spotlight is: At what point would your custom server's buffer overflow when reading a header matter and would that bug even exist at that point? Could a determined hacker get to your server without even knowing what weird software you cooked up and how to exploit your binary? We have a lot of success stories born from bad code. I mean look at Micro$oft. Look at al…

> Could a determined hacker get to your server without even knowing what weird software you cooked up and how to exploit your binary?

Yes.

Re: Love C, hate C: Web framework memory problems

#127

Post by mkfs »

davemp wrote: post #94
yipikaya wrote: post #78

As an aside, it's amusing that it took 25 years for C coders to embrace the C99 named struct designator feature: HttpParser parser = { .isValid = true, .requestBuffer = strdup(request), .requestLength = strlen(request), .position = 0, }; All the kids are doing it now!

I’m still regularly getting on projects and moving C89 variable declarations from the start of functions to where they’re initialized, but I guess it’s not the kids doing it.

> C89 variable declarations from the start of functions

Technically it's the start of a block.

Re: Love C, hate C: Web framework memory problems

#128

Post by fulafel »

jenadine wrote: post #114
fulafel wrote: post #112

Earlier quoted context omitted.

This shared memory and pointer shuffling is of course fraught with requiring correct logic to avoid memory safety bugs. Good C code doesn't get you pwned, I'd argue.

> Good C code doesn't get you pwned, I'd argue. This is not a serious argument because you don't really define good C code and how easy or practical it is to do. The sentence works for every language. "Good code doesn't get you pwned" But the question is whether "Average" or "Normal" C code gets you pwned? And the answer is yes, as told in the article.

The comment I was responding to suggested Good C Code employes optimizations that, I opined, are more error prone wrt memory safety - so I was not attempting to define it, but challenging the offered characterisation.

Re: Love C, hate C: Web framework memory problems

#129

Post by lifthrasiir »

card_zero wrote: post #124
lifthrasiir wrote: post #110

Earlier quoted context omitted.

Most pre-2010 games had to. As a prior gamedev after that period I can confidently say that it is a relic of the past in most cases now. (Not like that I don't care, but I don't have to be that strict about allocations.)

Because why?

Probably because hardwares became powerful enough that you can make a performant game without thinking much about allocations.

Re: Love C, hate C: Web framework memory problems

#130

Post by riedel »

bluetomcat wrote: post #21

Good C code will try to avoid allocations as much as possible in the first place. You absolutely don’t need to copy strings around when handling a request. You can read data from the socket in a fixed-size buffer, do all the processing in-place, and then process the next chunk in-place too. You get predictable performance and the thing will work like precise clockwork. Reading the entire thing just to copy the body o…

A long time ago I was involved in building compilers. It was common that we solved this problem with obstacks, which are basically stacked heaps. I wonder one could not build more things like this, where freeing is a bit more best effort but you have some checkpoints. (I guess one would rather need tree like stacks) Just have to disallow pointers going the wrong way. Allocation remains ugly in C and I think explicit data structures are are definitely a better way of handling it.
Post reply on HN