Hi,
Pete Batard wrote:
> So the way libcdio bails out depends on how you are trying to access the
> content.
Yep. With some run-up i noticed myself.
> Finally, if one replaces the calls to from_733_with_err() to from_733() in
> iso9660_fs.c then both the issue with isolist and isofile go away, so that's
> what I would advocate as a patch.
I second that idea.
But both calls do quite the same. from_733_with_err() tells that it has
warned, but we could as well just ignore the "err" parameter when calling it.
It does not provide much info if from_733() warns without saying where
the bad byte string came from. This knowledge is in the caller who will
not know that a warning was emitted.
So i think from_733() should not warn but just convert.
-----------------------------------------------------------------------
This brings me to a potential problem with endianness:
from_733 (uint64_t p)
{
...
return (UINT32_C(0xFFFFFFFF) & p);
}
It does not look to me as if reading of iso9660_dir_t does any conversions
or byte swappings which would swap the higher indexed bytes of a 7.3.3
field to the lower four bytes.
So the first 4 bytes of p are the number in little-endian representation.
So above return will yield a wrong result on big-endian CPUs
Since the source file is named "bytesex.h" i wonder why it's not
return uint32_from_le(UINT32_C(0xFFFFFFFF) & p);
Opinions. Can somebody defute my concerns ?
Does anybody have a machine or VM with big-endin CPU ?
(Does "isolist" work properly there ?)
-----------------------------------------------------------------------
Have a nice day :)
Thomas
