Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB

[Thomas Schmitt]

Hi,

i wrote:
> > * Give the type enmum of iso9660_stat_t a name ?
> >   Currently: No.
> >   Consequence: New API has to simulate anonymous enum values by integers.

> My take is to split off iso9660 with no ABI/API changes. Then change API
> and give the the anonymous enumeration a name.

To our luck, naming the enum will not break the API.
Only ABI might be in danger, because i cannot proove that the sizeof
an enum implementation is the same with named and unnamed enums.
And since i do all this to protect the ABI, it's an issue.

The currently activated hack avoids changing the struct iso9660_stat_s
in any way.


> > * Where to declare semi-public methods of iso_rock_statbuf_t ?

> Since we are breaking the API, declare it in rock.h.

Really. No API break planned.

I tried to squeeze the declarations into
  lib/iso9660/iso9660_private.h
but that gave me compiler errors because of missing iso_rock_statbuf_t
declaration.
Would it be appropriate to include
  include/iso9660/rock.h
in
  lib/iso9660/iso9660_private.h
?

-------------------------------------------------------------------------

About the assumption of block aligned extents:

While considering a branch which is based on that assumption, it came to
me that both existing proposals already allow for this sloppiness in
applications. The programmer just has to dare.

Now i wonder whether the documentation should mention that it is quite a
safe bet with existing ISO producers ?

-------------------------------------------------------------------------

I wrote:
> > * Design the API/ABI for being expandable without conflicting with the
> >   first two rules.

Pete Batard wrote:
> Pious goal. But realistically unachievable in my book.

I do this in libburn, libisofs, and libisoburn since more than 10 years.
So it's not unfeasible.


Have a nice day :)

Thomas