3 ms·
If you just grep, you'll get false-positives like // We don't need unsafe here or print!("This is NOT unsafe"); So you'd want a static analyzer anyway.
by jhasse 10y ago
If you just grep, you'll get false-positives like
// We don't need unsafe here
or
print!("This is NOT unsafe");
So you'd want a static analyzer anyway.
- lmm 10y agoPerhaps a "static analyzer" in some sense, but it would be a trivial one. It wouldn't have to do the sophisticated analysis necessary to tell whether someone is e.g. using a moved value in C++. C++ programmers love to claim that there's a simple set of rules that everyone can follow to write code that's just as safe as Rust, but somehow whenever you ask them to actually write down those rules it turns out they can't.
- pjmlp 10y agoSure, but that is what sed is for, removing comments. With Rust, or any other systems safe language for that matter, I can be assured that any code that violates the type system is contained in such blocks. In C or C++ written in C style, any string, vector, function call with out parameters, data structure manipulation can be hiding unsafe code. It is quite different just having to review some well defined sections than the whole program. However I do concede all of this fails flat when using third party binary libraries. I do enjoy using C++ since C++ARM days, already back then many of the modern C++ practices were possible after templates got added into the language, yet enterprise "C compiled with C++ compiler" code is the norm in many companies. Specially since many don't even bother to write type safe C++ wrappers and call C APIs directly.
- moosingin3space 10y ago> Specially since many don't even bother to write type safe C++ wrappers and call C APIs directly. Even though it's controversial, I think this is why it's a good thing Rust can't #include a C header directly (requiring bindgen to make a crate). The community has put work into making safe abstractions over the raw C.
- Nadya 10y agogrep /^unsafe(\s\{)|(\sfn)|(\strait)|(\simpl)/ Some variation of that, or four individual greps. I forgot how to use OR properly in Regex but each of those works individually. Tested on regex101 [0] against the following code: unsafe { // Scary stuff... } unsafe trait Scary { } unsafe impl Scary for i32 {} unsafe fn danger_will_robinson() { // Scary stuff... } That should catch all four instances that unsafe can be called in without any false positives. Since `fn`, `trait` and `impl` are keywords they won't change. Of course, any comments should be removed beforehand in case of a commented out unsafe block. [0] https://regex101.com/ https://regex101.com/
- deleted 10y ago[deleted]
- Nadya 10y agoCleaned it up and tested it as Unit Tests. `^unsafe(\s(\{|fn|trait|impl))` will match the four examples I gave but not match print or commented `unsafe`. I'm not sure if unsafe can be indented inside of a block but ignoring whitespace at the start of a line should fix it. I did this as a learning experience because I either regex101 doesn't properly implement /g or I don't understand capture groups. :D [0] http://i.imgur.com/zMSVo4A.png http://i.imgur.com/zMSVo4A.png