[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: |
Mon, 09 Jul 2018 14:52:17 +0200 |
Hi,
i wrote:
> > * 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.
To our luck, naming the enum will not break the API.
Only ABI might be in danger, because i cannot proove that the sizeof
an enum implementation is the same with named and unnamed enums.
And since i do all this to protect the ABI, it's an issue.
The currently activated hack avoids changing the struct iso9660_stat_s
in any way.
> > * Where to declare semi-public methods of iso_rock_statbuf_t ?
> Since we are breaking the API, declare it in rock.h.
Really. No API break planned.
I tried to squeeze the declarations into
lib/iso9660/iso9660_private.h
but that gave me compiler errors because of missing iso_rock_statbuf_t
declaration.
Would it be appropriate to include
include/iso9660/rock.h
in
lib/iso9660/iso9660_private.h
?
-------------------------------------------------------------------------
About the assumption of block aligned extents:
While considering a branch which is based on that assumption, it came to
me that both existing proposals already allow for this sloppiness in
applications. The programmer just has to dare.
Now i wonder whether the documentation should mention that it is quite a
safe bet with existing ISO producers ?
-------------------------------------------------------------------------
I wrote:
> > * Design the API/ABI for being expandable without conflicting with the
> > first two rules.
Pete Batard wrote:
> Pious goal. But realistically unachievable in my book.
I do this in libburn, libisofs, and libisoburn since more than 10 years.
So it's not unfeasible.
Have a nice day :)
Thomas
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, (continued)
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/10
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Rocky Bernstein, 2018/07/10
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Pete Batard, 2018/07/10
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/10
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/11
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/13
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Pete Batard, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB,
Thomas Schmitt <=
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Rocky Bernstein, 2018/07/09
- Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB, Thomas Schmitt, 2018/07/10