-
-
Notifications
You must be signed in to change notification settings - Fork 374
Update lib.rs #3160
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
Update lib.rs #3160
Conversation
I added the new error variants to the Error enum: - Configuration - For errors related to incorrect configuration settings - Compilation - For errors related to code compilation issues - System - For system call failures and resource allocation problems - Version - For version compatibility issues and added their corresponding constructor methods for each new error type, following the same pattern as the existing constructors in the library.
/// Compilation-related errors | ||
Compilation(String, ErrorBacktrace), | ||
/// System call or resource allocation failures | ||
System(String, ErrorBacktrace), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is almost always identical to OsError, right? Maybe make OsError's io::Error be optional, instead
/// System call or resource allocation failures | ||
System(String, ErrorBacktrace), | ||
/// Version compatibility issues | ||
Version(String, ErrorBacktrace), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this ever happen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well yes
- System(String, ErrorBacktrace) → Err(Error::system("The fuzzing target reports that the shm_open() call failed.")) and similar system error messages
- Version(String, ErrorBacktrace) → Err(Error::version("The -c cmplog target was instrumented with an too old AFL++ version, you need to recompile it.")) and the other version error message
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say it's fine to do
System(String, ErrorBacktrace) → Err(Error::os_error(None, "The fuzzing target reports that the shm_open() call failed.")) or os_error_str
(Error::illegal_state("The -c cmplog target was instrumented with an too old AFL++ version, you need to recompile it.")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm will do that
@@ -341,6 +341,14 @@ pub enum Error { | |||
InvalidCorpus(String, ErrorBacktrace), | |||
/// Error specific to a runtime like QEMU or Frida | |||
Runtime(String, ErrorBacktrace), | |||
/// Configuration errors, such as incorrect map sizes | |||
Configuration(String, ErrorBacktrace), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this different toIllegalArgument?
Do you have use cases for each of those? |
Those were deduced from
|
Yeah.. I would prefer to map these on existing error codes, see my comment above |
Ok for OSError instead of CompilationError, and where is defined toIllegalArgument? |
Status? |
I added the new error variants to the Error enum:
And added their corresponding constructor methods for each new error type, following the same pattern as the existing constructors in the library.