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

171–180 of 218 posts

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

#171

Post by lelanthran »

lock1 wrote: post #133
lelanthran wrote: post #55

Earlier quoted context omitted.

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

> Why does "unidiomatic" have to imply "buggy" code?

Because when you stray from idioms you're going off down unfamiliar paths. All languages have better support for specific idioms. Trying to pound a square peg into a round hole can work, but is unlikely to work well.

> You're basically saying an unidiomatic approach is doomed to introduce bugs and will never reduce them.

Well, yes. Who's going to reduce them? Where are you planning to find people who are used to code written in an unusual manner?

By definition alone, code is written for humans to read. If you're writing it in a way that's difficult for humans to read, then of course the bug level can only go up and not down.

> 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"?

"Pythonic" does not mean the same thing as "Idiomatic code in Python".

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

#172

Post by jacquesm »

nurettin wrote: post #131
frumplestlatz wrote: post #126

Earlier quoted context omitted.

> 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.

The code is on github. Figure out a way to get a shell through that code and you're hosed if someone recognizes it in active use.

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

#173

Post by codr7 »

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.

In C, direct memory control is the top feature, which means you can assume anyone who uses your code is going to want to control memory through the process. This means not allocating from wherever and returning blobs of memory, which means designing different APIs, which is part of the reason why learning C well takes so long.

I started writing sort of a style guide to C a while ago, which attempts to transfer ideas like this one more by example:

https://github.com/codr7/hacktical-c

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

#174

Post by pjmlp »

jacquesm wrote: post #169
pjmlp wrote: post #148

Earlier quoted context omitted.

Meanwhile, in Modula-2 from 1978, that would be PROCEDURE my_func(msg: ARRAY OF CHAR); Now you can use LOW() and HIGH() to get the lower and upper bounds, and naturally bounds checked unless you disabled them, locally or globaly.

This should not be downvoted, it is both factually correct and a perfect illustration of these problems already being solved and ages ago at that. It is as if just pointing this out already antagonizes people.

A certain group of people likes to pretend before C there were no other systems programming languages, other than BCPL.

Ignoring what happened since 1958 (JOVIAL being a first attempt), and thus all its failings are excused because it was discovering the world.

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

#175

Post by lelanthran »

Ygg2 wrote: post #150
_3u10 wrote: post #109

Earlier quoted context omitted.

It’s just two pointers the current place to write and the current place to read, escapes are always more characters than they represent so there’s no danger of overwriting the read pointer. If you support compression this can become somewhat of and issue but you simply support a max block size which is usually defined by the compression algorithm anyway.

If you have a place to write, then it's not zero allocation. You did an allocation. And usually if you want maximum performance, buffered read is the way to go, which means you need a write slab allocation.

> If you have a place to write, then it's not zero allocation. You did an allocation.

Where did that allocation happen? You can write into the buffer you're reading from, because the replacement data is shorter than the original data.

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

#176

Post by uecker »

jacquesm wrote: post #170
uecker wrote: post #137

Earlier quoted context omitted.

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.

C has one massive advantage over many other languages: it is just a slight level above assembler and it is just about as minimal as a language can be. It doesn't force you into an eco-system, plays nice with lots of other tools and languages and gets out of the way. 'modern' languages, such as Java, Rust, Python, Javascript (Node) and so on all require you to buy in to the whole menu, they're not 'just a language' (e…

Not forcing you into an eco-system is what makes C special, unique and powerful, and this aspect is not well understood by most critics. Stephen Kell wrote a great essay about it.

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

#177

Post by jabits »

codr7 wrote: post #173
lelanthran wrote: post #55

Earlier quoted context omitted.

> 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.

In C, direct memory control is the top feature, which means you can assume anyone who uses your code is going to want to control memory through the process. This means not allocating from wherever and returning blobs of memory, which means designing different APIs, which is part of the reason why learning C well takes so long. I started writing sort of a style guide to C a while ago, which attempts to transfer ideas…

Thanks for sharing this work.

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

#178

Post by acidx »

01HNNWZ0MV43FF wrote: post #32
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…

Can you do parsing of JSON and XML without allocating?

Yes! The JSON library I wrote for the Zephyr RTOS does this. Say, for instance, you have the following struct:

    struct SomeStruct {
        char *some_string;
        int some_number;
    };
You would need to declare a descriptor, linking each field to how it's spelled in the JSON (e.g. the some_string member could be "some-string" in the JSON), the byte offset from the beginning of the struct where the field is (using the offsetof() macro), and the type.

The parser is then able to go through the JSON, and initialize the struct directly, as if you had reflection in the language. It'll validate the types as well. All this without having to allocate a node type, perform copies, or things like that.

This approach has its limitations, but it's pretty efficient -- and safe!

Someone wrote a nice blog post about (and even a video) it a while back: https://blog.golioth.io/how-to-parse-json-data-in-zephyr/

The opposite is true, too -- you can use the same descriptor to serialize a struct back to JSON.

I've been maintaining it outside Zephyr for a while, although with different constraints (I'm not using it for an embedded system where memory is golden): https://github.com/lpereira/lwan/blob/master/src/samples/tec...

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

#179

Post by pjmlp »

jacquesm wrote: post #164
pjmlp wrote: post #146

Earlier quoted context omitted.

Thankfully the new cybersecurity laws will help here, when companies map production costs to languages, the needle will keep moving away from those that tank security budgets.

I was actually hoping for far more strict enforcement but so far they're taking it relatively easy.

Indeed, however better slowly than nothing at all.

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

#180

Post by nxobject »

codr7 wrote: post #173
lelanthran wrote: post #55

Earlier quoted context omitted.

> 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.

In C, direct memory control is the top feature, which means you can assume anyone who uses your code is going to want to control memory through the process. This means not allocating from wherever and returning blobs of memory, which means designing different APIs, which is part of the reason why learning C well takes so long. I started writing sort of a style guide to C a while ago, which attempts to transfer ideas…

Echoing my sibling comment - thanks for sharing this.
Post reply on HN