pyelftools icon indicating copy to clipboard operation
pyelftools copied to clipboard

elf: _default_=Pass for enums

Open ronnychevalier opened this issue 9 years ago • 6 comments

Why is _default_=Pass set for the enums?

If there is a bogus value in E_MACHINE it will not be caught, then when accessing elffile['e_machine'] we will get the unmap value which is an int, but we expect a str.

20f07e8647e438d1cf218a01cf70e8bfad468ff5 add _default_=Pass to the enums, but without any explanation. Could you explain the reason?

ronnychevalier avatar Jan 30 '16 23:01 ronnychevalier

IIRC, it's because otherwise we don't know what the original value was.

eliben avatar Jan 31 '16 00:01 eliben

On Sun, Jan 31, 2016 at 1:01 AM, Eli Bendersky [email protected] wrote:

IIRC, it's because otherwise we don't know what the original value was.

But, the values are known, so any value different from the known constants is irrelevant, right?

ronnychevalier avatar Jan 31 '16 00:01 ronnychevalier

I don't know if irrelevant, or just not standard. There's no single standard defining these values, and various tools insert their own values for special stuff. If I translate all such unknown values to, e.g. RESERVED, there's no way to know which value got there originally.

eliben avatar Jan 31 '16 00:01 eliben

On Sun, Jan 31, 2016 at 1:05 AM, Eli Bendersky [email protected] wrote:

I don't know if irrelevant, or just not standard. There's no single standard defining these values, and various tools insert their own values for special stuff. If I translate all such unknown values to, e.g. RESERVED, there's no way to know which value got there originally.

The exception thrown by construct gives us the value. Most of the known values are in pyelftools I believe, if someone would come across such exception (where the value actually means something) it could send a pull request/issue?

Because currently the only way there is to know if there is some bogus ELF, is to check whether we get an int or a str. This is a hack, the exception thrown by construct and caught by pyelftools is much more useful and a cleaner solution.

Would you accept a pull request to remove the Pass?

ronnychevalier avatar Jan 31 '16 00:01 ronnychevalier

The problem with the exception approach is that processing stops, and you get no parsed file unless you patch up pyelftools. Whereas with Pass the file does get parsed.

Maybe a better solution would be to str() the parsed value always (within pyelftools) so even for an integer you'd get it in string form and wouldn't have runtime errors?

eliben avatar Jan 31 '16 14:01 eliben