libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] ABI problem with: [PATCH v2] add multi extent ISO966


From: Pete Batard
Subject: Re: [Libcdio-devel] ABI problem with: [PATCH v2] add multi extent ISO9660 file support to libcdio
Date: Wed, 27 Jun 2018 19:57:38 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 2018.06.27 19:35, Thomas Schmitt wrote:
Well, instead of committing ritual suicide because of
   
https://www.nytimes.com/2018/06/27/sports/world-cup/germany-vs-south-korea.html

Sorry for your loss.

You can still play an old recording of the last WC semifinal against Brazil, if you want to feel better...

i might give it a try.

I really appreciate that, thanks!

My plan is to:

- Switch to branch pbatard-multiextent2.
   Create a new branch ts-multiextent in the hope to inherit Pete's work.

This should do the trick:

git checkout -b ts-multiextent pbatard-multiextent2

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

Sounds good to me. But then again, anything I no longer have to do myself sounds good... ;)

Regards,

/Pete



reply via email to

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