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

211–218 of 218 posts

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

#211

Post by AdieuToLogic »

estimator7292 wrote: post #166
AdieuToLogic wrote: post #101

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.

Examples are the best documentation, and we now have a machine to produce infinite examples tailored specifically to any situation

> Examples are the best documentation ...

No they are not, as examples lack explanation of the concepts underlying a programming language's definition.

> ... and we now have a machine to produce infinite examples tailored specifically to any situation

This is like saying, "to learn X language, just read a bunch of source in GitHub repositories that use it."

What books written by authoritative people provide, such as language designers or recognized luminaries, is conveyance of key linguistic concepts and an explanation of "the why" they are important. This is the sole purvey of people.

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

#212

Post by AdieuToLogic »

zweifuss wrote: post #136
AdieuToLogic wrote: post #101

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

Most of what you claim as being better does not address how people can discover concepts of which they are previously aware. To wit:

  One cannot complete "labs + quizzes" unless they know
  how to answer same.

  One cannot "Ctrl-F in a PDF manual" unless they know
  what to search for.
As to online docs being better than a printed "5yr old tome on bookshelf", that depends on if the available online documentation subsumes the book. If it does, awesome, but if it doesn't, then there very likely are things to learn within reach of said bookshelf.

EDIT:

An exemplar to consider is how the Actor Model[0] can be used to define a FaaS[1]-based system. Without being aware of this paper, it is unrealistic to expect someone to be able to formulate LLM prompts incorporating concepts identified by same.

Side note: the Actor Model[0] paper is far older than a "5yr old tome" and is very much applicable to this day.

0 - https://dspace.mit.edu/bitstream/handle/1721.1/41962/AI_WP_1...

1 - https://en.wikipedia.org/wiki/Function_as_a_service

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

#213

Post by noobermin »

kazinator wrote: post #115

I definitely don't love C that does atoi on a Content-Length value that came from the network and passes that to malloc. Even before we get to how a malicious would interact with malloc, there is this: > The functions atof, atoi, atol, and atoll are not required to affect the value of the integer expression errno on an error. If the value of the result cannot be represented, the behavior is undefined. [ISO C N3220 dr…

This seems more like a coding problem than a C problem. Most people would at least validate input before allocating anything.

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

#214

Post by 1718627440 »

kazinator wrote: post #115

I definitely don't love C that does atoi on a Content-Length value that came from the network and passes that to malloc. Even before we get to how a malicious would interact with malloc, there is this: > The functions atof, atoi, atol, and atoll are not required to affect the value of the integer expression errno on an error. If the value of the result cannot be represented, the behavior is undefined. [ISO C N3220 dr…

> But why would they when it's fewer keystrokes to use -1, which will go to 4294967295 on a 32 bit malloc, while scaling to 18446744073709551615 on 64 bit?

If that user wants to exploit your application it's better not to pass such a high value, since malloc typically detects size > SIZE_MAX/2. But then this code also doesn't check for malloc to return NULL, so this might also what leads to an exploit.

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

#215

Post by kcexn »

LexiMax wrote: post #86
lelanthran wrote: post #62

Earlier quoted context omitted.

> I believe that the fanatics in the rust community were the biggest factor. I second this; for a few years it was impossible to have any sort of discussion on various programming places when the topic was C: the conversation would get quickly derailed with accusations of "dinosaur", etc. Things have gone quiet recently (last three years, though) and there have been much fewer derailments.

As an outsider, I don't really see Rust having done anything different recently than they weren't doing from the start. What seems to have changed in recent years is the buy-in from corporations that seemingly see value in its promises of safety. This seems to be paired with a general pulling back of corporate support from the C++ world as well as a general recession of fresh faces, a change that at least from the si…

I'm not sure that there is a recession of corporate support from C++. Just that the proportion of companies that need C++ is smaller than it once was.

I like the safety promise of Rust. But the complicated interop story with C and C++ hurt it a lot. I mean, in a typical codebase, what proportion of bugs will be memory-safety related vs other reasons? Ideally, we could just wrap the safety-critical bits in a memory-safe wrapper and continue to use C and C++ for everything else.

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

#216

Post by wfn »

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…

Agree re: no need for heap allocation - for others: I recommend reading thru whole masscan source (https://github.com/robertdavidgraham/masscan), it's a pleasure btw - iirc rather few/sparse malloc()s which are part of regular I/O processing flow (there will be malloc()s which depending on config etc. set up additional data structs but as part of setup).

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

#217

Post by kazinator »

noobermin wrote: post #213
kazinator wrote: post #115

I definitely don't love C that does atoi on a Content-Length value that came from the network and passes that to malloc. Even before we get to how a malicious would interact with malloc, there is this: > The functions atof, atoi, atol, and atoll are not required to affect the value of the integer expression errno on an error. If the value of the result cannot be represented, the behavior is undefined. [ISO C N3220 dr…

This seems more like a coding problem than a C problem. Most people would at least validate input before allocating anything.

A HTTP request processing layer would typically have some configuration of the maximum content size that can be received in one request and reject anything larger.

That's why, e.g., you have to mess with a "php.ini" file to get your self-hosted webmail to handle large attachments (which are uploads from the browser UI to the back-end).

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

#218

Post by citbl »

moefh wrote: post #61
citbl wrote: post #13

Earlier quoted context omitted.

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

I don't understand why people think this is safer, it's the complete opposite. With that `char msg[static 1]` you're telling the compiler that `msg` can't possibly be NULL, which means it will optimize away any NULL check you put in the function. But it will still happily call it with a pointer that could be NULL, with no warnings whatsoever. The end result is that with an "unsafe" `char *msg`, you can at least handl…

Thanks I didn't know about this. I just read some article and took it for granted.
Post reply on HN