Closed jlxip closed 1 year ago
Ahh yes, that seems like what should be happening there. I don't see a reason for the behavior that's implemented today and I think I just overlooked that detail when putting together the no_std
support.
Like you suggested, it looks like the impl should be changed to core::error::Error
with the cfg line removed on that impl block. If you change that with a local checkout of the elf source, does it let you do what you're hoping for? If so, would you be interested in putting together a PR for this?
First, let me say that I have no idea what I'm talking about. I've been learning Rust since the past month or so, so I don't understand the intricate details of it.
I'm writing a kernel and I'm using this project as the ELF parser. My program loader returns a
Result
with a runtime error type, since it can be eitherParsingError
or any other thing (such as an issue during page allocation). I can'tunwrap()
theResult
ofminimal_parse()
since it's not always desirable to throw a kernel panic.Apparently I can't do:
since in
!#[no_std]
environments, where thestd
external crate isn't present, butcore
is, according to this line, theerror::Error
trait is not implemented, soParsingError
can't downcast to it.If I understood everything correctly,
std::error::Error
is just a re-export ofcore::error::Error
, which doesn't really need any std-ish functionality. Would it be possible to substitute theimpl
ofstd::error::Error
trait for thecore
one, and thus remove the need for thestd
feature to be enabled in the crate?Thanks a lot, and sorry if I'm not understanding something fundamental.