Hi, Rocky Bernstein wrote: > I'll rely on > Thomas to give the go ahead for merging the ts-multiextent branch (or > Thomas you can just go ahead and do it)
Don't let me do sincere git work. As for the go-ahead, i wonder whether Pete's compiler likes the code now. > After that settles, then we can make another ABI and possibly API breaking > release. The point is that Pete's ABI breaking proposal will make no sense after the new type was introduced. The appeal of Pete's proposal is its simplicity - on application level as well as on implementation level. ---------------------------------------------------------------------------- Pete Batard wrote: > In my view, Thomas' proposal is way too disruptive for both libcdio and its > users, Is the effort for your own programs really that big ? (If you subtract the pain of changing your adapted code once more.) I thought that users who want to access large data files could bear it. All others may use the old API as long as they want. "Deprecated" does not mean "will be removed". There is no need for removal. More problematic is the size of my changeset. I touched lots of code where i found poorly maintainable situations. This implies typical risks. (Classic example is fixing a Coverity report with 50+ valid complains and stepping into the one puddle where the automat misunderstood the situation and the programmer was not smarter.) But although the old API is implemented on the new one, there is no increased risk of memory leaks as long as the old one is used in the way that is barely tolerable up to now. (I.e. Disposing iso9660_stat_t by free(3) causes memory leaks only with Rock Ridge symbolic links.) > we can get something a lot less painful for everybody. Not for everybody. With my library upstream programmer's hat on, i feel pain with both, ABI breakage and the narrow file size limit which is forced on your proposal by its way of memory management. If i was maintainer of libcdio in a binary GNU/Linux distro, then i had a little voodoo shrine with a needle puppet to paralyze Rocky's release hand. Nevertheless Adrian Reber, who is a maintainer of binary packages, showed more tolerance towards the need for recompiling all application binaries. Debian currently prepares for shipping two libcdio binary versions in its next release. I wonder what forced this very unusual solution. > I have a very strong feeling that, if we decide to go with > integrating Thomas' latest proposal, it will come to bite both us and our > users, and the cost/benefit ratio will not be in anyone's favour. Do not esteem too high the quality of the old versions of the code which i touched. It's probably not more bugs than before. Just other ones. My ones. {:) (I still have to assess my changeset for drive-by fixes of problematic code pices. I dimly remember potential memory leaks and more.) --------------------------------------------------------------------- So we have more or less three fuzzy opinions leaning to both sides quite equally. It is about the strategic decision whether libcdio's ABI stability shall get the usual importance, or whether libcdio stays peculiar in the GNU/Linux world by bumping its ABI / SONAME with each release. No need to hurry. Have a nice day :) Thomas