31–40 of 48 posts
Surprising to see this article. I am a CS student, and at the second year, in OS course in one the assigment, we are actually building Shell in C. Very simplistic one. Great to read.
Earlier quoted context omitted.
Yes. Some people (myself included) enjoy "unsafe" languages like C. I'm not one of those people that argue that being careful is enough. For applications where security really matters, _please_ use something with a bit more verification (though even that doesn't disqualify C, see seL4). Now take a singleplayer game, or a text editor. It's not a security risk if these crash, so do you need the safety? I'd argue it's u…
Yet OWASP vulnerabilities hit lots of non-C languages and things that you definitely don't do in C: https://owasp.org/Top10 I am starting to wonder lately if all this "implicit language security" (use Rust, use Go so you don't have memory errors, overflows, etc.) is not just some way to shift accountability to some other layer. I do understand that lower level languages require better programming skills because you a…
Does this mean that eliminating memory errors is not worth it? I don’t think so. In C you have both memory errors and business logic bugs. So it takes more effort to get C code right than Rust.
I have personally tried to build one in C but the parsing was the real pain, I managed to have a tokenizer, barely found how to make an AST and never figured out what to do with. All parsing tutorials are about parsing mathematical expressions, I found it hard to adapt to shell grammar.
Yes a huge part of shell is parsing, and C is a bad language for that. If you want POSIX shell you'll have at least 5K lines of parsing code; if you want bash it's at least 10K lines. It's closer to 20K lines of C in bash itself. There's really no way around that, and IMO the best answer is to use a different language -- which is ALSO hard, because many language runtimes don't support fork() or signals in the way tha…
Earlier quoted context omitted.
Yes a huge part of shell is parsing, and C is a bad language for that. If you want POSIX shell you'll have at least 5K lines of parsing code; if you want bash it's at least 10K lines. It's closer to 20K lines of C in bash itself. There's really no way around that, and IMO the best answer is to use a different language -- which is ALSO hard, because many language runtimes don't support fork() or signals in the way tha…
Wouldn't most projects use a parser generator anyway? Making the choice of language separate from "what's the best language for parsing stuff".
Earlier quoted context omitted.
> It's not possible for humans to write correct and secure C code on an ongoing and consistent basis. https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl... "Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows." "I understand that many people, particularly those already enamored with Rust, won’t agree with much of this article. B…
> "Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows." The problem is that when you write a program in C for the public , this program's buffer overflows and segfaults aren't a problem only for you , but also for everyone around you . Security vulnerabilities are a serious problem. You can think of them as a form of software pollution:…
Earlier quoted context omitted.
> It's not possible for humans to write correct and secure C code on an ongoing and consistent basis. https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl... "Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows." "I understand that many people, particularly those already enamored with Rust, won’t agree with much of this article. B…
> "Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows." The problem is that when you write a program in C for the public , this program's buffer overflows and segfaults aren't a problem only for you , but also for everyone around you . Security vulnerabilities are a serious problem. You can think of them as a form of software pollution:…
Surprising to see this article. I am a CS student, and at the second year, in OS course in one the assigment, we are actually building Shell in C. Very simplistic one. Great to read.
Oregon State by any chance? It was a super cool exercise. I'd like to revisit it someday without a time crunch and build another.
Earlier quoted context omitted.
It's not possible for humans to write correct and secure C code on an ongoing and consistent basis. Even when people pay careful attention, problems arise: consider the various 0days in sudo. C isn't simple: it's simplistic : its apparent simplicity comes from shifting the burden of safety from compilers to humans. Consequently, we spend trillions of dollars on dealing with the consequences of security vulnerabilitie…
> It's not possible for humans to write correct and secure C code on an ongoing and consistent basis. While the Rust definitely is way more helpful than C, when it comes to writing secure code. I'd argue that generally the following holds: It's not possible for humans to write correct and secure code on an ongoing and consistent basis.
This in my ears echoes the understanding that humans aren't fully rational creatures, we just convince ourselves we are most of the time. So it would follow that we wouldn't be able to write secure (i.e. rational in its own context) code consistently.
Earlier quoted context omitted.
> "Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows." The problem is that when you write a program in C for the public , this program's buffer overflows and segfaults aren't a problem only for you , but also for everyone around you . Security vulnerabilities are a serious problem. You can think of them as a form of software pollution:…
I'm reminded of the adage that the lower the stakes, the more seriously people take stuff. Using C is not remotely on par with asbestos, let's have little perspective.