181–190 of 218 posts
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
While the classic "Parse, don’t validate"[0] paper uses Haskell instead of C as its illustrative programming language, the approach detailed is very much applicable in these scenarios. 0 - https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
> While the classic "Parse, don’t validate"[0] paper uses Haskell instead of C as its illustrative programming language, the approach detailed is very much applicable in these scenarios. Good thing someone (i.e. me ) took the time to demonstrate PdV in C: https://www.lelanthran.com/chap13/content.html
Earlier quoted context omitted.
Yes but how? After the overflow they still have to know the address of the next call site and the server would be in a UB state.
The code is on github. Figure out a way to get a shell through that code and you're hosed if someone recognizes it in active use.
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!
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.
Earlier quoted context omitted.
> 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 negati…
Earlier quoted context omitted.
Of course. You can do it in a single pass/just parse the token stream. There are various implementations like: https://zserge.com/jsmn/
It requires manual allocation of an array of tokens. So it needs a backing "stack vector" of sorts. And what about escapes?
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…
The answer to that though is probably more something like Zig than something like Rust.
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…
unsigned is easier: 'if(index >= max)' and has fewer edge cases because you don't need to worry about undefined behavior when computing index.
Earlier quoted context omitted.
> Could a determined hacker get to your server without even knowing what weird software you cooked up and how to exploit your binary? Yes.
Yes but how? After the overflow they still have to know the address of the next call site and the server would be in a UB state.
There are lots of ways the server could leak information about its internal state, and exploits have absolutely been implemented in the past based only on what was visible remotely.
Earlier quoted context omitted.
> Good C code will try to avoid allocations as much as possible in the first place. I've upvoted you, but I'm not so sure I agree though. Sure, each allocation imposes a new obligation to track that allocation, but on the downside, passing around already-allocated blocks imposes a new burden for each call to ensure that the callees have the correct permissions (modify it, reallocate it, free it, etc). If you're doing…
is there any system where doing the basics of http (everything up to framework handoff of structured data) are done outside of a single concurrency unit?