3 ms·

>You don't automatically segfault if you exceed the bounds; instead you read arbitrary memory. GCC and clang both have sanitizers either built in or available

by ue_ 10y ago

>You don't automatically segfault if you exceed the bounds; instead you read arbitrary memory. GCC and clang both have sanitizers either built in or available for them. Sure, it's not default, but let's not act like there is no choice in C but to account for every OOB access while programming or to read memory you don't want to. Furthermore, I never said that compile time checks of variables are possible, but rather we could move to using dependent typing, or at least a way to judge whether a variable would work as a subscript based on the type of the array and variable. The Rust designers didn't do that. Instead they put in a feature common in the two most popular C compilers to "panic" at runtime instead of accessing memory. That's nothing. It's rubbish. And if you know to "catch" the panic, why don't you check the value of what you're subscripting with? Saying you can catch the panic is missing the point of unintentional OOB accesses, which is that they're unintentional. C is just as safe with regard to OOB accessing, and to be honest that's pretty poor in 2017.

jjnoakes 10y ago
> let's not act like there is no choice in C If you are using gcc or clang, you have more options. True. But not all C compilers give you those options. However, the point is moot, since I never said you can't catch these things in C; I said it wasn't the default. Which you agree with. > I never said that compile time checks of variables are possible, but rather we could move to using dependent typing You didn't say anything about dependent typing. You said "Rust is no better than C". And I'm pointing out that it is. Dependent typing may be even better in some cases; I'm not arguing otherwise. > Saying you can catch the panic is missing the point of unintentional OOB accesses, which is that they're unintentional. No one said you should catch the panic. You can use Vec::get() for example if you are using runtime-derived indices and want bounds checking in an ergonomic fashion. And saying a panic for unintentional OOB is the same as in C is not true, since you get a panic by default in Rust, and to get one in C, not only must you be using a specific compiler or two, you must have the sanitizers enabled for every source file in your program. Not "by default" by any stretch. > C is just as safe with regard to OOB accessing, and to be honest that's pretty poor in 2017. It is nowhere close, and saying it is is pretty poor in 2017 as well. And you are still ignoring pointers, references, lifetimes, threads, ... you know, the other things that also help Rust make "Safe by default" and C "dangerous by default".

by ue_ 10y ago

jjnoakes 10y ago

> let's not act like there is no choice in C If you are using gcc or clang, you have more options. True. But not all C compilers give you those options. However, the point is moot, since I never said you can't catch these things in C; I said it wasn't the default. Which you agree with. > I never said that compile time checks of variables are possible, but rather we could move to using dependent typing You didn't say anything about dependent typing. You said "Rust is no better than C". And I'm pointing out that it is. Dependent typing may be even better in some cases; I'm not arguing otherwise. > Saying you can catch the panic is missing the point of unintentional OOB accesses, which is that they're unintentional. No one said you should catch the panic. You can use Vec::get() for example if you are using runtime-derived indices and want bounds checking in an ergonomic fashion. And saying a panic for unintentional OOB is the same as in C is not true, since you get a panic by default in Rust, and to get one in C, not only must you be using a specific compiler or two, you must have the sanitizers enabled for every source file in your program. Not "by default" by any stretch. > C is just as safe with regard to OOB accessing, and to be honest that's pretty poor in 2017. It is nowhere close, and saying it is is pretty poor in 2017 as well. And you are still ignoring pointers, references, lifetimes, threads, ... you know, the other things that also help Rust make "Safe by default" and C "dangerous by default".