8 ms·

Turning off your computer is the only way to avoid bugs. All software has bugs.

pcwalton 10y ago
We aren't talking about eliminating all bugs. We're talking about eliminating memory safety problems, which frequently result in RCE.
- civility 10y ago
  What you were doing is advocating Rust in a C++ thread, again. Safety first, and all that. Congratulations on getting voted to the top of this topic, but it's tiresome. Let's pretend C++ is a car. I get in my car, and I drive somewhere. Yes, there are hundreds of thousands of accidents per year, but really, most people get where they want to go, and we aren't all dead. I've had my share of fender benders, but no RCE has ever been exploited in 25 years of my C or C++ code. Let's pretend Rust is a car. Half the time I want to go somewhere, I can't even get out of the driveway before I stumble into a limitation of the language or the standard libraries. One time it's overly strict coherence rules that forbid me from doing something that shouldn't break coherence [1]. Some other time it's because the standard library doesn't have a trait for a commonly implemented method, so I can't write a generic function to call that method. Yet another time, I find out you really can't accomplish the task without writing unsafe code, so the compiler really wasn't going to protect me from myself anyways [2]. So yeah, Rust is saving me from car accidents because I don't even make it to the road much less my destination half the time. Do you drive wearing a 5 point harness and a helmet? Do you really think a true expert couldn't make a safe C++ regex library? -- [1] Honestly, I think you guys are screwed on that one. I suspect you're going to have to break backwards compatibility to really fix it, so I believe you'll leave it broken instead. [2] Outside of FFI calls, I have no idea what rules I'm supposed to respect in an unsafe block. I guess I just can't drive my Rust car to that neighborhood then. Very safe indeed.
  - dbaupp 10y ago
    > no RCE has ever been exploited in 25 years of my C or C++ code I'm genuinely curious about you say this with any sort of surety. Do you have any sort of, say, crash reporting from users' computer, or some other way to know if a problem occurred in the wild? (Not that these will actually detect a successful RCE, only failed ones.) Additionally, not being (known to be) exploited doesn't mean that much without more context, e.g. have malicious people/machines/fuzzers actually tried to find exploits in your code?
    - civility 10y ago
      > I'm genuinely curious [how] you say this with any sort of surety. Of all the things I said, is that really the only one you want to address? In the future, I'll try harder to qualify my statements with a "to the best of my knowledge" clause when replying to Rust core developers, but constantly adding caveats to every word I say is tedious. No, I'm not omniscient - I can't prove my software has never been exploited. I have some doubts whether your question is really all that sincere, but giving you the benefit of the doubt: For the last 15-20 years, my job-related software runs on networks which are effectively air-gapped. My users aren't shy about submitting bug reports, and they generally have my phone number. For what it's worth, truly "malicious users" run the risk of getting fired or facing a court-marshall. Anyone who runs my code already has a shell and a compiler on the machine. We give them the source. They frequently have sudo. It would be much simpler for them to just write a program and run it than inject it into my (hypothetical) buffer overflows. If they want to crash my software, they can simply kill -9 it (or not start it in the first place). Before that I worked for a few unsuccessful startups, and I wish my software had seen enough exposure to run the risk of being exploited. I've written Netscape plugins which I know were exploitable, but that code vanished along with the stock options before most people had gotten past dial-up connections. Maybe someone somewhere curses the day I was born, but they didn't send a bug report. Having said all of that, you probably think I'm in some rare position. However, it's a really big world, and you might be surprised how much sloppy C, C++, Fortran, and COBOL software is out there quietly getting the job done without the constant onslaught of black hats attacking it. We don't all write web browsers and servers. There are a lot of potentially profitable C++ targets in the finance industry, but somehow they survive. I'm not one of the people saying modern C++ solves all the problems. I'm keenly aware of many short comings in C++. The language sucks in a lot of ways, and I dread trying to explain the complexities to non computer science developers. Given all of that, I have been interested in Rust for reasons having nothing to do with safety. You have some great features, and I think you should advertise those. If you fixed the pain points in Rust instead of emphasizing the shortcomings in C++, I think you could win a lot more converts (and a lot of new developers who could grow your ecosystem outside of web clients and services).
  - pcwalton 10y ago
    > Do you really think a true expert couldn't make a safe C++ regex library? I do believe that a C++ regex library written in reasonable time using normal development practices will have memory safety problems in it. This is based on the real-world experience we have with C++ projects. > Yet another time, I find out you really can't accomplish the task without writing unsafe code, so the compiler really wasn't going to protect me from myself anyways [2]. If your project is 5% unsafe code and 95% safe code, that's a win due to isolating the trusted computing base. In fact, when you get down to it, this sort of setup describes all Rust projects, as the standard library has unsafe code. > [1] Honestly, I think you guys are screwed on that one. I suspect you're going to have to break backwards compatibility to really fix it, so I believe you'll leave it broken instead. I don't agree that it's broken. In order to "fix it", we'd either have to throw out generics in favor of C++/D-style templates or have Haskell-like overlapping instances link errors. Each of those options is unpalatable. You lose some expressiveness, sure, but writing newtype wrappers is not the end of the world. In general, I find issues with the expressiveness of generics are often overblown. Remember that people write all sorts of software in Go, which doesn't have generics at all, much less overlapping instances!
    - civility 10y ago
      > I do believe that a C++ regex library written in reasonable time using normal development practices will have memory safety problems in it. This is based on the real-world experience we have with C++ projects. Me too. I'm guessing the JavaScript RegExp types in Firefox and Chrome are pretty battle hardened at this point though. I submit those as existence proofs that it could be possible. However, I'm sure they've had their exploitable bugs along the way, and I would guess the code is now ugly. For what it's worth, I would never submit all of boost as a shining example of clean and modern C++. There are gems in there, but there is a lot of cruft too. I think the biggest benefits it has brought to the C++ world is as a testing ground for new ideas and as a compiler stress test. Some parts of boost are practically a fuzz test for finding the bugs in g++ and clang++. :-) > If your project is 5% unsafe code and 95% safe code, that's a win Unfortunately for me, it was the first 5%, and honestly I'd call it more like 20%. It was a weekend learning project, and all I wanted to do was create a freshman level data structure from scratch. I had already had other successes, so this seemed like a good next step, but it wasn't. The weekend passed, and what I really learned was to expect more pain the next time I want to write a low level data structure in Rust. > I don't agree that it's broken. I can't make you agree - we might be in opinion territory. It's certainly broken in my opinion. I have been following along in the various blog posts and forum discussions. It seems like some of your coworkers think the rules are overly restrictive, so broken or not, it looks like they're trying to fix it at least a little. Unfortunately, I don't think they're very concerned about my particular use cases (and maybe they shouldn't be). > In order to "fix it", we'd either have to throw out generics in favor of C++/D-style templates or have Haskell-like overlapping instances link errors. I don't think those are the only two options, but you might find the other options even more unpalatable. > In general, I find issues with the expressiveness of generics are often overblown. I think all this says is that you don't write very much of the kind of code which benefits from generics. You can dismiss my point of view, but some of us do use them a lot, and it's one of the driving reasons I use C++. Generics are a documented feature of Rust, but every time I try to use them I hit a wall and end up falling back on the (admittedly powerful) macro system. If I write a library, should I tell my users they need to invoke my macros for use with their types? This is exactly the use case for generics. (I suspect I need an obligatory smiley here to let you know it's still a friendly discussion :-) > Remember that people write all sorts of software in Go, which doesn't have generics at all People write all sorts of software in all sort of languages. That doesn't say much one way or the other. Go seems really nice in some ways. The learning curve looks small, so I don't think it would frustrate my coworkers like Rust would. However, if I tried to bring it to work I'd need some sort of code generator to avoid the multiple maintenance for functions that work on float32, float64, complex64, complex128 and so on. Maybe they'd consider adding a macro facility like the one in Rust to work around the deficiencies in the language. :-) Besides, Go has GC and some of our software already needs a lot of memory. The pause times might be getting pretty good, but I'm guessing the memory foot print would be at least twice what it is in C++. (I should measure that though.) > , much less overlapping instances! Disclosure: I don't really know what an "overlapping instance" means in this context. It might be possible we're talking about different deficiencies in Rust generics, and I just don't have the right vocabulary.

We aren't talking about eliminating all bugs. We're talking about eliminating memory safety problems, which frequently result in RCE.

civility 10y ago
What you were doing is advocating Rust in a C++ thread, again. Safety first, and all that. Congratulations on getting voted to the top of this topic, but it's tiresome. Let's pretend C++ is a car. I get in my car, and I drive somewhere. Yes, there are hundreds of thousands of accidents per year, but really, most people get where they want to go, and we aren't all dead. I've had my share of fender benders, but no RCE has ever been exploited in 25 years of my C or C++ code. Let's pretend Rust is a car. Half the time I want to go somewhere, I can't even get out of the driveway before I stumble into a limitation of the language or the standard libraries. One time it's overly strict coherence rules that forbid me from doing something that shouldn't break coherence [1]. Some other time it's because the standard library doesn't have a trait for a commonly implemented method, so I can't write a generic function to call that method. Yet another time, I find out you really can't accomplish the task without writing unsafe code, so the compiler really wasn't going to protect me from myself anyways [2]. So yeah, Rust is saving me from car accidents because I don't even make it to the road much less my destination half the time. Do you drive wearing a 5 point harness and a helmet? Do you really think a true expert couldn't make a safe C++ regex library? -- [1] Honestly, I think you guys are screwed on that one. I suspect you're going to have to break backwards compatibility to really fix it, so I believe you'll leave it broken instead. [2] Outside of FFI calls, I have no idea what rules I'm supposed to respect in an unsafe block. I guess I just can't drive my Rust car to that neighborhood then. Very safe indeed.
- dbaupp 10y ago
  > no RCE has ever been exploited in 25 years of my C or C++ code I'm genuinely curious about you say this with any sort of surety. Do you have any sort of, say, crash reporting from users' computer, or some other way to know if a problem occurred in the wild? (Not that these will actually detect a successful RCE, only failed ones.) Additionally, not being (known to be) exploited doesn't mean that much without more context, e.g. have malicious people/machines/fuzzers actually tried to find exploits in your code?
  - civility 10y ago
    > I'm genuinely curious [how] you say this with any sort of surety. Of all the things I said, is that really the only one you want to address? In the future, I'll try harder to qualify my statements with a "to the best of my knowledge" clause when replying to Rust core developers, but constantly adding caveats to every word I say is tedious. No, I'm not omniscient - I can't prove my software has never been exploited. I have some doubts whether your question is really all that sincere, but giving you the benefit of the doubt: For the last 15-20 years, my job-related software runs on networks which are effectively air-gapped. My users aren't shy about submitting bug reports, and they generally have my phone number. For what it's worth, truly "malicious users" run the risk of getting fired or facing a court-marshall. Anyone who runs my code already has a shell and a compiler on the machine. We give them the source. They frequently have sudo. It would be much simpler for them to just write a program and run it than inject it into my (hypothetical) buffer overflows. If they want to crash my software, they can simply kill -9 it (or not start it in the first place). Before that I worked for a few unsuccessful startups, and I wish my software had seen enough exposure to run the risk of being exploited. I've written Netscape plugins which I know were exploitable, but that code vanished along with the stock options before most people had gotten past dial-up connections. Maybe someone somewhere curses the day I was born, but they didn't send a bug report. Having said all of that, you probably think I'm in some rare position. However, it's a really big world, and you might be surprised how much sloppy C, C++, Fortran, and COBOL software is out there quietly getting the job done without the constant onslaught of black hats attacking it. We don't all write web browsers and servers. There are a lot of potentially profitable C++ targets in the finance industry, but somehow they survive. I'm not one of the people saying modern C++ solves all the problems. I'm keenly aware of many short comings in C++. The language sucks in a lot of ways, and I dread trying to explain the complexities to non computer science developers. Given all of that, I have been interested in Rust for reasons having nothing to do with safety. You have some great features, and I think you should advertise those. If you fixed the pain points in Rust instead of emphasizing the shortcomings in C++, I think you could win a lot more converts (and a lot of new developers who could grow your ecosystem outside of web clients and services).
- pcwalton 10y ago
  > Do you really think a true expert couldn't make a safe C++ regex library? I do believe that a C++ regex library written in reasonable time using normal development practices will have memory safety problems in it. This is based on the real-world experience we have with C++ projects. > Yet another time, I find out you really can't accomplish the task without writing unsafe code, so the compiler really wasn't going to protect me from myself anyways [2]. If your project is 5% unsafe code and 95% safe code, that's a win due to isolating the trusted computing base. In fact, when you get down to it, this sort of setup describes all Rust projects, as the standard library has unsafe code. > [1] Honestly, I think you guys are screwed on that one. I suspect you're going to have to break backwards compatibility to really fix it, so I believe you'll leave it broken instead. I don't agree that it's broken. In order to "fix it", we'd either have to throw out generics in favor of C++/D-style templates or have Haskell-like overlapping instances link errors. Each of those options is unpalatable. You lose some expressiveness, sure, but writing newtype wrappers is not the end of the world. In general, I find issues with the expressiveness of generics are often overblown. Remember that people write all sorts of software in Go, which doesn't have generics at all, much less overlapping instances!
  - civility 10y ago
    > I do believe that a C++ regex library written in reasonable time using normal development practices will have memory safety problems in it. This is based on the real-world experience we have with C++ projects. Me too. I'm guessing the JavaScript RegExp types in Firefox and Chrome are pretty battle hardened at this point though. I submit those as existence proofs that it could be possible. However, I'm sure they've had their exploitable bugs along the way, and I would guess the code is now ugly. For what it's worth, I would never submit all of boost as a shining example of clean and modern C++. There are gems in there, but there is a lot of cruft too. I think the biggest benefits it has brought to the C++ world is as a testing ground for new ideas and as a compiler stress test. Some parts of boost are practically a fuzz test for finding the bugs in g++ and clang++. :-) > If your project is 5% unsafe code and 95% safe code, that's a win Unfortunately for me, it was the first 5%, and honestly I'd call it more like 20%. It was a weekend learning project, and all I wanted to do was create a freshman level data structure from scratch. I had already had other successes, so this seemed like a good next step, but it wasn't. The weekend passed, and what I really learned was to expect more pain the next time I want to write a low level data structure in Rust. > I don't agree that it's broken. I can't make you agree - we might be in opinion territory. It's certainly broken in my opinion. I have been following along in the various blog posts and forum discussions. It seems like some of your coworkers think the rules are overly restrictive, so broken or not, it looks like they're trying to fix it at least a little. Unfortunately, I don't think they're very concerned about my particular use cases (and maybe they shouldn't be). > In order to "fix it", we'd either have to throw out generics in favor of C++/D-style templates or have Haskell-like overlapping instances link errors. I don't think those are the only two options, but you might find the other options even more unpalatable. > In general, I find issues with the expressiveness of generics are often overblown. I think all this says is that you don't write very much of the kind of code which benefits from generics. You can dismiss my point of view, but some of us do use them a lot, and it's one of the driving reasons I use C++. Generics are a documented feature of Rust, but every time I try to use them I hit a wall and end up falling back on the (admittedly powerful) macro system. If I write a library, should I tell my users they need to invoke my macros for use with their types? This is exactly the use case for generics. (I suspect I need an obligatory smiley here to let you know it's still a friendly discussion :-) > Remember that people write all sorts of software in Go, which doesn't have generics at all People write all sorts of software in all sort of languages. That doesn't say much one way or the other. Go seems really nice in some ways. The learning curve looks small, so I don't think it would frustrate my coworkers like Rust would. However, if I tried to bring it to work I'd need some sort of code generator to avoid the multiple maintenance for functions that work on float32, float64, complex64, complex128 and so on. Maybe they'd consider adding a macro facility like the one in Rust to work around the deficiencies in the language. :-) Besides, Go has GC and some of our software already needs a lot of memory. The pause times might be getting pretty good, but I'm guessing the memory foot print would be at least twice what it is in C++. (I should measure that though.) > , much less overlapping instances! Disclosure: I don't really know what an "overlapping instance" means in this context. It might be possible we're talking about different deficiencies in Rust generics, and I just don't have the right vocabulary.