Re: [Libcdio-devel] Invalid/bad directory errors with openSUSE Leap 15.0 ISO

[Pete Batard]

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