For the record, the bug with openSUSE has been filled as:
https://bugzilla.opensuse.org/show_bug.cgi?id=1094761
On 2018.05.26 21:36, Thomas Schmitt wrote:
This brings me to a potential problem with endianness:
return (UINT32_C(0xFFFFFFFF) & p);
I meanwhile understand that it is safe.
On a big-endian machine, "0xFFFFFFFF &" will keep bytes 4 to 7 of p,
which are correctly formatted as big-endian 32 bit value.
Wouldn't we want to have some logic to discard the big endian value and
instead use the endian-swapped little endian value if we find that
little and big endian are in disagreement?
If we are to process the current (non spec-compliant) openSUSE ISOs on
big endian machines, aren't we going to get the incorrect/unpatched
sizes as a result? Or am I missing something?
If I'm correct, I expect that the openSUSE Leap processing will fail on
big endian archs, even if we replace from_733_with_err() with from_733()
since we'll pick the (wrong) big endian part then.
So I guess what I'm proposing would be to use from_733() instead of
from_733_with_err() as proposed earlier but also add some logic in
from_733() to:
0. Discard the warning altogether
1. Compare the BE and LE values
2. Silently use the LE value if we find the BE and LE are in
disagreement, as it is unlikely that the BE is the one we are really after.
In case it matters, from_733_with_err() would be left unchanged, so that
we can still use that version for parts of the code where we believe
that we need to detect and report these conversion errors.
Does that make sense?
Regards,
/Pete
