[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 23:28:38 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0

On 2018.07.09 22:05, Thomas Schmitt wrote:
     lsn_t extent_lsn;

     extent_lsn = from_733 (p_iso9660_dir->extent);

     /* Important: Test here with previous .total_size */
     if (p_stat->total_size > 0) {
       /* This is a follow-up extent. Check for a gap. */
       if (p_stat->lsn + p_stat->total_size / ISO_BLOCKSIZE != extent_lsn
           || p_stat->total_size % ISO_BLOCKSIZE) {

         /* >>> Gap detected. Throw error. <<< */;

         return NULL;
     } else {
       /* No extent with data before. Record this start as overall start. */
       p_stat->lsn = extent_lsn;

     /* Only now update .total_size */
     p_stat->total_size += from_733 (p_iso9660_dir->size);

Ah, OK. I see now, thanks.

Then, as a pragmatic person, I vote for the "only add total_size" approach, as this is the only one we really need, and we can address any reports of gaps *when* people can provide a real-life example of a gapped ISO.

As long as there's an error message on gap detected, and an error thrown, I'm onboard with this.

The only thing I'd like to see is a planned deprecation of size (through DO_NOT_WANT_COMPATIBILITY), so that downstream developers get some hint that they should update their code.



reply via email to

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