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

use no_panic to prove the absence of panics in parser code #193

Open
daniel-noland opened this issue Jan 31, 2025 · 0 comments
Open

use no_panic to prove the absence of panics in parser code #193

daniel-noland opened this issue Jan 31, 2025 · 0 comments
Assignees
Labels
clean-up Code base clean-up, no functional change enhancement New feature or request

Comments

@daniel-noland
Copy link
Collaborator

The no_panic attribute macro is a very handy way to ensure that code which you think is sound really truly is.

Given that a fundamental rule of the parser is to never panic, even in the presence of outright malicious input, this tool seems very helpful.

How can this possibly work?

The full details can be found in the source code, but the TL;DR is that the no_panic macro checks that the compiler itself has optimized out any and all branches of the decorated function which could potentially panic.
This strategy is effective, but it has minor drawbacks as well.

  1. Code which is naively annotated no_panic will not compile in debug builds (or any build which is doing insufficient optimization to allow the compiler to elide the paths which might panic). You can work around this limitation by using #[cfg_attr(not(debug_assertions), no_panic)] instead of just #[no_panic].
  2. Just because the compiler can't prove that something is true does not mean that it is false.
    It may be that your function really truly does not ever panic, but that the compiler can't prove it.
    In those cases we need to use other strategies like kani (which I would also like to bring in now that we are using bolero)
@daniel-noland daniel-noland added clean-up Code base clean-up, no functional change enhancement New feature or request labels Jan 31, 2025
@daniel-noland daniel-noland self-assigned this Jan 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clean-up Code base clean-up, no functional change enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant