[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
Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB
Sun, 8 Jul 2018 20:47:47 +0100
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...