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

191–200 of 218 posts

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

#191

Post by fsckboy »

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…

>Good C code will try to avoid allocations as much as possible in the first place.

there's a genius to this: if you're going to optimize prematurely, do it right out of the gate!

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

#192

Post by Ygg2 »

lelanthran wrote: post #175
Ygg2 wrote: post #150

Earlier quoted context omitted.

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.

You have a read buffer and somewhere where you have to write to.

Even if we pretend that the read buffer is not allocating (plausible), you will have to allocate for the write source for the general case (think GiB or TiB of XML or JSON).

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

#193

Post by lelanthran »

Ygg2 wrote: post #192
lelanthran wrote: post #175

Earlier quoted context omitted.

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

You have a read buffer and somewhere where you have to write to. Even if we pretend that the read buffer is not allocating (plausible), you will have to allocate for the write source for the general case (think GiB or TiB of XML or JSON).

> You have a read buffer and somewhere where you have to write to.

The "somewhere you have to write to" is the same buffer you are reading from.

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

#195

Post by Ygg2 »

lelanthran wrote: post #193
Ygg2 wrote: post #192

Earlier quoted context omitted.

You have a read buffer and somewhere where you have to write to. Even if we pretend that the read buffer is not allocating (plausible), you will have to allocate for the write source for the general case (think GiB or TiB of XML or JSON).

> You have a read buffer and somewhere where you have to write to. The "somewhere you have to write to" is the same buffer you are reading from.

Not if you are doing buffered reads, where you replace slow file access with fast memory access. This buffer is cleared every X bytes processed.

Writing to it would be pointless because clears obliterate anything written; or inefficient because you are somehow offsetting clears, which would sabotage the buffered reading performance gains.

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

#196

Post by qalmakka »

OT: using the `strcasecmp` family of functions is basically asking for trouble - unless you've previously set the locale to "C", which is basically the only locale with a defined behaviour. Otherwise you're basically bound to run onto very funny internationalisation issues you'd rather know nothing about (and fail the Turkey Test)

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

#197

Post by simonask »

jacquesm wrote: post #167
simonask wrote: post #155

Earlier quoted context omitted.

I don't have time to respond to all of this, but let me just say that you seem to be under the impression that it is somehow my responsibility to "win you over" and convince you to use Rust. I have stated very clearly that that's not my point. My point is that we should all stop lying about the actual cost of delivering reliable software written in C or C++, and in particular that we as an industry need to stop downp…

> I'm not a representative of Rust the language (how could I be), and I reserve the right to call out moral corruption as I see it. I frankly do not need any "well-meaning" advice about how best to advocate for Rust - that's not my job. Whether you realize it or not, you are an advocate and you are doing a very, very poor job of it.

If you are making technical decisions based on how strangers on the internet make you feel, I fear there's not much I could have done anyway.

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

#198

Post by uecker »

simonask wrote: post #46
uecker wrote: post #30

Earlier quoted context omitted.

I think the correct comparison is a sharp knife. It is extremely useful and while there is a risk it is fully acceptable. The idea that we should all use plastic knifes because there are often accidents with knifes is wrong and so is the idea that we use should abandon C because of memory safety. I follow computer security issues for several decades, and while I think we should have memory safety IMHO the push and ar…

I’m sorry, but there is an incredible amount of hard data on this, including the number of CVEs directly attributable to memory safety bugs. This is publicly available information, and we as an industry should take it seriously. I don’t mean to be disrespectful, but this cavalier attitude towards it reads like vaccine skepticism to me. It is not serious. Programming can be inconsequential, but it can also be national…

Number of CVEs is completely irrelevant. Also Google's or Microsoft's priorities are completely irrelevant. If you have reliable data from the real world, please show it to me.

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

#199

Post by pjmlp »

hu3 wrote: post #90
LexiMax wrote: post #85

Earlier quoted context omitted.

Being a C++ developer and trafficking mostly in C++ spaces, there is a phenomenon I've noticed that I've taken to calling Rust Derangement Syndrome. It's where C and C++ developers basically make Rust the butt of every joke, and make fun it it in a way that is completely outsized with how much they interact with Rust developers in the wild. It's very strange to witness. Annoying advocacy of languages is nothing new.…

I don't think Rust will ever be as big as C++ because there were fewer options back then. These days Go/Zig/Nim/C#/Java/Python/JS and other languages are fast enough for most use cases. And Rust learning curve doesn't help either. C++ was basically C with OOP on steroids. Rust is very different. I say that because I wouldn't group Rust opposition with any of those languages you cited. It's different for mostly differ…

As someone that was there, a few things helped C++ adoption, and even then it wasn't without the C vs C++ flamewars that endure to these days.

- At the time, with a few minor differences, C++ was Typescript for C, thus very easy to adopt into existing projects

- Being born on the same birthplace as C and UNIX, meant all C compiler vendors saw as added value to have it as part of their offering, and it was natural that every UNIX SDK also had C++ support available alongside C.

- Apple, Metrowerks, IBM, Borland and Microsoft helped to push C++ adoption, by making it the official way to use application frameworks. MacApp (originally in Object Pascal), PowerPlant, CSet++, Turbo Vision/OWL/VCL, and MFC respectively.

This kept C++ as the language to go for performance in enterprise computing, while Delphi and VB got the "easy" development role, until Java and .NET took over all those frameworks.

Rust doesn't have this kind of industry wide push, even in OSes where it is being embraced like Windows and Android, note that it isn't being pushed as yet another way to write userspace applications, rather low level OS services.

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

#200

Post by DenisDolya »

int_19h wrote: post #187
uecker wrote: post #30

Earlier quoted context omitted.

I think the correct comparison is a sharp knife. It is extremely useful and while there is a risk it is fully acceptable. The idea that we should all use plastic knifes because there are often accidents with knifes is wrong and so is the idea that we use should abandon C because of memory safety. I follow computer security issues for several decades, and while I think we should have memory safety IMHO the push and ar…

The real problem with C is that it's not just a sharp knife, it's a knife with poor ergonomics that makes it more prone to cutting yourself. The answer to that though is probably more something like Zig than something like Rust.

Hi, are you interested in Zig? Then please check out my port of jsmn to Zig. I wanted to know if people will like it and if there are any downsides others might not. https://github.com/Ferki-git-creator/jsmn_zig
Post reply on HN