Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a simple shell in C – Part 3

blog.ehoneahobed.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Building a simple shell in C – Part 3

#41

Post by bitwize »

mk89 wrote: post #30
unsafecast wrote: post #4

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…

> 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.

No, it's a way to eliminate THE MOST COMMON CLASS OF SECURITY BUG. Boom, gone, because you used safe Rust instead of C.

It doesn't mean you won't discover other bugs -- you will. But those bugs might have lurked undiscovered because you were too busy fighting buffer overflows and UAFs. Any given team of engineers has only so much time and energy; with fewer bug types to eliminate, the same team can get closer to bug-free.

This is why the My Little Pony character alter of your average 25-year-old trans furry plural system wearing uwu kawaii programming socks, working in Rust, can code circles around even the most jaded C grognard with decades of experience -- and will be writing an OS kernel or driver near you.

> I don't know. I do see the value Rust and Go create, but if we follow good software practices in C, don't you think we could ship decent safe software there too? Or are all C programs inherently buggy by default?

All C programs but the most trivial are inherently buggy by default. As I put it, C is unsafe at any speed. Theoretically, it should be possible to establish sound disciplines and best practices to ensure safe C code, but experience has taught us that C is so full of potholes and footguns that it is practically impossible to write safe C even for experienced developers.

Re: Building a simple shell in C – Part 3

#42

Post by chubot »

FartyMcFarter wrote: post #33
chubot wrote: post #28

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".

Parser generators aren't widely used for implementing shells (or JavaScript engines, or C/C++ compilers, for that matter). IMO they're nice for designing languages, but not necessarily implementing them.

bash is actually one of the only shells that uses yacc, and the maintainer regards it as a mistake. It uses yacc for maybe 1/4 of the language and the rest is all hand written stuff intertwined with generated code. It's pretty messy.

See http://www.aosabook.org/en/bash.html

and e.g. https://www.oilshell.org/blog/2016/10/13.html

Re: Building a simple shell in C – Part 3

#44

Post by ilyash »

chubot wrote: post #42
FartyMcFarter wrote: post #33

Earlier quoted context omitted.

Wouldn't most projects use a parser generator anyway? Making the choice of language separate from "what's the best language for parsing stuff".

Parser generators aren't widely used for implementing shells (or JavaScript engines, or C/C++ compilers, for that matter). IMO they're nice for designing languages, but not necessarily implementing them. bash is actually one of the only shells that uses yacc, and the maintainer regards it as a mistake. It uses yacc for maybe 1/4 of the language and the rest is all hand written stuff intertwined with generated code. I…

I might have issues later. For now, in Next Generation Shell peg/leg parser is doing fine (with limited scripting around to avoid repetition).

https://piumarta.com/software/peg/

https://github.com/ngs-lang/ngs/blob/bdfb2fd70162cd7183ac8d4...

Re: Building a simple shell in C – Part 3

#45

Post by cassepipe »

chubot wrote: post #28
cassepipe wrote: post #12

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…

I actually took inspiration from https://www.oilshell.org/blog/2016/10/19.html#toc_1 when I implemented the tokenizer. Really liked the idea.

Re: Building a simple shell in C – Part 3

#46

Post by unsafecast »

quotemstr wrote: post #8
unsafecast wrote: post #4

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…

> Now take a singleplayer game, or a text editor. It's not a security risk if these crash, so do you need the safety Any program that operates on untrusted data can be a security vulnerability. If an attacker can make your text editor execute arbitrary code if you open a specially crafted file, that's a major security problem. Why would you create the risk of this sort of problem on purpose when we have adequate safe…

Not if the entire editor is untrusted. This is the job of the operating systems, and simple mechanisms like pledge and unveil can solve most of this.

Re: Building a simple shell in C – Part 3

#47

Post by unsafecast »

swinglock wrote: post #24
quotemstr wrote: post #8

Earlier quoted context omitted.

> Now take a singleplayer game, or a text editor. It's not a security risk if these crash, so do you need the safety Any program that operates on untrusted data can be a security vulnerability. If an attacker can make your text editor execute arbitrary code if you open a specially crafted file, that's a major security problem. Why would you create the risk of this sort of problem on purpose when we have adequate safe…

Even an offline game is dangerous. What if the save files are backed up and that storage is compromised? This allows an attacker to escalate access from one computer or service to others.

These are issues for the operating system to care about, not every single application. With pledge and unveil (or similar), you can solve most of this once.
Post reply on HN