On Sun, Jul 1, 2018 at 3:36 AM, Thomas Schmitt <[email protected]> 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 > > >
