Hi, i wrote: > > Currently i am not sure whether an API extension would be that much more > > development work
Pete Batard wrote: > In that case, I'm going to respectfully ask someone else to do that work, > because I have spent about as much time as I can allocate to adding > multi-extent support to mainline libcdio. Well, instead of committing ritual suicide because of https://www.nytimes.com/2018/06/27/sports/world-cup/germany-vs-south-korea.html i might give it a try. My plan is to: - Switch to branch pbatard-multiextent2. Create a new branch ts-multiextent in the hope to inherit Pete's work. - Change iso9660_stat_s.extent_lsn and iso9660_stat_s.extent_size to dynamically allocated memory (with proper destruction). Commit for a still ABI incompatible state with less memory waste. - Rename existing mixed API function implementations iso9660_*_stat*() to new names iso9660_*_statv2*(). Derive iso9660_statv2_s from iso9660_stat_s + DO_NOT_WANT_COMPATIBILITY. Remove multi-extent stuff from iso9660_stat_s. Implement old API functions again as mere frontends to the renamed functions. Expose iso9660_*_statv2*() calls which hand out iso9660_statv2_s. Implement and expose access functions for members of iso9660_statv2_s. Commit for ABI compatible state. Does this sound reasonable ? Especially the first step with git wizzardry ? Have a nice day :) Thomas
