[Libcdio-devel] ABI problem with: [PATCH v2] add multi extent ISO9660 file support to libcdio

[Thomas Schmitt]

Hi,

> 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.

There is still the option of providing a new additional API.
It needs to be used only for data files, because directories are not allowed
to have more than one file section. So most internal functions of libcdio
can continue to use old iso9660_stat_t.


> 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.

Currently i am not sure whether an API extension would be that much more
development work compared with squeezing new stuff into iso9660_stat_t.

Consider these steps:

- Copy old API struct, type and functions to new names:
   struct iso9660_stat_s
   typedef iso9660_stat_t
   iso9660_fs_stat
   iso9660_fs_stat_translate
   iso9660_fs_readdir
   iso9660_ifs_stat
   iso9660_ifs_stat_translate
   iso9660_ifs_readdir
   iso9660_stat_free

- Adapt copy to new needs as you would do with iso9660_stat_t, but without
  the need for compatibility.

- Optional improvement over old API:
  Create API functions to inquire the members of the new struct.
  Do not expose the struct entrails in API.
  (We would not have to discuss this issue if the entrails were already
   private.)

Advantage would be freedom to later improve the new API (e.g. by reading
libisofs AAIP attributes), freedom of any compatibility fears, and
freedom of memory inflation fears with existing applications of libcdio.


> 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.

It looks like there is already the obligation to call iso9660_stat_free()
on the iso9660_stat_t which were handed out by API calls.

So even with ABI change it would be more flexible and in average more
economic not to have fixed size arrays but rather a pointer to a
dynamically allocated array of structs with members {lsn_t , uint32_t}.


> 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 my olde Debian GNU/Linux there are installed

  libcdio.0.83.a
  libcdio.a
  libcdio.so.13.0.0
  libcdio.so.16.0.0

Number 13 was obviously installed with the base system
  https://packages.debian.org/jessie/amd64/libcdio13/filelist
I guess that i installed number 16 from my own experiments last year.
At that time libcdio.0.83.a was renameed from old libcdio.a.

Debian 9 still offers libcdio13. But Debian 10 prepares for libcdio17
and libcdio18 simultaneously:
  https://packages.debian.org/source/buster/libcdio

So this ABI compatibility and SONAME stuff matters in the Debian world.


> it is unlikely that someone will ever need to create an
> ISO-9660 with a >32GB file,

Largest optical medium is 128 GB. My personal main use case with ISO 9660
is backup of data files. I play with large ISO images. So a 32 GiB data
file is not totally unlikely. 


Have a nice day :)

Thomas