Skip to content

restriction lint: subcondition side-effects #2215

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
xd009642 opened this issue Nov 7, 2017 · 5 comments
Open

restriction lint: subcondition side-effects #2215

xd009642 opened this issue Nov 7, 2017 · 5 comments
Labels
A-lint Area: New lints E-medium Call for participation: Medium difficulty level problem and requires some initial experience. L-correctness Lint: Belongs in the correctness lint group T-middle Type: Probably requires verifiying types

Comments

@xd009642
Copy link
Contributor

xd009642 commented Nov 7, 2017

So disclaimer, I'm not sure if this is a necessary lint (anyone with input see my rust forum post https://users.rust-lang.org/t/evaluation-order-of-boolean-subconditions/13748). But I have the feeling that boolean subcondition execution order is probably not guaranteed like in C and C++. Therefore, if a user had side-effects in a subcondition program behaviour could change significantly due to something like a changed optimisation flag.

Below is some code which should be warned against if this lint is necessary. If this is an issue I wouldn't mind implementing the lint to help out 😄

fn side_effect(i: &mut i32) -> bool {
    (*i) += 1;
    true
}

fn main() {
    let mut i  = 4;
    if false && side_effect(&mut i) {
        //Some code
    }
    println!("i is {}", i);
    if side_effect(&mut i) && false {
        //Some code
    }
    println!("i is {}", i);
}
@oli-obk
Copy link
Contributor

oli-obk commented Nov 8, 2017

Subconditions are ordered in c++, too and often this is required. E.g. foo.len() > 3 && foo[2] is guaranteed panic free.

@oli-obk
Copy link
Contributor

oli-obk commented Nov 8, 2017

For bit operations instead of short circuiting operations this makes sense though. I think we already have an issue for eval order unclearness

#1193

#277

@xd009642
Copy link
Contributor Author

xd009642 commented Nov 8, 2017

Fair enough, I guess this is the issue with spending the day job doing MISRA C you forget what is paranoia and what is language spec 😄 I'm happy closing this issue if you think there's nothing that needs doing

@oli-obk
Copy link
Contributor

oli-obk commented Nov 15, 2017

I guess this is the issue with spending the day job doing MISRA C you forget what is paranoia and what is language spec

It never hurts to be paranoid. Please bring in your experience with MISRA-C by scrutinizing Rust code! We can really use an experienced eye from mission critical software development.

We could have a restriction lint that disallows side-effects in boolean chains. I think this could often result in a gain in readability. What do you think?

@oli-obk oli-obk changed the title New subcondition side-effect lint restriction lint: subcondition side-effects Nov 15, 2017
@oli-obk oli-obk added L-correctness Lint: Belongs in the correctness lint group E-medium Call for participation: Medium difficulty level problem and requires some initial experience. A-lint Area: New lints T-middle Type: Probably requires verifiying types labels Nov 15, 2017
@xd009642
Copy link
Contributor Author

True true, when I have time I'll look over my copy of the MISRA standard and open an issue with warning lints related to MISRA violations/warnings. It's a good first step in getting the safety of rust onto things like automobiles etc 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: New lints E-medium Call for participation: Medium difficulty level problem and requires some initial experience. L-correctness Lint: Belongs in the correctness lint group T-middle Type: Probably requires verifiying types
Projects
None yet
Development

No branches or pull requests

2 participants