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

131–140 of 218 posts

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

#131

Post by nurettin »

frumplestlatz wrote: post #126
nurettin wrote: post #56

Earlier quoted context omitted.

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.

Yes but how? After the overflow they still have to know the address of the next call site and the server would be in a UB state.

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

#133

Post by lock1 »

lelanthran wrote: post #55
lock1 wrote: post #48

Earlier quoted context omitted.

Why does "good" C have to be zero alloc? Why should "nice" javaesque make little sense in C? Why do you implicitly assume performance is "efficient problem solving"? Not sure why many people seem fixated on the idea that using a programming language must follow a particular approach. You can do minimal alloc Java, you can simulate OOP-like in C, etc. Unconventional, but why do we need to restrict certain optimization…

> Why does "good" C have to be zero alloc? GP didn't say "zero-alloc", but "minimal alloc" > Why should "nice" javaesque make little sense in C? There's little to no indirection in idiomatic C compared with idiomatic Java. Of course, in both languages you can write unidiomatically, but that is a great way to ensure that bugs get in and never get out.

  > Of course, in both languages you can write unidiomatically, but that is a great way to ensure that bugs get in and never get out.
Why does "unidiomatic" have to imply "buggy" code? You're basically saying an unidiomatic approach is doomed to introduce bugs and will never reduce them.

It sounds weird. If I write Python code with minimal side effects like in Haskell, wouldn't it at least reduce the possibility of side-effect bugs even though it wasn't "Pythonic"?

AFAIK, nothing in the language standard mentions anything about "idiomatic" or "this is the only correct way to use X". The definition of "idiomatic X" is not as clear-cut and well-defined as you might think.

I agree there's a risk with an unidiomatic approach. Irresponsibly applying "cool new things" is a good way to destroy "readability" while gaining almost nothing.

Anyway, my point is that there's no single definition of "good" that covers everything, and "idiomatic" is just whatever convention a particular community is used to.

There's nothing wrong with applying an "unidiomatic" mindset like awareness of stack/heap alloc, CPU cache lines, SIMD, static/dynamic dispatch, etc in languages like Java, Python, or whatever.

There's nothing wrong either with borrowing ideas like (Haskell) functor, hierarchical namespaces, visibility modifiers, borrow checking, dynamic dispatch, etc in C.

Whether it's "good" or not is left as an exercise for the reader.

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

#134

Post by varjag »

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!

Some of the most famous C codebases (e.g. the Linux kernel) been using them for some time.

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

#135

Post by MathMonkeyMan »

acidx wrote: post #93
MathMonkeyMan wrote: post #92

Earlier quoted context omitted.

Unspecified, really? cppreference's [C documentation][1] says that it returns zero. The [OpenGroup][2] documentation doesn't specify a return value when the conversion can't be performed. This recent [draft][3] of the ISO standard for C says that if the value cannot be represented (does that mean over/underflow, bad parse, both, neither?), then it's undefined behavior. So three references give three different answers…

The Linux man page ( https://man7.org/linux/man-pages/man3/atoi.3.html#VERSIONS ) says that POSIX.1 leaves it unspecified. As you found out, it's really something that should be avoided as much as possible, because pretty much everywhere disagrees how it should behave, especially if you value portability. sscanf() is not a good replacement either! It's better to use strtol() instead. Either do what Lwan does ( https:…

If your use case can have C++, then [std::from_chars][1] is ideal. Here's gcc's [implementation][2]; a lot of it seems to be handling different bases.

[1]: https://en.cppreference.com/w/cpp/utility/from_chars.html

[2]: https://github.com/gcc-mirror/gcc/blob/461fa63908b5bb1a44f12...

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

#136

Post by zweifuss »

AdieuToLogic wrote: post #101
uyzstvqs wrote: post #84

Earlier quoted context omitted.

It's a double-sided coin. LLMs are probably the best way to learn programming languages right now. But if you vibecode in a programming language that you don't understand, it's going to be a disaster sooner or later. This is also the reason why AI will not replace any actual jobs with merit.

> LLMs are probably the best way to learn programming languages right now. Books still exist, be they in print or electronic form.

I would claim that:

(interactive labs + quizzes) > Learning from books

Good online documentation > 5yr old tome on bookshelf

chat/search with ai > CTRL+F in a PDF manual

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

#137

Post by uecker »

jacquesm wrote: post #49
uecker wrote: post #24

Earlier quoted context omitted.

Compared to other languages, this is still nice.

It is - like everything else - nice because you, me and lots of others are used to it. But I remember starting out with C and thinking 'holy crap, this is ugly'. After 40+ years looking at a particular language it no longer looks ugly simply because of familiarity. But to a newcomer C would still look quite strange and intimidating. And this goes for almost all programming languages. Each and every one of them has wa…

I agree that the first reaction usually is only about what one is used to. I have seen this many times. Still, of course, not all syntax is equally good.

For example, the problem with Vec> for a 2D array is not that one is not used to it, but that the syntax is just badly designed. Not that C would not have problematic syntax, but I still think it is fairly good in comparison.

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

#138

Post by uecker »

lelanthran wrote: post #122
uecker wrote: post #20

Earlier quoted context omitted.

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,…

If you want something fool-proof where a statistical code generated will not generate issues, then C is certainly not a good choice. But also for other languages this will cause issues. I think for vibe-coding a network server you might want something sand-boxed with all security boundaries outside, in which case it does not really matter anymore.

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

#139

Post by uecker »

OneLessThing wrote: post #23
uecker wrote: post #20

Earlier quoted context omitted.

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.

This is why I love C. You can build these guard rails at exactly the right level for you. You can build them all the way up to CPython and do garbage collection and constant bounds checking. Or keep them at just raw pointer math. And everywhere in between. I like your approach. The downside being that there are probably 100,000+ bespoke implementations of similar guard rails where python users for example all get the…

I think the C standard should provide some good libraries, e.g. a string library. But in any case the problem with 100000+ bespoke implementations in C is not fixed by designing new programming languages and also adding them to the mix. Entropy is a bitch.

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

#140

Post by uecker »

lelanthran wrote: post #67
uecker wrote: post #22

Earlier quoted context omitted.

I prefer C to Zig. IMHO all the successor languages throw out the baby with the bathwater and add unnecessary complexity. But Zig is much better than Rust, but, still, I would never use it for a serious project. The "promoting unexpectedly" is something I do not think happens if you know C well. At least, I can't remember ever having a bug because of this. In most cases the promotion prevents you from having a bug, b…

> Recently I saw somebody "upgrading" a C code basis to C++ and also changing all loop variables to size_t. This caused a bug which he blamed on working on the "legacy C code" he is working on, although the original code was just fine. I had the same experience about 10 years back when a colleague "upgrade" code from using size_t to `int`; on that platform (ATMEGA or XMEGA, not too sure now) `int` was too small, over…

I don't think this is the only takeway. My point is that you can reliably identify signed integer overflow using sanitizers and you can also reliably mitigate related attacks by trapping for signed integer overflow (it still may be a DoS, but you can stop more serious harm). Both does not work with unsigned types except in a tightly controlled project where you treat unsigned wraparound as a bug, but this fails the moment you introduce other idiomatic C code that does not follow this.
Post reply on HN