Live data from Hacker News

Love C, hate C: Web framework memory problems

alew.is

141–150 of 218 posts

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

#141

Earlier quoted context omitted.

To reduce the amount of allocation instead of: struct parsed_data * = parse (...); struct process_data * = process (..., parsed_data); struct foo_data * = do_foo (..., process_data); you can do parse (...) { ... process (...); ... } process (...) { ... do_foo (...); ... } It sounds like violating separation of concerns at first, but it has the benefit, that you can easily do procession and parsing in parallel, and al…

How testable is this, though?

It might be a problem when you can't afford side-effects that you later throw away, but I haven't experienced that yet. The functions still have return codes, so you still can test, whether a correct input results in no error check being followed and that incorrect input results in an error check being triggered.

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

#142

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…

That mythical "Good C Code", which is known only to some people who I never met.

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

#143

Earlier quoted context omitted.

Most pre-2010 games had to. As a prior gamedev after that period I can confidently say that it is a relic of the past in most cases now. (Not like that I don't care, but I don't have to be that strict about allocations.)

Because why?

Virtual memory gets rid of a lot of fragmentation issues.

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

#144

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…

These abstractions were already common in enterprise C code decades before Java came to be, thanks to stuff like Yourdon Structured Method.

Using fixed size buffers doesn't fix out of bounds errors, and stack corruption caused by such bugs.

Naturally we all know good C programmers never make them. /s

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

#145
post #30

Earlier quoted context omitted.

I've had some fun reviewing some very old code I wrote (1980's) to see what it looked like to me after such a long time of gaining experience. It's not unlike what the OP did here, it reads cleanly but I can see many issues that escaped my attention at the time. I always compared C with a very fast car: you can take some corners on two wheels but if you make a habit of that you're going to end up in a wall somewhere.…

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…

Except any good chef or butcher knows that they should be wearing protective gloves when using sharp knifes.

> Cut-resistant gloves are an essential piece of safety equipment in any kitchen.

https://www.restaurantware.com/blogs/smallwares/how-to-choos...

Where are C's gloves?

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

#146

Earlier quoted context omitted.

So what do you propose to do?

I propose that we start taking the appropriate amount of professional responsibility. That includes being honest about the actual costs of software when you don’t YOLO the details. Zero UB is table stakes now - it didn’t use to be, but we don’t live in that world anymore. It’s totally fine to use C or whatever language for it, but you are absolutely kidding yourself if you think the cost is less than at least an orde…

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.

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

#147

Earlier quoted context omitted.

> I propose that we start taking the appropriate amount of professional responsibility. I agree. For me that means: software engineering should start taking the same attitude to writing software that structural engineers bring to the table when they talk about bridges, buildings and other structures that will have people's lives depending on them. I'm not sure how we're going to make rings out of bits but we need to…

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 games, they won't win every little micro benchmark, however for like 99% of commercial use cases, what they deliver is fast enough for project requirements in execution time, and hardware resources.

Now where they fail is in human perception and urban myths, of where they are suitable to be adopted.

Languages like Rust overcome this, with their type system approach to resource management, the naysayers have run out of excuses.

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

#148
post #13
post #4

Earlier quoted context omitted.

> What is interesting is that the apparent cleanliness of the code (it reads very well) is obscuring the fact that the quality is actually quite low. I think this is a general feature and one of the greatest advantages of C. It's simple, and it reads well. Modern C++ and Rust are just horrible to look at.

The safer the C code, the more horrible it starts looking though... e.g. my_func(char msg[static 1])

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.

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

#149

Earlier quoted context omitted.

> 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

Interactive labs can do a great job of teaching skills, but they fell short of teaching understanding. And at some point, it’s faster to read a book to learn, because there’s a reduced need for practice.

Hypertext is better than printed book format, but if you’re just starting with something you need a guide that provides a coherent overview. Also most online documentation are just bad.

Why ctrl+f? You can still have a table of contents and an index with pdf. And the pdf formats support link. And I’d prefer filtering/querying over generation because the latter is always tainted by my prompt. If I type `man unknown_function`, I will get an error, not a generated manual page.

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

#150
post #109
post #41

Earlier quoted context omitted.

Theoretically yes. Practically there is character escaping. That kills any non-allocation dreams. Moment you have "Hi \uxxxx isn't the UTF nice?" you will probably have to allocate. If source is read-only you have to allocate. If source is mutable you have to waste CPU to rewrite the string.

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.

Post reply on HN