libcdio-devel
[Top][All Lists]
Advanced

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

Re: [Libcdio-devel] ABI problem with: [PATCH v2] add multi extent ISO966


From: Pete Batard
Subject: Re: [Libcdio-devel] ABI problem with: [PATCH v2] add multi extent ISO9660 file support to libcdio
Date: Wed, 27 Jun 2018 13:26:43 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

Hi Thomas,

Yeah, as you found out, you can't move those new members to the end of the struct, so we're going to break the ABI anyway.

Besides, my view with regards to leaving the possibility to increase ISO_MAX_MULTIEXTENT is that, due to development time constraints, we have to make compromises here. The previous compromise was that libcdio did not support extent at all, because the previous developers (correctly) decided that it would be unlikely to affect that many people, and the new compromise is that we're not going to support more than 8 extent, with the reasoning that, since extent are logically being used when mastering files that occupy more than 4 GB, it is unlikely that someone will ever need to create an ISO-9660 with a >32GB file, and if they really need to do, they can always recompile their own *custom* version of libcdio with a higher limit (which we make very easy to do) for their own purpose. The likelihood that there will be an actual need to share a dynamic version of this library, or that we will ever find such a library in the wild, is minimal enough to decide we don't want to care about it right now.

On the other hand, I have no objection to setting ISO_MAX_MULTIEXTENT to something larger than 8 if we are worried that it may be too small.

With regards to your helpful means of generating a small multiextent image, I'll look into it as soon as I get a chance, and see if I can add a new test using that (which may take another couple weeks).

Regards,

/Pete


On 2018.06.27 11:22, Thomas Schmitt wrote:
Hi,

sorry, my demand to move the new members to the end of iso9660_stat_s
is poisonous.

Currently it looks like we will have to choose between a SONAME version
jump and implementing a complete new class for the ISO 9660 objects
which are currently represented by struct iso9660_stat_s.

See what's wrong with appending new members to iso9660_stat_s:

While pondering methods to avoid memory leaks with dynamic memory,
i came to this gesture in include/cdio/iso9660.h:

   #ifndef EMPTY_ARRAY_SIZE
   #define EMPTY_ARRAY_SIZE 0
   #endif
   ...
   struct iso9660_stat_s { /* big endian!! */
     ...
     char         filename[EMPTY_ARRAY_SIZE]; /**< filename */
   }

What ?
Google:

   https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
   "Declaring zero-length arrays is allowed in GNU C as an extension.
    A zero-length array can be useful as the last element of a structure
    that is really a header for a variable-length object"

   
https://stackoverflow.com/questions/9722632/what-happens-if-i-define-a-0-size-array-in-c-c
   "C99 6.7.2.1, ยง16: As a special case, the last element of a structure
    with more than one named member may have an incomplete array type;
    this is called a flexible array member.

So the opportunity to expand iso9660_stat_s in an ABI compatible way is
already used up. (Damn ingenious programming ! The fine art must be in the
model, not in the code.)


Have a nice day :)

Thomas






reply via email to

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