Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB

[Pete Batard]

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

Regards,

/Pete