-
Notifications
You must be signed in to change notification settings - Fork 163
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
Add 'alloc' feature #75
Comments
I realized I started typing up bunch of stuff, but seems like you've done most of this, just wanted clarification on some things hehe. Sorry for the delay; So for That being said, the For example, I initially imagined the following hierachy:
Honestly, at this point, The parser flag should also turn on every other flag, since its the default + the maximal api surface. As for other mach/pe feature gates, I think they're all It's hard to say; if you have a PR might be better to open up and i'll be able to look at the diff, or where your thoughts are/what you're thinking, before it gets to be too much of a monster? |
Ok that makes sense. Do you count the scroll traits as part of the parser?
I'm not sure about that. I think it should be possible to enable parsing for only the bits you need. So I think the hierarchy should be:
The |
The work I've done so far is just to verify that I can do parsing in the object crate without depending on std, but the changes I've done for that are just hacks to get it to compile. So if the above kind of sounds like the right way to go, then I'll clean it up to look like that, then can review further. |
For gimli-rs/object#45, we need to be able to parse all the formats when using
#[no_std]
. Currently, a lot of the parsing requires allocation. Completely avoiding allocations is too much work for now, and probably not a good use of time. And anyway, we can still use thealloc
crate withno_std
(but this does require building with nightly currently).So I propose we add an
alloc
feature that is midway betweenno_std
andstd
. This feature will cover everything that uses allocations, and so mostly what will be left instd
will be things that usestd::fs
orstd::io
.I've done enough to verify that this approach works, so assuming this is acceptable, now I just need to clean it up and submit a PR.
One question I have is about the
endian_fd
feature. What exactly is this meant to cover? The readme says it 'parses according to the endianness in the binary', but it doesn't cover code such ashttps://github.com/m4b/goblin/blob/master/src/elf/section_header.rs#L490. Currently it gates the entire mach/pe/archive formats, and it also requires 'std'. I want to relax this restriction as part of adding the
alloc
feature, but I'm not sure which parts of mach/pe/archive should still require it.The text was updated successfully, but these errors were encountered: