libcdio-devel
[Top][All Lists]
Advanced

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

Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible


From: Thomas Schmitt
Subject: Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB
Date: Sun, 08 Jul 2018 17:46:54 +0200

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




reply via email to

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