You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Except for the type named HeaderPt1, the rest of the ELF data uses the byte order indicated by the e_ident. Currently data will be read using the host's native byte order, which isn't correct in general.
It's not clear to me how to fix this, as the parsing approach taken by zero isn't particularly friendly to reinterpreting data.
The text was updated successfully, but these errors were encountered:
One option is to add a phantom type indicating the byte order of the data, and wrapping all multibyte values with a ByteOrder<E, T>, where T is the primitive numeric type being wrapped and E is the byte order direction. This E phantom type would need to be threaded throughout all of the everything. Parsing an ELF structure would then be some form of:
Most code can be generic over the byteorder marker completely, but it's correctness-critical that constructing the wrapper type enforces the correct byteorder.
Except for the type named
HeaderPt1
, the rest of the ELF data uses the byte order indicated by the e_ident. Currently data will be read using the host's native byte order, which isn't correct in general.It's not clear to me how to fix this, as the parsing approach taken by
zero
isn't particularly friendly to reinterpreting data.The text was updated successfully, but these errors were encountered: