Skip to content
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

Exploit short circuiting in Boolean operators #226

Open
MattWindsor91 opened this issue Oct 18, 2020 · 2 comments
Open

Exploit short circuiting in Boolean operators #226

MattWindsor91 opened this issue Oct 18, 2020 · 2 comments
Labels
Area:Fuzzer Specifically affecting the program mutator Type:Enhancement New feature or request

Comments

@MattWindsor91
Copy link
Collaborator

The fuzzer's algebraic rules table captures rules such as x || true = true || x = true, which are useful for generating convoluted expressions with known final values. These are useful for making the compiler consider conditional atomic action evaluations, but one thing that we're missing is testing whether the compiler avoids evaluating side-effects of atomic actions altogether when those operators are short-circuited out.

For example, we could generate fun expressions such as:

int x = 4004;
if (x == 4004 || atomic_fetch_add(&y, 24) == 6) { foo; }

and, as far as I understand it, the short-circuiting semantics of || should kick in and cause y to be unmodified.

@MattWindsor91 MattWindsor91 added Type:Enhancement New feature or request Area:Fuzzer Specifically affecting the program mutator labels Oct 18, 2020
@johnwickerson
Copy link
Collaborator

Good idea!

@MattWindsor91
Copy link
Collaborator Author

There's already some code that distinguishes between short-circuiting and non-short-circuiting operators: https://github.com/MattWindsor91/act/blob/1f41f7e7ddb7883cdae53613b35727f6b19f221f/lib/fir_gen/src/expr.ml#L446-L469 but it currently delegates to Bool_values.quickcheck_generator, which is always careful to generate side-effect-free Boolean expressions. Ideally, the short-circuiting version should delegate to a broader generator that can generate side-effects (either in how it generates Booleans, or how it generates integers that it feeds to relational operators), but I'd have to think about how to do so in a way that doesn't either duplicate code or make that generator module even less readable than it currently is...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area:Fuzzer Specifically affecting the program mutator Type:Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants