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

[Thomas Schmitt]

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


Have a nice day :)

Thomas