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
