[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: Thomas Schmitt
Subject: Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB
Date: Mon, 09 Jul 2018 14:52:17 +0200


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
but that gave me compiler errors because of missing iso_rock_statbuf_t
Would it be appropriate to include


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


reply via email to

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