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

[Thomas Schmitt]

Hi,

i deem it a dangerous pitfall that application programmers could submit
stat buffers of the wrong type to calls of legacy or modern API.

How stupid is the following idea for a runtime distinction of iso9660_stat_t
and upcomming iso9660_statv2_t ?

-----------------------------------------------------------------------------

iso9660_stat_s begins by a iso_rock_statbuf_t which begins by a bool_3way_t.
bool_3way_t can have values 0, 1, or 2. But not 3.

Regardless of endianness, sizeof(bool_3way_t), and struct packing, i see
no way that the first byte of iso_rock_statbuf_t and thus iso9660_stat_s
could become 0xFF.
So one could recognize instances of iso9660_statv2_t if their first byte
was 0xFF unconditionally.

-----------------------------------------------------------------------------

Why bother ?
Although gcc warns if wrong types are used as function parameters, we have
  typedef CdioList_t CdioISO9660FileList_t;
  typedef CdioList_t CdioISO9660FileListV2_t;
which are not distiguished in their use cases by my local gcc.
They do not register the type of their list members, hand them out at run
time to credulent loops, and by their destructors iso9660_filelist_free*()
they make own assumptions about the destructor of their members.

How many bytes should be used for such a magic number member at the start
of iso9660_statv2_s ?
  struct iso9660_statv2_s {

    /** The constructor must set magic_number[0] to 0xFF */
    uint8_t magic_number[ISO9660_STATV2_MAGIC_SIZE];

    ...
  };
Are there alignment issues ?

What would be the proper reaction at run time as dynamic library 
on such a programmer's error ?  cdio_assert() ?


Have a nice day :)

Thomas