Philip Craig

> This is the code that solves it. That's changing the code to return the addresses of the IAT entries instead of their values. I don't think that's the correct...

> But maybe it would be helpful to additionally expose a function that returns import names and their rva. This isn't something I'm familiar enough with to be able to...

Thanks for that explanation. Also my suggestion to add `SyntheticImportDirectoryEntry::import_address_table_rva` is wrong because it already exists at `SyntheticImportDirectoryEntry::import_directory_entry.import_address_table_rva `.

I've also noticed now that the `import_lookup_table` can have holes in it: https://github.com/m4b/goblin/blob/b43b93ed2243b75043d6fb1021ad9aec227df1f5/src/pe/import.rs#L144-L145 so calculating the RVAs may be inaccurate. That is, we do need to store them. Something that...

> I've also noticed now that the import_lookup_table can have holes in it: This shouldn't actually happen for valid files. It did previously happen, but that was due to a...

No, there was an example file in the original report #28, but we now parse that successfully.

My opinion is to keep things simple, especially for something that probably prevents the file from being executed, but I don't maintain this project. This also has the advantage that...

I didn't write the code, but here's my thoughts. `container` and `endianness` are different because they don't directly correspond to header fields (they aren't `#[repr()]`), and they are concepts that...

> Isn't the same true for e_type? I don't think that many new variants will be added There's also: ```rust /// OS-specific range start. pub const ET_LOOS: u16 = 0xfe00;...

No, this is the equivalent of clang's `-flto`, which causes the compiler to output bitcode instead of an object file. So it's a different file format (maybe it contains an...