3 ms·

The blog post says that this bug is inside code written in C and Ragel (a parser generator), Rust seems not to be involved in this bug

by sligor 8y ago

tptacek 8y ago
That's the point; Rust operates in the places they needed C before, and C is unsafe.
- pjmlp 8y ago
  There is a huge difference between being able to track down unsafe statements and a language where 100% of the source code is unsafe, given the 200+ cases of UB, implicit conversions and lack of data integrity validations. Sure logic errors can always happen, but moving away from C would already get a portion of memory corruption issues out of the table. Unless you are asserting that Mesa/Cedar, NEWP, Oberon, Oberon-07, Active Oberon, Modula-2, Modula-2+, Modula-3, Object Pascal, Concurrent Pascal, Component Pascal, Basic, D, Ada, SPARK, Sing#, Midori, BLISS, PL/I, PL/S, PL/8, PL/M, Swift, HPC# are all unsafe as C.
masklinn 8y ago
The slide is a bit unclear, the whole deck is terse and clearly not intended to be consumed independently from the presentation, so "Safe (we had a bug once…)" should be interpreted as "safe (we kind-of had a not-very-small bug in our C code once)" not "Safe (we've only had one Rust bug)"
- steven_pack 8y ago
  Indeed. It was very much just prepared as some talking points for the folks in the room. Makes more sense with the video. Note to self: Stuff about Rust always makes it to HN. :)
buro9 8y ago
Rust was not the cause of the bug. It was a C bug and was exposed during the process of deleting the code in question (adding the new code to replace it actually exposed the old bug). It has given us a very keen awareness of just how bad such bugs can be, and hence "we had a bug once" might be considered the soft way of saying "no more effing C". Of course we'll still have C and C++ as we're heavily invested, but if there are safer alternatives that we can use those will definitely be considered first.
- thurston 8y ago
  What rarely gets discussed in this case was that old, working code was modified in a critical way in order to accommodate new code when that didn't need to be done at all. It was actually a failure in the software development process.

The blog post says that this bug is inside code written in C and Ragel (a parser generator), Rust seems not to be involved in this bug

by sligor 8y ago

The blog post says that this bug is inside code written in C and Ragel (a parser generator), Rust seems not to be involved in this bug

tptacek 8y ago

That's the point; Rust operates in the places they needed C before, and C is unsafe.

pjmlp 8y ago
There is a huge difference between being able to track down unsafe statements and a language where 100% of the source code is unsafe, given the 200+ cases of UB, implicit conversions and lack of data integrity validations. Sure logic errors can always happen, but moving away from C would already get a portion of memory corruption issues out of the table. Unless you are asserting that Mesa/Cedar, NEWP, Oberon, Oberon-07, Active Oberon, Modula-2, Modula-2+, Modula-3, Object Pascal, Concurrent Pascal, Component Pascal, Basic, D, Ada, SPARK, Sing#, Midori, BLISS, PL/I, PL/S, PL/8, PL/M, Swift, HPC# are all unsafe as C.

masklinn 8y ago

The slide is a bit unclear, the whole deck is terse and clearly not intended to be consumed independently from the presentation, so "Safe (we had a bug once…)" should be interpreted as "safe (we kind-of had a not-very-small bug in our C code once)" not "Safe (we've only had one Rust bug)"

steven_pack 8y ago
Indeed. It was very much just prepared as some talking points for the folks in the room. Makes more sense with the video. Note to self: Stuff about Rust always makes it to HN. :)

buro9 8y ago

Rust was not the cause of the bug. It was a C bug and was exposed during the process of deleting the code in question (adding the new code to replace it actually exposed the old bug). It has given us a very keen awareness of just how bad such bugs can be, and hence "we had a bug once" might be considered the soft way of saying "no more effing C". Of course we'll still have C and C++ as we're heavily invested, but if there are safer alternatives that we can use those will definitely be considered first.

thurston 8y ago
What rarely gets discussed in this case was that old, working code was modified in a critical way in order to accommodate new code when that didn't need to be done at all. It was actually a failure in the software development process.