[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible

From: Pete Batard
Subject: Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB
Date: Mon, 9 Jul 2018 18:17:36 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0

On 2018.07.09 17:17, Thomas Schmitt wrote:
The reader from ISO directory records, _iso9660_dir_to_statbuf(), knows
the start and size of the previous extent. So it could check whether the
current extent fits seamlessly.
E.g. after:

     p_stat->extent_lsn[p_stat->num_extents] = from_733 (p_iso9660_dir->extent);
     p_stat->extent_size[p_stat->num_extents] = from_733 (p_iso9660_dir->size);
     p_stat->total_size += p_stat->extent_size[p_stat->num_extents];

it could do:

     if (p_stat->extent_lsn[p_stat->num_extents - 1]
         + p_stat->extent_size[p_stat->num_extents - 1] / ISO_BLOCKSIZE)
         != p_stat->extent_lsn[p_stat->num_extents]
         p_stat->extent_size[p_stat->num_extents - 1] % ISO_BLOCKSIZE) {

       /* >>> Gap detected <<< */;


Ah, now I'm starting to see what your actual plan is.

My understanding was that you were planning to drop the extent_lsn[] and extent_size[] members altogether, keeping only the first extent lsn and the last extent size (for last extent truncation), along with a new total_size, and assert that everything would be set sequentially in 4 GB extents in between, dropping the need for ISO_MAX_MULTIEXTENT (since we would no longer have the arrays).

If you are planning to keep the arrays, then I guess your whole point is about avoiding libcdio users to add an inner extent loop if they prefer.

I personally don't believe it's that big a deal, but, if we are not going to drop the publicly exposed LSN arrays, I don't have much of an objection providing samples that go in this direction (while having at least one sample that does the inner loop, along with alignment/truncation handling, since we're going to have the extent arrays exposed anyway), and give the choice to downstream folks to pick the one they prefer for dealing with multiextent.

If gaps are found, it could either bail out with error message, or it
could mark the stat buffer by a new flag member. Another flag could
indicate whether ISO_MAX_MULTIEXTENT was exceeded.

Bail out is what I would advocate for. I don't like the idea of giving the opportunity for people to have a big chunk of data missing or corrupted, and go on their merry way if they fail to check a flag. Missing/corrupted data _is_ a big deal and should result in an error.

Apart from that, and now that I think I understand what you're trying to accomplish, sure, adding an alternate path in our code to read a multiextent file in one sway sounds like a good idea, if it doesn't add too much complexity.

But considering that we still need to have some arrays of extents LSNs and sizes (either dynamic or fixed), it still doesn't do much to answer the question about using a _v2 and keeping the ABI, or just expending the existing struct and breaking the ABI (reminding everyone that none of these options would break the API). Unless I'm mistaken, what you are proposing can be accomplished on top of whichever option we pick.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]