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

[Rocky Bernstein]

On Mon, Jul 9, 2018 at 6:54 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> while copying Pete's work from example/isofile.c to example/C++/isofile.cpp
> i noticed that the j-loop assumes full blocks in all but the last extent
> of a data file.
> All blocks get read and written fully. Only the last extent's copy gets
> adjusted by ftruncate(3).
>
> I did not notice this when working on the .c files in ./examples.
> Pete, were you aware when you made your changes ?
>
>
> Reasoning why this assumption is very inappropriate currently:
>
> If we made it, then we would not need to model extents at all.
> It would suffice to add to iso9660_stat_t a large integer as ".total_size"
> and to deprecate the use of ".size".
> Applications would not need to loop over extents but simply loop longer
> over the blocks of a single giant extent.
>
> The assumption itself is quite plausible. I do not know real ISO images
> where it would not hold. For ISO producer software it is very natural.
> But: It is not in the ISO 9660 specs and it is not in Linux kernel.
>
> ------------------------------------------------------------------------
>
> What does this mean for our current discussion ?
>
> If we agree to make that assumption, then Pete's proposal can be reduced
> to a form which is very convenient for the existing applications.
> They would only have to change the use of one struct member.
> (ABI would break anyway.)
>
> If we do not agree to that assumption, then somebody will have to correct
> the extent loops in his proposal.
>
> The assumption makes few sense with my proposal. Either we can do it cheap
> or we can do it right.
> So i will now adapt the extent loops in ./example and ./test of my branch.
> I will give you a note when the first loop is ready for review.
>
> ------------------------------------------------------------------------
>
> Further my proposal still needs two boss decisions, before it could
> potentially be accepted:
>
> * Give the type enmum of iso9660_stat_t a name ?
>   Currently: No.
>   Consequence: New API has to simulate anonymous enum values by integers.
>

My take is to split off iso9660 with no ABI/API changes. Then change API
and give the
the anonymous enumeration a name.

I'm not all that thrilled with savannah as a project hosting system
compared to what you get with either
github, gitlab, or sourceforge.


> * Where to declare semi-public methods of iso_rock_statbuf_t ?
>   Currently: Declared in iso9660_fs.c and rock.c. Not in any header file.
>   Consequence: Clumsy. That's what header files are for.
>

Since we are breaking the API, declare it in rock.h.


>
> Have a nice day :)
>
> Thomas
>
>
>