You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is some reason to believe that generating larger program inputs increases the chances of finding interesting bugs. For example, the Rustlantis Rust compiler fuzzer generates large (> 1000 LOC) programs, and Cristian Cadar's recent tutorial suggested that compiler fuzzing benefits from large programs.
One reason larger programs could help is that if a bug arises from a combination of features, it is more likely that that combination is present in a larger program rather than a smaller one. While the cost to generating a large program is greater than a small program, the large program is often equivalent to many small ones, paying back that cost.
We propose to adjust Cedar's generators to have parameters that nudge it towards (much) bigger programs, and then to test those generators against the status quo to see if they improve things.
Describe alternatives you've considered
N/A
Additional context
No response
Is this something that you'd be interested in working on?
👋 I may be able to implement this feature request
⚠️ This feature might incur a breaking change
The text was updated successfully, but these errors were encountered:
Category
DRT generator(s)
Describe the feature you'd like to request
There is some reason to believe that generating larger program inputs increases the chances of finding interesting bugs. For example, the Rustlantis Rust compiler fuzzer generates large (> 1000 LOC) programs, and Cristian Cadar's recent tutorial suggested that compiler fuzzing benefits from large programs.
One reason larger programs could help is that if a bug arises from a combination of features, it is more likely that that combination is present in a larger program rather than a smaller one. While the cost to generating a large program is greater than a small program, the large program is often equivalent to many small ones, paying back that cost.
We propose to adjust Cedar's generators to have parameters that nudge it towards (much) bigger programs, and then to test those generators against the status quo to see if they improve things.
Describe alternatives you've considered
N/A
Additional context
No response
Is this something that you'd be interested in working on?
The text was updated successfully, but these errors were encountered: