Re: [Libcdio-devel] [RFC] Hid ISO_MAX_MULTIEXTENT from public and made extent list dynamic memory

[Rocky Bernstein]

On Sun, Jul 1, 2018 at 3:36 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> maybe ritual suicide would have been better than an attempt on
> iso9660_statv2_t. The diff is now 2600 lines long and i'm not done
> yet with all examples and test programs. Some housekeeping aspects
> still need attention, too.
> (Especially annoying was the habit in rock.c to use iso9660_stat_t
>  as currency where its own iso_rock_statbuf_t would suffice. I had
>  to wean it.)
>
> ---------------------------------------------------------------------
>
> During tests of the new code i had to learn that my commit
>
>   "Hid ISO_MAX_MULTIEXTENT from public and made extent list dynamic memory"
>
>   http://git.savannah.gnu.org/cgit/libcdio.git/commit/?h=ts-
> multiextent&id=3b602d69cb116a297ee95e48471a097ce7456435
>
> causes memory corruption (e.g. in example/extract with a Debian netinst
> ISO)
> by two clone gestures at the beginnings of  _fs_stat_traverse()  and
>  _fs_iso_stat_traverse() , which i did not recognize as such.
>
> Further the previous programmers caused memory leaks with disposal of
> iso9660_stat_t objects by free(3) rather than iso9660_stat_free().
>


When you find errors like this please just fix them in the main branch.
Thanks.



> In the current implementation this is problematic only with Rock Ridge
> symbolic links. But with dynamically allocated extents or with
> iso9660_statv2_t it became bad with every statbuf object.
>
> Three cheers to valgrind !
>
> If there is interest, then i can fix this flaw in the ABI incompatible
> but much less intrusive variation. It depends how my proposal with
> iso9660_statv2_t is received.
> (Currently my git clone is clogged with code changes and experiments.
>  I better do not try what happens if i branch now.)
>
>
I've been trying to clean up stale branches. Feel free to do the same.


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