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

31–40 of 218 posts

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

#31

Post by imtringued »

jacquesm wrote: post #10
messe wrote: post #6

Earlier quoted context omitted.

I slightly unironically believe that one of the biggest hindrances to rust's growth is that it adopted the :: syntax from C++ rather than just using a single . for namespacing.

I believe that the fanatics in the rust community were the biggest factor. They turned me off what eventually became a decent language. There are some language particulars that were strange choices, but I get that if you want to start over you will try to get it all right this time around. But where the Go authors tried to make the step easy and kept their ego out of it, it feels as if the rust people aimed at creati…

Software vulnerabilities are an implicit form of harassment.

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

#32

Post by 01HNNWZ0MV43FF »

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?

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

#33

Post by zdragnar »

nurettin wrote: post #27
jacquesm wrote: post #2

There are many, many more such issues with that code. The person that posted it is new to C and had an AI help them to write the code. That's a recipe for disaster, it means the OP does not actually understand what they wrote. It looks nice but it is full of footguns and even though it is a useful learning exercise it also is a great example of why it is better run battle tested frame works than to inexpertly roll yo…

> should never see production use. I have an issue with high strung opinions like this. I wrote plenty of crappy delphi code while learning the language that saw production use and made a living from it. Sure, it wasn't the best experience for users, it took years to iron out all the bugs and there was plenty of frustration during the support phase (mostly null pointer exceptions and db locks in gui). But nobody woul…

Buggy code that just crashes or produces incorrect results are a whole different category. In C a bug can compromise a server and your users. See the openssl heart bleed vulnerability as a prime example.

Once upon a time, you could put up a relatively vulnerable server, and unless you got a ton of traffic, there weren't too many things that would attack it. Nowadays, pretty much anything Internet facing will get a constant stream of probes. Putting up a server requires a stricter mindset than it used to.

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

#34

Post by messe »

imtringued wrote: post #31
jacquesm wrote: post #10

Earlier quoted context omitted.

I believe that the fanatics in the rust community were the biggest factor. They turned me off what eventually became a decent language. There are some language particulars that were strange choices, but I get that if you want to start over you will try to get it all right this time around. But where the Go authors tried to make the step easy and kept their ego out of it, it feels as if the rust people aimed at creati…

Software vulnerabilities are an implicit form of harassment.

I'm hoping that's meant to satirise the rust community, because it's horseshit like this that makes a sizeable subset of rust evangelists unbearable.

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

#35

Post by 01HNNWZ0MV43FF »

jacquesm wrote: post #10
messe wrote: post #6

Earlier quoted context omitted.

I slightly unironically believe that one of the biggest hindrances to rust's growth is that it adopted the :: syntax from C++ rather than just using a single . for namespacing.

I believe that the fanatics in the rust community were the biggest factor. They turned me off what eventually became a decent language. There are some language particulars that were strange choices, but I get that if you want to start over you will try to get it all right this time around. But where the Go authors tried to make the step easy and kept their ego out of it, it feels as if the rust people aimed at creati…

> I don't remember any other language's proponents actively attacking the users of other programming language.

I just saw someone on Hacker News saying that Rust was a bad language because of its users

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

#37

Post by bluetomcat »

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, you can do it with minimal allocations - provided that the source buffer is read-only or is mutable but is unused later directly by the caller. If the buffer is mutable, any un-escaping can be done in-place because the un-escaped string will always be shorter. All the substrings you want are already in the source buffer. You just need a growable array of pointer/length pairs to know where tokens start.

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

#38

Post by gritzko »

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?

Yep, no problem. In place parsing only requires a stack. Stack length is the maximum JSON nesting allowed. I have a C dialect exactly like that.

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

#39

Post by veqq »

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?

Of course. You can do it in a single pass/just parse the token stream. There are various implementations like: https://zserge.com/jsmn/

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

#40

Post by 01HNNWZ0MV43FF »

uecker wrote: post #8
messe wrote: post #5

> Another interesting choice in this project is to make lengths signed: There are good reasons for this choice in C (and C++) due to broken integer promotion and casting rules. See: "Subscripts and sizes should be signed" (Bjarne Stroustrup) https://open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1428r0... As a nice bonus, it means that ubsan traps on overflow (unsigned overflows just wrap).

I do not agree that the integer promotion or casting (?) rules are broken in C. That some people make mistakes because they do not know them is a different problem. The reason you should make length signed is that you can use the sanitizer to find or mitigate overflow as you correctly observe, while unsigned wraparound leads to bugs which are basically impossible to find. But this has nothing to do with integer promo…

> That some people make mistakes because they do not know them is a different problem.

We can argue til we're blue in the face that people should just not make any mistakes, but history is against us - People will always make mistakes.

That's why surgeons are supposed to follow checklists and count their sponges in and out

Post reply on HN