flac dev - Jan 2009 - Missing dereference in Stream::set_metadata()?

Hello,

I seem to have hit a bug with adding meta data to a stream via the C++
interface. I am using FLAC 1.2.1. I've had a look through the email list
archive and can't spot anything similar.

The Stream::set_metadata(Prototype) function takes a double pointer which
implies that it is expecting an array of pointers to Prototype objects. For
example:
    FLAC::Metadata::Prototype       *table[2];
    FLAC::Metadata::VorbisComment   comment;
    FLAC::Metadata::SeekTable       seek;
    table[0] = &seek;
    table[1] = &comment;
    bool bSuccess = encoder->set_metadata( table, 2 );

The assumption from the (very brief) API doxygen is that it will internally
convert from FLAC::Metadata::Prototype pointers to FLAC__StreamMetadata
pointers. Looking at the code, it does do the conversion but as a straight cast
which is therefore nothing more than an assignment. As the two objects are not
equivalent, this is a broken conversion. It results in an array of FLAC_SM
pointers that return gibberish when used and produces seg faults, infinite
memory consumption and other nasty effects!

The code needs to derefence the FLAC::M::P pointer before doing the cast in
order to make the compiler call the conversion operator on the object. That is,
it should read:
    m[i] = const_cast< ::FLAC__StreamMetadata*>((const
::FLAC__StreamMetadata*)*metadata[i]);

If I make the above change then everything works quite happily and I can produce
FLAC files that are exact binary matches with those produced by the flac command
line tool.

Is this a genuine bug or am I missing something?

Thanks.


_________________________________________________________________
Twice the fun?Share photos while you chat with Windows Live Messenger. Learn
more.
http://www.microsoft.com/uk/windows/windowslive/products/messenger.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20090128/d2aa9825/attachment.htm

So given that there are apparently people on this mailing list, has anyone had a
look at this? I've not heard anything back at all.

Thanks.


From: sayte75 at hotmail.com
To: flac-dev at xiph.org
Date: Wed, 28 Jan 2009 19:50:10 +0000
Subject: [Flac-dev] Missing dereference in Stream::set_metadata()?








Hello,

I seem to have hit a bug with adding meta data to a stream via the C++
interface. I am using FLAC 1.2.1. I've had a look through the email list
archive and can't spot anything similar.

The Stream::set_metadata(Prototype) function takes a double pointer which
implies that it is expecting an array of pointers to Prototype objects. For
example:
    FLAC::Metadata::Prototype       *table[2];
    FLAC::Metadata::VorbisComment   comment;
    FLAC::Metadata::SeekTable       seek;
    table[0] = &seek;
    table[1] = &comment;
    bool bSuccess = encoder->set_metadata( table, 2 );

The assumption from the (very brief) API doxygen is that it will internally
convert from FLAC::Metadata::Prototype pointers to FLAC__StreamMetadata
pointers. Looking at the code, it does do the conversion but as a straight cast
which is therefore nothing more than an assignment. As the two objects are not
equivalent, this is a broken conversion. It results in an array of FLAC_SM
pointers that return gibberish when used and produces seg faults, infinite
memory consumption and other nasty effects!

The code needs to derefence the FLAC::M::P pointer before doing the cast in
order to make the compiler call the conversion operator on the object. That is,
it should read:
    m[i] = const_cast< ::FLAC__StreamMetadata*>((const
::FLAC__StreamMetadata*)*metadata[i]);

If I make the above change then everything works quite happily and I can produce
FLAC files that are exact binary matches with those produced by the flac command
line tool.

Is this a genuine bug or am I missing something?

Thanks.


Share your photos with Windows Live Photos ? Free  Find out more!
_________________________________________________________________
Love Hotmail?? Check out the new services from Windows Live! 
http://clk.atdmt.com/UKM/go/132630768/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20090224/897e15eb/attachment-0001.htm