On Mon, Jul 9, 2018 at 8:52 AM, Thomas Schmitt <[email protected]> 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 > > >
