Add unaligned feature#231
Conversation
|
I think I may be a bit confused, what happens today if anything is unaligned? Does an error get returned in parsing or does it end up being unsound? The way I thought something like this would look is that by default everything is considered unaligned to be safe, and then there'd be a crate feature for "assume everything is aligned" and alignment checks are added early on in parsing. (which may be higher performance?) |
|
From gimli-rs/addr2line#170:
|
|
Today the alignment checks are already there, and it returns an error if anything is unaligned. The feature has to be "assume everything is unaligned", because features must be additive: it is adding the ability to parse unaligned headers. |
|
Ah ok, makes sense. I don't really have an idea of what the performance impact to this would be, but I doubt that it'd affect the backtrace crate too too much either way. |
fitzgen
left a comment
There was a problem hiding this comment.
👍
LGTM; the discussion in this thread was clarifying.
While the structs defined in this crate have the alignment required by the specifications, some toolchains violate these requirements. Add an `unaligned` feature that allows these files to be processed, at the cost of potentially slower code.
|
Based on sentiment here and in the bug report, it sounds like it will be more convenient if this enabled by default, so I've changed it to that. |
Add `unaligned` feature
While the structs defined in this crate have the alignment required by the specifications, some toolchains violate these requirements. Add an
unalignedfeature that allows these files to be processed, at the cost of potentially slower code.Fixes #230
I've kept this out of the
allfeature for now. I'm not sure if this should be enabled by default. @alexcrichton What are your thoughts on whatbacktrace-rswill want for this? I'm not sure how much the performance of this matters, and whether you want to selectively enable it for some architectures (most likely x86-64).