[Top][All Lists]

[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: Pete Batard
Subject: Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB
Date: Sun, 8 Jul 2018 20:47:47 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0

On 2018.07.08 16:46, Thomas Schmitt wrote:
i wonder whether Pete's compiler likes the code now.

Yes, looks fine now. Thanks for fixing that.

Is the effort for your own programs really that big ?

My objection is with going with a new _v2 struct when all we do is changing/adding 3 fields into arrays. IMO, a v2 should be reserved for "oh yeah, we designed the _whole_ thing very wrong, and this is creating tons of issues, so we're redesigning from scratch in a way that should alleviate all these problems".

But if you're really addressing a single issue, and you can easily do so by adding a couple arrays to the existing struct, whatever alternative I see to that approach will always ring as "overkill" to me, even more so as I will also continue to firmly dispute both the ideas that breaking the ABI is the end of the world (it's just an annoyance, which we can absolutely delay for as long as we feel like, in order to give some breathing space for maintainers & developers) and that limiting ourselves to "only" 8 extents, if we choose to do so, will create an actual real-world insurmountable issue for libcdio users in the long term.

So I am against going through an over-design for purely academical problems, which is how this solution feels to me. At least, as much as I do value the depth of your work, these are not the problems I see much interest in addressing when there are enough real-life issues that should take precedence such as, indeed, going over the coverity warnings and other stuff.

Furthermore, I very much think we want to nudge developers into caring for extents in their code, which isn't going to happen if they can simply compile with latest libcdio and not see anything changed. Continuing to have developers ignore extents _will_ result in a degraded experience for users, who won't be able to throw something like the very publicly available blackarchlinux-live ISO at whatever libcdio based application they want to use. So having an ABI breakage and/or an existing struct with members that are clearly flagged as about to be deprecated, with a clear indication of new ones to be used instead, is a good way to get people to care about stuff that will be beneficial for their users, even if their first impression might be that it's purely an annoyance. On the other hand, if we do our darnedest to hide the multiextent issue, we might indeed manage to make the life of developers and maintainers easier, but at the expense of the end users...



reply via email to

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