Live data from Hacker News

Love C, hate C: Web framework memory problems

alew.is

151–160 of 218 posts

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

#151

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 first validate the buffer, to know it contains valid JSON, and then you can work with pointers to beginings of individual syntactic parts of JSON, and have functions that decide what type of the current element is, or move to the next element, etc. Even string work (comparisons with other escaped or unescaped strings, etc.) can be done on escaped strings directly without unescaping them to a buffer first.

Ergonomically, it's pretty much the same as parsing the JSON into some AST first, and then working on the AST. And it can be much faster than dumb parsers that use malloc for individual AST elements.

You can even do JSON path queries on top of this, without allocations.

Eg. https://xff.cz/git/megatools/tree/lib/sjson.c

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

#152
post #127
post #94

Earlier quoted context omitted.

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.

Technically but I don’t think folks ever really bothered.

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

#153

Earlier quoted context omitted.

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

I don't see how arenas solve the problems.

You group things from the same context together, so you can free everything in a single call.

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

#154
post #116

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!

It's only Microsoft's fault to have not implemented it for decades in MSVC. They stayed at C89 forever.

I never understand the reason why Microsoft lagged so much behind on newer c standards adoption. Did their compiler infrastructure made it difficult to adopt newer standards flexible? Or they simply did not care?

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

#155

Earlier quoted context omitted.

Cost is a useful metric because it reflects a number of relevant things: Time to develop, effort to maintain - yes, but also people turnover, required expertise levels, satisfaction, and so on. Whether or not you like it, you have to care about cost if you want to make rational decisions. I'm not talking about assigning a Euro/Dollar/Yuan value to each hour spent on a project, but you need a rough idea about the size…

> Cost is a useful metric because it reflects a number of relevant things: Time to develop, effort to maintain - yes, but also people turnover, required expertise levels, satisfaction, and so on. Whether or not you like it, you have to care about cost if you want to make rational decisions. I'm not talking about assigning a Euro/Dollar/Yuan value to each hour spent on a project, but you need a rough idea about the si…

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 downplaying the consequences of things like UB.

Are you personally doing any of those things? I don't know, and I don't think I have accused you of that.

I'm not here to swoon you by sweet-talking you into using a different programming language. All this "show don't tell" - what are you talking about? Do you need real-world examples of successful Rust projects? There's a myriad of impressive ones, but you are fully capable of googling that.

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.

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

#156

Earlier quoted context omitted.

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…

CVE are important but there’s also a lot of theatre there. How many are known exploitable? Most aren’t if you follow threat intel. Most of the Internet infrastructure is running c/c++ and is very safe.

It's fine to have a sober view of the severity, but we can hopefully agree in general that writing any program in C or C++ that faces the internet requires extreme caution.

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

#157
post #147

Earlier quoted context omitted.

Cost is a useful metric because it reflects a number of relevant things: Time to develop, effort to maintain - yes, but also people turnover, required expertise levels, satisfaction, and so on. Whether or not you like it, you have to care about cost if you want to make rational decisions. I'm not talking about assigning a Euro/Dollar/Yuan value to each hour spent on a project, but you need a rough idea about the size…

> The point here is that, until Rust came along, you had the choice between wildly risky (but fast) C and C++ code, or completely safe (but slow) garbage collected languages with heavy runtimes and significant deployment challenges. Not really, I have been mostly coding in managed languages for the last couple of decades, and this has been not really true for quite some time. Yes if we go down language benchmark game…

I think you are pointing out that garbage collected languages can be very fast, right? I agree about that, but it does fundamentally comes with some very big caveats.

There's a huge number of use cases that are perfectly served by GC languages, even where performance matters, but there's also a huge number that benefit from the extra boost and significantly lower memory usage of a compiled language.

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

#158
post #147

Earlier quoted context omitted.

> The point here is that, until Rust came along, you had the choice between wildly risky (but fast) C and C++ code, or completely safe (but slow) garbage collected languages with heavy runtimes and significant deployment challenges. Not really, I have been mostly coding in managed languages for the last couple of decades, and this has been not really true for quite some time. Yes if we go down language benchmark game…

I think you are pointing out that garbage collected languages can be very fast, right? I agree about that, but it does fundamentally comes with some very big caveats. There's a huge number of use cases that are perfectly served by GC languages, even where performance matters, but there's also a huge number that benefit from the extra boost and significantly lower memory usage of a compiled language.

There are plenty of compiled languages with GC, value types and low level programming capabilities, including playing with pointers C style.

D, C#, Nim, Swift, Go for mainstream examples.

If we dive into less successful attempts from the past,

Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Oberon-07, Spec#, System C# among plenty others that are probably listed on ACM SIGPLAN list of papers.

As for some commercial examples,

https://www.withsecure.com/en/solutions/innovative-security-...

https://dlang.org/blog/2018/12/04/interview-liran-zvibel-of-...

https://www.wildernesslabs.co/

https://www.astrobe.com/boards.htm

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

#159
post #116

Earlier quoted context omitted.

It's only Microsoft's fault to have not implemented it for decades in MSVC. They stayed at C89 forever.

I never understand the reason why Microsoft lagged so much behind on newer c standards adoption. Did their compiler infrastructure made it difficult to adopt newer standards flexible? Or they simply did not care?

They focused on C++ only. Management, not their devs.

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

#160

Earlier quoted context omitted.

Yup, unsigned math is just nasty. Actually, unchecked math on an integer is going to be bad regardless of whether it's signed or unsigned. The difference is that with signed integers, your sanity check is simple and always the same and requires no thought for edge cases: `if(index max)`. Plus ubsan, as mentioned above. My policy is: Always use signed, unless you have a specific reason to use unsigned (such as memory…

> The difference is that with signed integers, your sanity check is simple and always the same and requires no thought for edge cases: `if(index max)` Wait, what? How is that easier than `if (index > max)`?

Because if max is a calculated value, it could silently wrap around and leave index to cause a buffer overflow.

Or if index is counting down, a calculated index could silently wrap around and cause the same issue.

And if both are calculated and wrap around, you'll have fun debugging spooky action at a distance!

If both are signed, that won't happen. You probably do have a bug if max or index is calculated to a negative value, but it's likely not an exploitable one.

Post reply on HN