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

[Rocky Bernstein]

On Mon, Jul 9, 2018 at 8:52 AM, Thomas Schmitt <address@hidden> wrote:

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

Ok. Good.

>
>
> > > * 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
> ?
>
>
I don't see why not: rock.h is a public interface and libiso9660 already
depends on libcdio.


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

Sure. Documenting what it took you a while to figure out is great thing to
do.


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